zygot

I did figure out a way to scroll though 4M samples in a text file and plot 16K sample segments at a time using OCTAVE. Not pretty but usable. SCILAB is, unfortunately, just unable to handle matrices larger than about 64KB. No doubt an issue with how they handle memory. I have a few things to clean up before getting moving on developing a ZMOD demo project that lets them be useful and avoid the dreaded storage closet where old and useless things sit hoping for a second chance...

I think that our wires are crossed. Except for some potential ZYNQ designs where it's unavoidable, I don't want to see or touch anything AXI. Even with ZYNQ I can usually step around them employing BRAMs or AXI FIFO streaming interfaces where I'm not worried about efficiency or data throughput. I don't see much use for all the hassle of incorporating an ARM into an FPGA design except for rare applications. For something like making a mid to high performance FPGA platform a ZYNQ solution is just going to get in the way. Now, it's possible to design a ZYNQ board that lets users do advanced IO designs. You just have to be willing to put enough PS DDR on the board to support it's OS and room for some large data buffers that might connect to the PL. You also have to provide the PL with its own DDR so support those advanced IO applications. Unfortunately, finding a moderately priced ZYNQ platform that does that is a rarity... off hand none come to mind. Yes, I can see using a well designed AXI Master packaged in a way that's suitable for the Vivado flow so I can quickly build a standalone SDK application in the SDK or Vitas. Got one of those? No I have no interest in experimenting with lots of 'bus adapter' IP that involves busses that I want to avoid like the plague. Really I just want a nice non-ARM FPGA platform that doesn't prevent me from using all of that nice Series7 Select IO to its fullest capability.. and a 1gE or better yet 1,2.5,5,10 gigabit port, and a usable PCIe or USB 3.x platform/PC interconnect. The old Z7000 is really not ideal for a nice Linux/FPGA development platform. In theory the UltraScale ZYNQ families now have the processor horsepower to keep up with a Raspberry Pi 4 but the IO requires too much additional hardware to use the PL with most existing stuff that you might want to use it with. So you can get a cheap UltraScale board for less than a decent Z7020 board but you can't afford to connect it anything without a lot of expense and effort building you own adapter boards. I suppose that this is the price of technical advancement. One point of this exercise is that using only HDL and even a low end plain old FPGA platform that has been reasonably well designed can do a lot more than a comparable ZYNQ platform with a lot less pain with a shorter design time using far fewer logic resources and be reusable in a different project using some future version of Vivado without spending weeks of resolving broken IP instantiations and code depreciation. "I think I might disagree with you about CPU design being one potential or even necessary user of such a complex bus structure. It doesn't need to be so." My reference here is to a standalone general purpose microcontroller IC that a customer might use on a PCB. Even then I'm not advocating for it, just possibly willing to concede that it might serve a useful purpose. I'd still rather have a simple external data pipe to deal with.

If this was a ZYNQ platform and I was using the AXI Virtual FIFO I wouldn't be able to capture more than 4 channels of 32K samples each as there is a limit of 256KB with the core. My philosophy is that pipes that just move data around should be as simple and fast as possible. The complexity should be in the logic. For ARM based FPGA devices the hard ARM complex is best suited to handle complexity that end. For the PL this is where your logic resources are. There's absolutely no design justification for putting AXI busses between the ARM complex and the PL. A simple bus with address, data and a handful of simple gating controls is ideal. Instead of 4-8 AXI pipes connecting the PS to the PL, and perhaps an application only using 1 or 2 of them, there should be one or two really wide fast pipes letting the user can decide how to best use them for their application. I mean customized application specific logic is the reason for being for an FPGA. It sure can't compete with non-programmable logic. Now if you are designing a ARM CPU without programmable logic I could see where you might want to expose complicated AXI or AMBA busses to the user who might want to hang a number of all sorts of peripherals with a combination of low speed low throughput and high speed high throughput. For an FPGA with an embedded hard ARM core complex this makes no sense to me.

An additional thought. It took me a lot less time to make use of the ZMODADC1410 for this application than it did trying to work out the overly complicated and poorly thought out Eclypse-Z7 supporting code... and I'm not close to being done with that as I write. Compare the two approaches. Compare the usability. with this platform I can write a PC application that configures the target FPGA, executes an application and quickly gets data to a PC for analysis or storage. The Eclypse-Z7 can't do any of that. At this point it can't do anything without an SDK or Vitas support. [edit] I'm still hopeful that Digilent has the will to at least make the Eclypse-Z7 live up to its potential. It's flawed but still worth the investment in development time to allow users to do interesting things with.

