zygot

Hmmm... thanks for the information, you just won me a lunch bet. Perhaps you can answer this question. Why is it that people who have time to engage in unproductive nonsense can't use the time to provide useful help. Here's a suggestion. Instead of posting snarky remarks, just paste one of your AXI master Verilog source files here with a brief description of how you used it. That can't take up much of your valuable time and could help the average user grasp the topic.

I've been involved with as an employee or contractor with a awful lot of companies using a very diverse range of technology. I've yet to meet anyone who's mastered all of that limited set of technology. That doesn't mean the everyone I've met is an idiot or incompetent; it just means that none of them have mastered all of the those technologies. Early TV, the CD player, LTE and 5G rely on very complicated and often non-intuitive concepts and conjectures to work. Very few people have an appreciation for the tricks and details involved. Yet everyone has used them. Thinking that you understand all of the underlying principals of technology doesn't necessarily mean that you are smart, perhaps just not knowledgeable, nor does it make those who know little about them stupid. I welcome challenges to things that I post on but I'm not too happy with assertions of competence or non-competence. If you think that I'm wrong about any of my assertions please post a reply; but be prepared to back up pure bluster with some evidence. I rarely direct my posts to seasoned expert engineers because these forums are for beginning users. The purpose of the forums is education and enlightenment, and perhaps to steer those with little experience toward a more fruitful path. The original question was about connecting a ZYNQ PS to the PL so I don't think that anything said so far has been off topic. Yet, I think that it's necessary to state what should be obvious.

Really? I guess that you missed what I posted above concerning the SmartConnect that Vivado insists must be used with it's own IP, using it own preferred design flow. Well, yes using AXI usually does end up using gates... and the need for larger and expensive parts, which is the whole idea. Can you write your own AXI IP and minimize slice utilization? Of course. Will anyone using the preferred board design flow have similar success? Not a chance. I've written and packaged my own AXI IP which has served the purposes of the project that I've used them on so I'm not just expressing gas on this topic. I'd modify your words to say that if your design uses a lot of gates then you're probably using the tools as Xilinx or Intel would prefer you do. So, I'll direct the same challenge to you as I did to @D@n, post a demo project showing off your AXI prowess for the typical Digilent Forum reader's benefit for everyone to admire and learn from as well as see how trivial it is. Dan didn't reply to my explicit mail invitation because, as far as I can tell, he's never actually done a complete ZYNQ HW/SW design project and has a few holes in his understanding of what's actually involved. Calling other people idiots is easy. Directing readers to blogs that don't actually resolve a complete design that can be replicated is easy. Posting projects to the Project Vault with source code is useful. So, put your integrity where you mouth is.. show us what you got. ( I'm pretty sure that I've avoiding degenerating into the abyss that our first dialog sent us to but if not someone will be in touch ). A demo is worth a lot more than idle boasting. For what it's worth, I never stated that AXI is bad. If a vendor is selling a micro-controller with a general purpose external bus interface knowing that adding programmable logic isn't likely a viable customer option, then sure an overly complicated and general purpose bus that the customer can hang high-performance and or low-performance logic onto makes sense. If the micro-controller is embedded into a large FPGA device then this make a lot less sense for the customer at least. At least provide one high performance simple connection between the PS and PL that doesn't serve a myriad of purposes; especially when there are so many other AXI paths provided. I'm just suggesting that the reason for not doing that has nothing to do with technical problems that ARM can't resolve.