Two ADC ZMODs each with a dual 14-bit (sign plus 13 bits) ADC. All four ADCs sampling at 100 MHz. This is an Artix 75T and is comparable to the PL in a XCZ020 device. No AXI anything. No processor cores. Just a couple of FIFOs, a DDR read/write controller, a Mig DDR soft controller, and some control logic. The ADC data is gain and offset calibrated so some of the bits can be thought of as fractional. But the DDR data write rate for 4 channels is 100 million 64-bit words/s. The DDR has a 32-bit data path. It sure would be nice if the Artix had a hard DDR controller like the Spartan6 it replaces as the Spartan6 DDR controller is both higher performance and more flexible. Unfortunately, the Mig is stuck with a 4:1 controller/DDR clock ratio, but it all works out. The DDR, for this application, is essentially a giant FIFO. A small state machine controls how many words are are captured and after capture the host application reads out the contents of the DDR. If you want to capture 128M samples per channel you could just write the DDR and use it as a circular buffer though this would complicate the design a bit. As I mentioned this is just a proof of concept design at the moment. This shows the possibilities for the boards involved. The SYZYGY is capable of demonstrating Series7 Select IO and each SYZYGY port could support a quad 16-bit ADC though the DDR would have to be beefier for 8 channels. Then there's the limitations of a small FPGA board and its power supplies. The FPGA never got above about 50C as measured with a infrared temperature sensor and has no heat sink. I'll probably add one at some point. The USB interface is vendor provided encrypt netlists and somewhat odd to work with but can do sustained 350+ MB/s data transfers befitting such a platform. The application was written in C++ using VS2019. As I mentioned I used as much vendor supplied code as possible to get off and running quickly. I had to do a few preliminary projects to create the Mig so the early ones were all Verilog. Once things came into place I copied the Mig and instantiate all of the Verilog into my VHDL toplevel entity. The USB interface allows for changing gain and offset calibration coefficients on the fly as well as analog front end gain and coupling options. It's all a lot cleaner and uses way less resources than AXI IP. Because the ADC data is aggregated into a 64-bit data word and written to an asymmetric FIFO (64-bit write, 1024 bit read) the application has to do some additional formatting to take 8-bit chars and create scaled real data in Volts. The ZMODs are nicely thought out and well implemented. A nod of appreciation to the design team responsible. Great job! It's really an adaption of the Analog Explorer ADC design beefed up for a higher performance platform. The only Xilinx IP are the native MIg and FIFOs and an MMCM. The thing that should impress people is the low resource utilization for the entire design. Try that with a Microblaze tricycle design approach! In the real world no one uses MicroBlaze because it takes up most of the resources and leaves the designer with little left to work with. I'm still looking for that FPGA board that let's Series7 really shine. Take the Genesy2. Remove the FMC connector. Add 2-3 standard SYZYGY ports and a 4-lane SYZYGY transceiver port. Make the DDR with a 64-bit data path, keep the mDP as is, call it Genesys3 and now we're talking business**. TI makes some nifty Ultrasound AFE devices that could work with a double-wide standard pod arrangement. Actually, there's a lot of possibilities. As I pointed out earlier SYZYGY isn't necessary but is a nice format that allows for a wide range of FPGA design applications. For too long now students and experienced engineers on a budget have had to make do with hardware that doesn't allow them to make use of the resources of the FPGA devices they are paying for. That's more than a shame. I could have done a similar 4 channel ADC design with the Cyclone V GT development board and two DDC HSMC mezzanine cards and used the PCIe 4-lane Gen2 as a PC interface though it would be messy since that board isn't really designed to sit in a PC properly. I have used a PCIe extender cable with that board. It's just nice to be able to do this with a Xilinx device and tools. The PCIe data rate is high enough to stream data directly into the PC memory. ** [edit] If you are going to make a nice platform like this it should have at least a USB3.0 interface for interaction with a PC and these days most boards that aren't the lowest end should have at least 1 high quality programmable clock module. Designing a good FPGA board is hard work. Why waste the effort by doing something half baked?

I suppose that now I have to buy another DAC ZMOD so that I can test 4 ADC channels. I have a lot more confidence in a 4 channel DAC with the Eclypse-Z7 as a useful combination.