Hmmm, I guess then that you'd suggest that Intel and Xilinx ( or it's new owners ) had better find a new occupation because they are purveyors of some really bad and or buggy AXI IP. I'd say that this is evidence that you don't have to be an idiot if you struggle designing with it. Let's face it most of the questions asked on this forum aren't from expert and seasoned FPGA developers. Yes, you are correct that there's no mystery in AXI or AMBA specifications; they are freely available. But I'd have to disagree with the notion that they are trivial to work with. The truth is that they are overly complicated and inappropriate for most FPGA design applications, unless of course they are required as is the case with FPGA devices having a hard ARM core complex. Both Altera and Xilinx could have provided a simpler and less complex hose between the PS and the PL but they chose not to because they are in the business of selling gates. If AXI was so trivial you'd think that companies who's income depends on it woulf be able to do a better job with it. While any of the AXI versions might not be excessively complicated that doesn't mean that only idiots design bad AXI based logic and applications. In my experience it's rare for an FPGA designer to design logic to use an interface in all of its permutations and capabilities, unless they happen to be in the IP selling business. When creating IP with partial functionality it's sadly not uncommon to find that things were missed. This is more about professionalism and a commitment to robust design over making money. Good engineers working for bad companies usually don't do good engineering. While am on the subject it isn't just bus specifications that some users might find intimidating, basic concepts like clocked logic and resets are done poorly in many designs that I've seen. Some of us can do something about that and some of can't.

So have I. I've also had experiences with the same device giving me about 10 KB/s. The difference is due to a number of factors. My point is that assuming that the best measured data rates are typical or guaranteed for any application is a bad idea. This is due to the protocol, the drivers, the OS, the software application, etc. A great way to kill your data rate is having to require packet termination. USB isn't overly complex but I've run into more than my share of surprises since I've been developing with it.

Well, I'll offer one way, which is how I do ZYNQ designs. After creating the board design and generating the output products I tell Vivado to create a wrapper file in the project HDL, typically for me in VHDL. This wrapper then gets instantiated into my own toplevel entity where I can connect to any exposed signals that were made external in the board design. Usually, Vivado attaches IO buffers to these signals but will remove them and spit out warnings that can be ignored. You can look over an example here: https://forum.digilentinc.com/topic/20299-fun-with-phasors/ So, in your schematic above the first thing to do is make your UART signals external... [edit] I forgot a sentence that I always add: When you have Vivado create your wrapper file make sure to de-select the default option that lets Vivado manage the wrapper code. You want to manage this to avoid unnecessary fights with the tools.