Capture 4 channels of 120+ million ADC samples per channel. As a proof of concept project I just completed a design using the Opal Kelly XEM7320 with 2 Digilent ADC14010 ZMODs in a direct to DDR 4-channel ADC 100 MHz Fs application. Opal Kelly has a unique approach to FPGA development that generally appeals to software developers. For me they do a few things that usually are show stoppers. For one most boards have a closed configuration/PC interface. The only way to use their boards is with pre-compiled encrypted netlists. For another they don't provide schematics, or even partial schematics. Their price point for hardware verses say Digilent or Terasic is substantially higher. Still, I've had success with their products which allows me to overlook the bad stuff. It's great that Digilent has gotten into the SYZYGY game with two very good converter ZMODs. Not so great is their inability to make an FPGA platform product that showcases the potential for what amounts to as an opportunity to use Xilinx Series7 Select IO in all of it's glory. SYZYGY isn't the only way to go, though it is a worthy attempt at a plug and play cross-platform cross-vendor standard. Any board vendor can make an FPGA board that allow users to explore the full value of the Xilinx Series7 devices, they just have to want to and then design board that allows it. Don't let marketing people design boards, hire an experienced FPGA guy person and let him them design boards. Trust me it'll all work out in the end and everyone will be happy. You'll make money and you will have a broader customer base buying your stuff. The XEM7320 is the only non-ZYNQ board the Opal Kelly offers. It has an Artix 75T device and is priced competitively with the Eclypse-Z7. The XEM7320 has 2 standard ports and 1 transceiver port verses the Eclypse-Z7 2 standard plus 2 PMOD ports. The XEM7320 has a USB 3.0 PC interface and the tools for configuring the device from within the software application. The important feature that the XEM7320 has with respect to SYZYGY is a 1GB DDR device that ZMOD ADC samples can be written directly to. I was able to bootstrap the Opal Kelly RamTester demo C++ and HDL code to make an application that can capture 128M 16-bit samples on 4 channels using 2 ADC1410 ZMODs. It's an all HDL mixed VHdl/Verilog design. No MicroBlaze. No board design. (almost) no vendor tool version issues. No SDK or Vitas, just VS2019, which is free these days. I used the Digilent ADC1410 low level controller code as a first cut though I will be replacing that with a more appropriate approach later. The DDR is essential just a very large FIFO. The whole design resource useage: LUTS <20% LUTRAM 5% FF 8% BRAM <10% DSP 2% The VS2019 application configures the device and saves all data to an ascii file for use with SCILAB to OCTAVE. The only big issue at this point is viewing large 4 column matrices in a waveform rendering. I'm open to suggestions. How is the best way to render a plot of this: d = [ float4, float3, float2, float1, //sample 0 ... ... float4, float3, float2, float1] //sample 1048575 Thanks Digilent for bringing 100 Ms/s ADC/DAC options to the general Xilinx user audience. It's been a long time in coming. [edit] Apologies to anyone reading the first version of this post where I got the sample count wrong. If I had a marketing guy writing this the title would have read " Capture over 1/2 Billion ADC samples". I hate it when the details deflate the high expectations of the attention grabbing headline, even if over half a billion samples is technically correct. I should point out that so far I've only capture and uploaded 1*1024*1024 sample for all four channels. The reason being that I don't have a way to verify more data than that. I did start of with a 100 MHz 64-bit counter written to DDR and that I was able to confirm. Even with a very fast USB 3.0 interface converting bits to mV and formatting even 10*1024*1204 samples and printing the data to a file takes more time than I want to spend at the moment. [edit2] Gender and skill are not correlated at all. Don't select books or talent by the appearance of the cover.

So, for someone with no background in digital design or FPGA development the cheapest board will do. You don't have to think about external interfaces and advanced IO features. You will be concentrating on learning basic concepts and the tools. The tools are complex enough. There are a number of options under $150. The Arty A7 is a fine way to get started. Once you start getting a feel for how this FPGA stuff works and have started fleshing out the specifics of some of your eventual project goals then you'll know what peripheral interfaces are most important and will be in a position to make a better decision. I would encourage you to resist the idea of growing into a more expensive board that is designed to provide capabilities that you don't need. The Nexys Video is a fine board. I use one myself. As the name implies it's primarily for video applications though I use it mostly for other things. As for hidden costs you should be aware that Digilent doesn't really provide support for all of the features of all of its boards but relies on Xilinx IP and puts the burden on the user to figure out how to use them. The Nexys Video is a good example of this. Unfortunately, this is common among such vendors. It's a good idea to 'test drive' a board that you think that you are interested in to see what you are getting into. A good way to do this is to install Vivado and then download every demo provided by the board vendor and see if you can create a bitstream for it on your own. You will learn about required licenses and issues like tool version compatibility in short order. You can also see the level of support that you''ll get from the board vendor or the tools vendor. There's no scalability; if you need more external memory or FPGA resources or capability you need to buy a new board. Some boards so have a measure of extensibility like an FMC connector. The Nexys Video is one of them. Don't assume that you will find an FMC mezzanine card with the features you want and expect it to work with a particular FPGA carrier board though. I've done plenty of DSP design work in VHDL using devices less capable than a Artix 35T which is near the low end of Digilent's portfolio. You don't need to use vendor IP either. I highly encourage you to adopt the Verilog or VHDL design flow even though, up front, the board design flow using vendor IP seems easy. This is especially true for Ethernet; particularly if you want to do something unusual with it. As for ZYNQ I'd advise this as an unnecessary complexity and distraction for people learning an HDL flow. Understand how to design logic and verify it first. When you have designed your experiment and can partition some elements as being processor efficient verses other elements being logic efficient then you can decide if this is appropriate. Don't get distracted by non-essential frills, especially before you get your 'sea legs'. I would suggest that you stick to boards with a 14-pin JTAG header for a number of reasons. [edit] You mention machine learning. Intel is big into this. Terasic has a few inexpensive OpenVino boards for this. The GT version of the C5P is designed to be an machine learning 'accelerator' , though on the low end. I use one myself for other applications. You can use the free tools for this board. Xilinx doesn't have anything comparable to this at an affordable price. At least look around. Both Intel and Xilinx are big into this arena but only for the well heeled. You need to do a lot of homework to figure out where the gotcha are though. in general, the more layers of tools there are the more nasty surprises are waiting for the uninformed.

Just when I was about to complement @xc6lx45on posting a more succinct reply by focusing on the most glaring problem with your question he interrupts my train-wreck of thought with a second post. A sure way of de-railing ( notice how I can keep to a theme? ) a project is to under-estimate the requirements or complexity involved. If you anticipate that learning how to do useful FPGA development is a trivial step toward completing an FPGA-centric application then you are in for some unpleasant surprises. I've know people who were brilliant enough to seemingly side-step all of the preliminary preparatory work and experience that mere mortals like myself would need in order to accomplish something remarkable but this is truly a rare individual. Even if you know everything that need to be known about the topics and theory of a project there's another couple of levels of complexity involved with tools, IP, licensing etc to trip you up. Lot's and lots of levels of details waiting to complicate your intentions. Possibly the best question for @QuantAI-goto deal with is: "Why do you believe that an FPGA is necessary or even appropriate for your particular efforts?" For anyone other than the original questioner reading this I need to make a comment about FPGA vendors. I've used the tools of every FPGA vendor out there and a few who've gone the way of the Moa. Anyone out there remember WARP? It's not unusual for me to be doing a project involving both Intel and Xilinx tools and devices and involve more than one board with an FPGA on it. Assuming that you are already competent in an HDL you have to be very careful about hidden costs and issues that might force a rethinking about how you might implement a particular interface. Intel is especially scrouge-like in terms of allowing potential customers to evaluate a part for a project. You can't create a bitstream for all Cyclone devices these days without purchasing a 1-year license for the tools. Want to use a Cyclone10 LP? Fine, you can use the free tools. Want transceivers or something akin to older Cyclone parts like Cyclone V? Too bad you need to buy license for a version of Quartus that only lets you create a bitstream for the Cyclone10 GX devices. Want to try out a higher end part? Too bad, you need to buy a license for yet another version of Quartus that lets you target any device, except of course those Cyclone10 GX parts. Think that a Quartus license is cheap? Go find out. In my experience some projects can be easily done using Intel devices and their supporting hardware ecosystem but might be way too expensive for other projects. There's much less overlap between what you can do, in a limited budget, between the Intel universe and Xilinx universe than you might hope for. It's mostly due to different marketing strategies. Both companies use a heavy hand in controlling their ecosystems and the low end ( in terms of revenue ) get serviced. Do your homework and choose wisely before spending money.

You're in Luck! Here at Quick-draw Bill's University of Cosmetology, Neuro-Surgical, and Electrical Engineering Arts we equip people for the multi-dimensional skills required by tomorrow's workplace. Sorry... just kidding... haven't finished my morning cup of coffee. So while I can wrap my head around what most of the things you mention might entail I'm still having difficulty figuring out how all them are connected. Fortunately, I'm awake enough to figure out where to start the interrogation. You didn't think that you could come here and get help without an interrogation did you? To me the obvious place to start is by side-stepping the complicated questions and getting straight to business. Why did you decide that a Nexys Video is the ideal board for completing your project portfolio? Is there a lot of video involved? If so I'd recommend spending the extra money on a Genesis2 as the FPGA is much more capable. But really that question is intended only to get you focused on a basic issue. Let's put aside what the FPGA device requirements might be since there's no detail on which to make such an assessment. You obviously want the most performance that you can afford in terms of selecting an FPGA device and will have to settle for designing an application that fits its capabilities. Evidently, you've already determined that and Artix 200T is sufficient for your needs. Perhaps telling us how you made that determination might help you get a helpful answer. As for selecting an FPGA board platform for learning FPGA development or some generic Verilog or VHDL experimentation this is a bit more solvable. First, you need to decide what features your platform requires. Does it need external memory? Does it need Ethernet connectivity? Does it need to be extensible (work with specific add-on boards)? Clearly, you want Ethernet connectivity. I know a little about what's involved in high-speed, low latency trading applications and I can tell you that they don't involve a MicroBlaze and proprietary MAC IP. There are no FPGA boards available for you to buy that are suitable for this actual application. That doesn't mean that you can't do 'deep packet inspection' and try and emulate 'low latency' whatever that means for your demonstration project. It does mean that you should be doing everything in an HDL, that you code by yourself. This implies that you have a very good understanding about all of the layers that make up Ethernet. You should know that what you can do in a particular FPGA device using only logic narrowly crafted for a particular purpose in VHDL or Verilog is very different than what you can do using vendor provided IP with a MicroBlaze. This design flow will use up significant resources of your FPGA device that you might need for actual working logic. In fact, MicroBlaze and low latency are headed in opposite directions. You ask: "what would be the best data/peripheral connection options to achieve high throughput and low latency on this board? Is it possible to extend the board with PCIe?". This implies that moving data between your FPGA platform and a PC is a critical specification. Notice that I left of the part about 'for this board' because I don't think that you're ready to make that call yet. A board with a 1Ge port, DDR memory, PCIe and HSMC connectors for extensibility could be the Cyclone V GT Devlopment board. There is even a possibility for developing applications using that PCIe and I'm betting that you are fairly clueless as to what that entails. That wasn't an insult. That means that there are a lot of things that you need to understand before you decide that an interface is what you want to use. Of course nobody doing high-speed trading is thinking about 1Ge Ethernet except possibly as a debug port, so perhaps 10/100 is adequate for your project demonstration. You'll need to explain yourself a bit clearer here because your choice of words is telling me that you aren't quite grasping what it is that an FPGA does. This is a big problem. You don;t want to start designing your projects to work on a platform that doesn't support its requirements. Rule 1 of selecting an FPGA development platform: Don't choose a board that you hope will meet your needs. Figure out what your project requires and choose a board that supports it. This implies that the first step is defining a project. Specifying the project requirements in terms of hardware. Lastly, looking around for the best fit within your budget.

Thanks, the information is appreciated.

@malexanderIs anyone closer to making the Eclypse-Z7 fan control available to non-Linux application code? Is there any plan to provide a Standalone source for accessing the PMCU registers from the ZYNQ? The protocol isn't supported by Xilinx PS example code as far as I can tell. It would be nice if developers would update the Digilent GIT repository with status commentary so that users would be able to know when changes worthy of going to the trouble of updating the source is appropriate.

Thanks, The FAN isn't a fire yet ( as far as I know ) so I don't need a solution today, but I'll certainly need to turn it on and off at some point. The people who argued that an Eclypse-Z7 Linux OS is a normal use case didn't seem to get the hardware people on board and have a lot of work to do to make that a reality. As of now its only purpose seems to be to connect the Ethernet port to the SDK for running Linux applications from the SDK. For what it's worth, I'd argue for not having a live FS, so that no one can destroy the FS accidently. There should be space available in the FLASH to store inter-session configurations, setting and what have you.

@malexander, Ok, that's something. Currently, I'm doing development for bare-metal applications so I'm not booting into the FS, just booting into JTAG mode. So, how do I control the FPGA fan when there's no OS to run decutil or any other application/utility? On the subject of permissions; it a real hassle having to do 'sudo systemctl poweroff' and then have to type in a password just to shut down the OS before hitting the power off switch. I can only imagine the debates that went on while developing this product; and am happy not to have been involved. Still, the result is an OS that doesn't seem to know what it exists for, at least on running development code, and a board that can, in theory, support bare-metal, Xilinx RTOS, or other configurations. As of today, I find the Eclypse OS as more of a distraction than a platform for developing applications. Lot's of disconnected appendages in the Eclypse-Z7 ecosystem. You don't have to work to hard to confuse me but I have a distinct feeling that I'm not alone here. Regardless, of application I need to be able to run the FAN. P.S. Juggling various Linux, Xilinx and other platforms while working on multiple projects might be fun for software guys but it really is a headache for poor old me. Debian might be mother, but her offspring certainly don;t play well together. Let's see, is it ifconfig, no wait what am I running at the moment? ARRRRG!!!

I have yet to hear the FPGA fan run on this board. The documentation and even schematics are confusing as to just how this is supposed to work. Can anyone shed some light on this and indicate if the FPGA fan is currently supported? Clearly control is tied to another header and involves a controller external to the FPGA.

It took me less than 10 minutes to download the archive from this thread to my Win10 box and create a bitstream. At least try it out and let me know what you think. After 2019 all of my Python 2.x code will become depreciated so it may be awhile before I do a rewrite.

I knew that there was some confusion when I saw OOB... just didn't get the specifics correct. This project is referenced as a Community Project with link in the CMOD A7 Resource Center. The OOBs from Digilent typically use the MicroBlaze board design flow. I don't unless the target is a ZYNQ based board. My project isn't in the Digilent GIT. Download CmodA735tDemoR1.zip from the top of this thread and try it out. I have a nice Python script to interact with it and reasonable documentation. Read the README.txt in my project to see what it does. Compare the flow for both projects and compare the resource usage for both projects. My project wasn't Vivado version dependent until Vivado 2019.2 came along but as mentioned on the first page of this thread still works albeit with a little extra effort. I'm not sure how you conflated Digilent's project with mine; but that doesn't really matter... I still think that mine's more useful. You can use the dcp as a source in your own project using this one as a guide. If I'm a bit shocked by anything, it's that the latest verison of Vivado still works with a dcp created in Vivado 2015.

require Well, I'm happy for you but what you built wasn't this project. I don't use Microblaze. You might want to go to the top of this thread and download the zip file and try out my project as an alternative. I just downloaded the archive file from the Digilent Project Vault to my WIN10 box and built it using Vivado 2019.2. I just had to create the MMCM component in Vivado 2019.2.

I appreciate that argument. I try and avoid providing executable programs, text source using embedded scripts, and anything depending on tools having the letters JAVA in it for the same reasons. From my perspective, providing a constraints file that can be read and checked plus source HDL is the safest thing for everyone. You should be in the practice of checking the post place and route pin assignments for all new project bitstreams regardless. Even if you think that you are using a constraints file with valid location and IOSTANDARD assignments things happen....

There are other posts dealing with using the NMV. Be careful as once you have something in your FLASH device that starts the configuration process you can find your module appearing as a bricked board.

You are correct that Vivado 19.2 has broken IP from previous versions. I'll try and create a release for Vivado's latest. Meanwhile, though I haven't tried it yet , I expect that if you create your own MMCM using the Vivado 2019.2 IP Wizard you should be able to build the project using the other sources.. I prefer that users create their own bitstream. NMV ???

Everything needed to create a bitstream is provided. A couple of the HDL source is provided in the form of a dcp file. Are you having trouble creating a bitstream? ISE doesn't support the Artix 35T device.

I suppose that the first part of this sentence is a pass for the second part but I still had to wince at reading it. You can have storage using combinational (un-clocked) logic. If a synthesis tool decides that your code requires storage it will infer a latch; and provide a warning that it did so. The warning indicates that inferred latches are generally bad. One problem with learning your first HDL on your own from a book is that you might be tempted to use keywords without understanding the ramifications of your choices. There is a place for variables and := in VHDL, but not for assigning values to logic elements like std_logic or std_logic_vector. A problem with offering a critique of code in a venue like the forum is that it's easy to provide advice that, while addressing an aspect of poor coding might cause more confusion than solution. There's only so much space and time for posting coding critiques and too often an attempt at making it concise and easy it ends up being misleading. My point isn't to criticize hamster or anyone posting code; it's to suggest that there are better ways to learn how to use and HDL effectively than this format provides.

Well you get points for doing some research. I suggest that you start with reading the Xilinx literature for the ZYNQ device on your board to see how the PS and PL connect. Then look at the schematic for your board to see what the various interfaces connect to. If you look on page 8 of the Arty 7 schematic you'll see that the DDR and UART signals are connected to PSxx pins or PS_MIOxx pins; that is to the PS. A few ZYNQ boards have DDR and or Ethernet connected to PL pins but most like the Arty7 have all of the user interfaces connected to the PS. SO... tying off the PS and just using the PL, something that is possible by the way, is going to be difficult for what you want to do. Neither the UART or DDR for the Arty 7 are connected to the PL. It is possible to create a program running as a bare-metal application to service an AXI connection between some design in your PL and the PS to allow you to connect a TTL USB cable to PL pins to a UART in your design. There are a number of options for building proper AXI interfaces to your PL HDL code and I like to use BRAM. Since your interface is a UART a DMA interface seems a bit extreme to me on face value... but I haven't tried to do this. My personal preference for ZYNQ designs is to have the bare minimal board design functions needed to connect the PS to the PL. I then use the HDL entity or module created by Vivado representing the board design as a component in my toplevel HDL design file where all of my real design goes. I'm not quite understanding what exactly it is that you envision as the layers of hardware involved but you can't read/write directly to DDR from either the PS or the PL. Both have external memory controllers that are quite complicated, though on the PS side most of it might be something that you can ignore. Perhaps starting off with a simpler design concept; like creating a bare-metal PS application to read PL registers for address, write data etc and write other PL registers like read data. Given typical UART speeds a polled service should be usable. That project will be more than enough to keep you busy for a while. I'm curious as to why you would want to do a ZYNQ project without the ZYNQ.

I assume that you mean that you implemented a scrambler in the PL. If this is the case you need to add some IP provided by Vivado to allow the PS to pass data between the PS and the PL The PS will communicate with the PC uart using software and the PL logic will handle the communication between the PS and the PL using the interconnect There are a number of ways to do this. If you look in the IP Catalog you will see a variety of AXI and AXI-lite possibilities to allow your ARMs to pass data to and from the PL and your logic. You can't bypass the PS uart resource connected to the connector and send the signals to the PL directly. The easiest approach would be to use something like the AXI_GPIO IP, though you won't be connecting the signals to pins ( just logic ) The IP Catalog doesn't make finding all of the IP easy so keep expanding all of the categories until you find it. Once you export your hardware design to the SDK it will write a driver for you though you will still have to do some software development to create a complete application. There are a number of tutorials showing how to do this. So the steps are: add the AXI peripheral interconnect IP of your choice to the board design schematic and generate the design build a new bitstream configuration file export the design to the SDK create an application that gets data from the uart and sends it to your PL scrambler then reads the output and sends the result back to the uart. You will have to figure out a few details to make it all work but the tutorials should help with the basic concepts and using the tools. [edit] So I just realized that the previous steps are not quite right for you. I would have Vivado create an HDL to encompass the board design and then instantiate that into a toplevel design of my own that instantiates the scrambler. I think that what you are supposed to do is create your own scramble IP that you will integrate directly into the board design ( not use a standard AXI interface as I mentioned..) This is a bit more complicated than how I'd do it but there are tutorials on how to create and add IP to your own IP catalog. To anyone else reading this thread for help in a similar project. This is a good example of why the Zynq isn't the best platform for all FPGA projects. You can do this project with a CMOD-A7 without the hassle and complexity of the board design and SDK. If this were a product the Zynq device would be too costly to be viable in the marketplace. As a project that makes you learn how to do the basic Zynq development flow it's a pretty good project. [edit] Personally, I find the whole IP creation thing to usually be too much trouble for the benefit, though I could see where I might want to do this. Sometimes it's good to learn how to do things that you never have to do...