I recently posted a demo project in the Digilent Project Vault using an 8 pin pseudo-ram device. One of the platforms that I implemented the ram IP on was the Zedboard. You might find this interesting. On the CMOD-A7 with a UART user interface: ram IP used: 49 slices, 128 registers, 146 LUTs user interface used: 134 slices, 146 registers and 238 LUTs For the Zedboard I used the 'preferred' board design approach to have 2 BRAM controllers and 2 BRAMs, 8 32-bit control registers and 8 32-bit status registers using my own ZXI IP that I did many years ago. Functionally, the CMOD and Zedboard demos did the exact same thing ( note that I wasn't using the BRAMs in this implementation ). Here's the damage on the Zedboard: the 2 BRAM Controllers used: 186 slices, 412 registers, 405 LUTs the ram IP used: 52 slices, 129 registers and 150 LUTs the control registers used 51 slices, 159 registers and 57 LUTs the status registers used 41 slices, 161 registers and 39 LUTs the SmartConnect that Vivado added to the board design used: 2627 slices, 8639 registers and 7425 LUTs For the first iteration of the Zedboard implementation I had only 4 32-bit registers using the Xilinx AXi GPIO and all of the AXI utilization was significantly worse. You can make of that what you want. One way to look at it is why worry about resource usage when your design doesn't need more? The other way to look at it is for a complicated design will Vivado leave enough resources left for my design after the AXI interface is implemented? Or perhaps more importantly, if I do a design that fits today and tomorrow I want to add functionality will I be able to do it with on the hardware that I started with? The last one is a question that those in industry need to consider.

@D@n, I sent you a message.

I don't object to saying that writing an AXI master is 'doable', but I'd say that doable a relative term. From what I've read about the work that @D@nhas put into understanding the AXI bus specification and FPGA vendor implementations I'd say that this is no trivial endeavor. I'm always loathe to assert that something can't be done, seems like a guaranteed way to lose a bet. On the other hand betting that specific individuals couldn't do a robust job at it might be a good way to earn beer money. You don't need to use AXI bus DMA functionality. The ARM complex has a software programmable DMA engine that can be used nicely with PL BRAM. Writing an AXI master or slave in an HDL is one thing. Packaging and integrating that IP into form that can be used seamlessly by the FPGA vendors' HW/SW tools is another. So @D@n, what's the chance of seeing a compact demo of your IP that does that and can be replicated by user's of this forum using Vitis and Vivado? I'm absolutely sure that more than a few readers of the Digilent Forums would find it to be interesting and useful.

If you want to use USB as a data transport the place to start is with the specifications. There are some interfaces where the specifications are unavailable unless you pay to become a developer. Fortunately, for Ethernet and USB 2.0 and USB 3.0 at least this is not the case. If you don't have a basic understanding of how the USB protocol and physical layers work you are in for some tough sledding. Fortunately, the Nexys Video is a pretty good platform for experimenting with USB. It has an FT2232H that can use FIFO mode and an FMC connector that accepts USB 3.0 development mezzanine boards form Cypress or FTDI. I've used all of those options on the Nexys Video. Digilent has a Adept library for using the FT2232H in what they refer to as DPTI mode. I've seen up to 30 MB/s on it ( I modified the eeprom to do synchronous 245 FIFO mode and do NOT recommend this; read all of the pleas for help on this web site from those who did this foolishly ). With USB the 'up to' is always a required modifier when talking about data rates. There are a lot of factors that affect sustained or average data rates in the software layer of USB before you even consider OS kernel behavior. You don't have to use Adept to use the Nexys Video or Genesys2 FT2232H, though I'd advise starting with that; you can write PC applications using FTDI libraries. You will need elastic storage, usually provided by FIFOs, if you want to guarantee some sort of baseline sustained data rate, One tip when working with USB is to avoid sending partial data frames. Understand that streaming data is different than transmitting data. Cypress and FTDI both have application notes that are a good adjunct to the specifications. Both offer inexpensive USB 3.0 evaluation kits that work on the Nexys Video using the LPC FMC connector. The Cypress FX3 uses an embedded ARM processor so it is a lot more flexible, and a lot more complicated to develop with. FTDI tends to be a little less helpful than I've wanted it to be when running into problems. Yes. a better question would be 'Is this likely to be a good approach?' That answer is a bit harder to come by. It depends on how much time and effort you are willing to put into it. You can find all of the relevant Digilent demo projects... if you you come across one let me know. If taking the time to read and grasp the basics of the USB specification seems like a big ask, then the likelihood of success is low. Beyond the specifications and software behavior it takes a lot of experience to understand. I've done quite a bit of experimentation along these lines with no object other than to get a sense of what might work.

Unfortunately, the FPGA vendors have decided that this has to be a very complex and challenging thing to pull off, even though it should be trivial. The best way to connect the PS and PL would be to write your own AXI slave or master IP. This is difficult and beyond the scope of many peoples ability. FPGA vendors like this arrangement because their limited function AXI IP uses up huge amounts of PL resources and confines many within the walls of the IP garden. Putting aside questions as to why you'd want to do what you propose here's one perspective. Generally, in order to connect the PS with the PL you need to use the AXI bus interfaces provided in the ARM hardware. There are exceptions and a simple UART is one of them. The PS has a lot of interfaces that aren't being used on most ZYNQ boards. One happens to be a 2nd PS UART. You can 'export' the spare PS UART through the EMIO through the PL. Normally, one would connect EMIO signals to PL pins but you can just connect the TxD and RxD to logic in your PL. From an HDL point of view there are alternates to complex AXI infrastructure. You can instantiate a BRAM controller in your board design and add a dual clock BRAM with one side exposed to the PL. Your HDL just uses the BRAM as normal and your PS can do read/write operations like any other memory connected to the PS. You are still wasting PL resources on AXI infrastructure but it does ease your PL design burden. While if makes no sense to me I understand why it might be tempting to have a design with an embedded hard ARM processor complex and an additional soft processor in the PL. Conventional software design is just a lot more familiar and comfortable than logic design. The FPGA vendors know this too and will make you pay an exorbitant price for the convenience. But that's the way technology has always been; fast, cheap, simple, convenient has always been over-priced. Here's a suggestion. Ditch the ZYNQ board. Buy an FPGA board like the ARTY-A7. Learn how to design logic in the HDL or your choice. It's like learning how to break horses. The first attempts will be a rough ride, but eventually you will end up having a greater appreciation for horses and a usable skill that doesn't rely on crutches like a MicroBlaze....

Say what? If you're still probing for an easy solution to seeing those LEDs and the VGA doing something useful, I'm not the guy you want help from. I'll encourage you to learn proper FPGA design using Verilog or VHDL, or any other HDL that appeals to you and is supported with your tools. If you look around there are demo projects available that will help you with those elements, but most are MicroBlaze and canned IP based. You are better off learning how to make you're own IP and understand basic design concepts. Those displays are ISE era technology. ISE was distributed on 1 DVD for all supported platforms and can do HDL designs every bit as good as Vivado. Moreover, Vivado has depreciated some interesting Xilinx. There were releases of ISE that were so bug riddled as to be worthless, but version 14.7 was not one of them.

I still use ISE for Spartan 6 and occasionally for Kintex as, for some projects, ISE is a lot less frustrating than Vivado. 90% of my projects are all HDL.

The Spartan 3 family is not supported by any version of Vivado. You will have to use ISE. I have a vague recollection that the last version of ISE available in the Xilinx archives doesn't support all of the Spartan 3 devices either so you will have to do a bit of research. The last ISE 14.7 distributed by Xilinx did support you device.

You definitely need to use the Eclypse-Z7 and ZMOD timing constraints. You shouldn't get failing timing paths for the Digilent demos.

To emphasize the importance of ADC users knowing how to interpret ADC output I'll add that constraining an input signal to half of the ADC range, say by halving the signal input amplitude and introducing a 50% offset so that you only get positive output values from a signed ADC, you are turning your 13-bit plus sign ADC into a 12-bit plus sign converter; you just aren't using 50% of the ADC range. In other words you are losing the msb, not the lsb. If you have to throw away bits, you want to toss the lsbs. The Digilent ADC and DAC Zmods are nicely designed SYZYGY pods, but before you can use them effectively you need to trace through the entire signal chain, starting with the converter, though the analog conditioning front end, through the software drivers to know what's going on. Otherwise, you are in for some bad surprises.

Nope.... Read the datasheet for the ADC to see how the output data is formatted. Ok, for the ADC ZMOD the question as to how you should interpret the output data is a bit more complicated... but the place to start is with the datasheet for the AD9648. These kinds of questions belong in the FPGA section of the forum.

There are subtle but immense differences between coding for a processor and programmable logic design so it's easy to get confused. There are a lot of new conceptualizations that need to replace older ones and the amount of knowledge needed to be competent is considerably larger for programmable logic. I think that the effort is well worth it. If you were an obese 50 something who never did any exercise it would be unrealistic to decide on a Thursday to get ready to do a triathlon on Saturday. Same idea with logic design. Here's some advice suitable for most people: Take your time and don't let your imagination set too difficult goals. As you learn, the universe of unknown expands Master concepts in small steps before adding new ones. I suggest that even beginners start with the HDL design flow rather than the GUI 'drag and drop' board design flow. But this really depends on how far you want to go. In ancient times, the days of Z80, S100 bus, 6502 etc., even processor coding was a mysterious art. People got together and formed clubs because learning as a group is always easier and more productive than learning as an individual. Those groups started out pretty informally.... You should start off with minimal investment in hardware, like the Arty A7. Here's a dirty little secret. The latest tools are not the best or most appropriate tools. New versions include new bugs and don't necessarily fix old bugs. Currently, Vivado install weighs in at 40+ GB. Older versions of Vivado might be better suited to your board in that available demo projects for it just work. A version of Vivado that dates to approximately when the Arty A7 first came out is probably the best one to start with. It's certainly a lot less painful to install. I only try out the newer versions of tools from FPGA vendors if I need support for a new device. The ARM based FPGA devices are a bit different in this regard but I encourage beginners to start with the non-ARM devices.

Welcome to the world of FPGA development. The AD776x class of converters are pretty nifty for the right applications. I've done what you want to do for the AD7761 EVM, which is the AD7768 16-bit little brother, for the Nexys Video and Genesys2 boards. At the maximum 256 KS/s conversion rate across 8 channels for the 24-bit converter AD7768 this works out to about a 6 MB/s sustained streaming data rate. Getting this to a PC will be a bit more challenging on the Zedboard as you'll need the Ethernet interface. ADI has some pretty good FPGA support for its evaluation boards but I wrote my own HDL. I suggest that you use the HDL design flow. The Zynq for a project like this just adds unnecessary complexity.

You are free to use published source code according to the terms of the license, assuming that such terms are part of the source file. Published demo projects using the board design flow are also free for use in personal designs. Of course if you publish a design of you own that borrows from others it's proper to credit their contribution.

@Greatzwall, @JColvin I think that there's some confusion that needs to be cleared up. I didn't publish the 4 channel XEM7320 ADC design as it doesn't use a Digilent FPGA platform, and because the design requires proprietary Opal Kelly pre-compiled HDL net-lists for the configuration/USB interface. Also, the software application was based on an Opal Kelly DDR test demo. The stay tuned reference I made in this post does relate to a project that I posted in the Project Vault here: https://forum.digilentinc.com/topic/20331-more-fun-with-phasors/ This also uses the XEM7320 with one DAC ZMOD. It was posted as an alternate implementation of this project: https://forum.digilentinc.com/topic/20299-fun-with-phasors/ which is Eclypse-Z7 based. Functionally, those 2 projects do the same thing. The XEM7320 is different in that the entire user experience involves running one software executable ( windows only at the moment ). The Eclypse-Z7 project involves a somewhat unusual configuration process and waveforms can be changed form within an OCTAVE script. Neither project includes the complete HDL code but both include enough information to serve the purpose of the projects. There were a variety of reasons for doing this. I'd be happy to answer specific questions to anyone who wants to duplicate any of the projects mentioned here or in the Project Vault.

Do you mean that your design constraints uses the 1.2V LVCMOS_12 IOSTANDARD for your outputs? I hope that you aren't using external pull-up resistors to 3.3V on your outputs. Did you intend to say that your constraints selected internal pullups to Vccio? Did you make sure that you properly set the Vccio bank voltage for your FMC IO to 1.2V using the pins described in the Nexys Video Manual?

Hi, can anyone tell me what's happened to this board?

Intellectual Property is in the eye of the beholder. I'm inclined to agree with @JerryGthat there's nothing to see here folks... but only Digilent can make the decision of whether or not the missing schematic page has a value in bad will, that is exceeded by whatever information is being withheld by a schematic page. I once worked for a small company that was owned by a very large international conglomerate. Boy did they love patents. The fact that all of the patent ideas that I saw didn't work, weren't part of any actual product, or was simply a bad idea or not defensible if challenged in court doesn't matter. Patents are playthings of lawyers who generally can't or don't bother to assess their worthiness. They make the same money on both ends of patent fights. If your company has 10000 patents and you get into a fight with another company with only 1000 patents you might be able to use them to make your opponent blink... if you are a good poker player... but in general civil law is won by whoever can give lawyers the most money.

I'd like to have my application change things like fan speed that aren't written to non-volatile memory, i.e the default settings appear after a power off/on cycle, and I want them only to be active when my application is running... or at least until power is turned off. The example code changes the power on settings. I wouldn't want to set a SYZYGY port Vio override and have it come up the same next power up.