zygot

Mull over your sine LUT. BTW, why did you replicate 2 cycles instead of just using 1 in your LUT?

I glanced at your code. The lines like this one bother me: new_val := dac1_accum + sample - 2048; I wonder how Vivado implemented this. Usually, in my experience a better way to do this is to pipeline so that each '+' operation is performed on a separate pipeline version of the signal. From a coding viewpoint it appears to be straightforward. From an implementation viewpoint it looks like you have in implied latch, at least. Regardless, you are trying to perform 2 add or one add and 1 subtract in a clock cycle. Even for a quick prototype exercise this isn't a good idea. Sometimes our HDL code gets written by the parts of our brain wired for C. It's dangerous.

Measurement technique is certainly critical to successful analysis of how your hardware is performing. So is the selection of test equipment. I see that your most recent plots show a high DC component. As Sigma-Delta Modulators aren't DC accurate is appears that your are trying to do measurements using direct coupling. An AC coupled load would seem to me to be more appropriate. This raises the topic of source and load impedance.

I can confirm that the example can indeed change the Eclypse-Z7 fan settings. Just curious, is there a way to turn control aspects of the SYZYGY and support hardware that doesn't get stored, that is that doesn't survive a power off/on cycle?

@malexander, I don't know when these issues were fixed but I'm working with repository source that I got 2 days ago. I think that the bigger issue is that whoever is writing the code isn't testing it on actual hardware. So, is it your belief that the dpmutil code example and dpmutil code have successfully changed the FPGA fan on real hardware? Creating lots of branches on git is a bad idea since it's hard to tell what state the underlying dependencies are. That and the utter lack of commentary for both code changes, git submissions, and the Digilent git website. It can;t be easy for your developers and it sure as heck is a pain in (**a lot of places**) for customers to deal with. Digilent needs an adult to supervise its software development, especially if you want to keep working engineers, who have their own problems to solve, interested.

Yeah, there are problems. I guarantee you that whoever wrote the example code never bothered to test the 'setfancfg' command.; the command parser rejects any command line with an 'a' in it... But fixing that doesn't solve the problems.The enum and getinfo commands do appear to work. I tried setting the fan from my Eclypse-Z7 application project without success. I then created a project using your example and that doesn't work either.

Thank you Michael.

@malexander Hi, It's been a while since you scheyduled a fix for the EclypseZ7 fan for bare-metal applications. Any progress to report? Last I checked the Digilent repositories are still being updated with no commentary as to what's changed and that's a big problem for users.

Final thought. Though reading FPGA vendor literature is a good idea before trying to design a project, if you are going to connect your FPGA IO pins to things it's a also a good idea to educate yourself on specific logic standards. You can pretend that FPGA development is just another kind of software development, at least in the beginning of your own development, as long as everything stays inside the device. Once you start connecting pins to other devices you are doing digital logic design and there's no pretending anymore.

I stand corrected, and didn't take the time to look at the schematic. Thanks. On the plus side, now that I've been shamed into being a bit more responsible, and seeing the Arty A7 schematic, it does look like your choice of IO pins means that the standard habit of Digilent IO using 200 ohm series resistors isn't a concern. I guess that I wasn't thinking that the fact that termination as a requirement for differential drivers isn't obvious. Think of them as similar to Open Collector (Drain) or ECL PECL. In my defense UG471 does say "requires external 50 ohm pull-up resistors". It mentions termination on the inputs but as @asmi has pointed out differential drivers don't do much unless connected to proper termination ( input or not ) as the termination completes the driver circuit. BTW, when the receiving end is powered by a different Vcc than the driver you can get into trouble if Vcc for both the driver and receiver aren't powered on simultaneously. This seems to be somewhat of a shortcoming for a video standard where monitors are usually different equipment than video source equipment, each with their own power supplies. Still, you can and should design your circuit for such eventualities. Driving current into your FPGA IO bank Vccio rails through IO pins isn't desirable at all. Silly me, I thought that UG471 had a termination diagram for TMDS33... I seem to have gotten that wrong. Apologies.

You can figure this out for yourself by going back to the first step of your project. This was reading the Series 7 Select IO User's Manual. Pay attention to the sections on TMDS33 IOSTANDARD, particularly study the termination diagrams. Then look at the schematic for your board and see if you can follow them. Are you driving your sys_clk_p and sys_clk_n on clock capable pins? While you are getting the Select IO User's Manual take some time to brows through the Series 7 Clocking User's Manual.

Stay tuned to the Project Vault forum. Now that Digilent lets me play with well designed modules that do conversion between the analog and digital realms with a reasonable bandwidth on Xilinx hardware there are all sorts of fun ideas to explore.

What's better than an AXI Master Virtual FIFO for moving large quantities of data from an interface, like say 64 bits of 100 MHz ADC data , into DDR? No standard busses. Which is what I did for this project. It's just straight-forward HDL. There can be a case made for AXI, AMBA, Wishbone, or whatever but if I don't need any of the complexity of such a bus what good is it? Why would I want to worry about beats, bursts, boundaries, and a lot of other details if all they represent is unnecessary complexity and obstacles to achieving the best solution for my particular design problem? I wouldn't is the correct answer. If my target platform was ZYNQ based, like the Eclypse-Z7, I might want to experiment with your virtual fifo master AXI design; but only if I could use it with the FPGA vendor's SDK tools to write the PS software end of the application. Since you don't know how to do that I'm having a hard time convincing myself that the reward is worth the effort for me to figure out how to do that. But I do respect that you worked out a good answer to one question on a three question test. What is that.. a C- on the curve? [whenever a prof gives a three question test in which you only get points for a completely correct answer you know that the purpose of the test is to convince most of the class to find another major] But your post does suggest the need for revisiting a few issues of why ZYNQ isn't always the best platform for FPGA designs. The purpose of this project is to capture lots of data for post-event analysis. If the application was for an embedded self-sufficient device sitting on some mountain collecting and analyzing specific data I'd probably** want to use a ZYNQ device. For this project that certainly isn't the case. Though this was a 'proof-of-concept' project just to prove that it could be done, it turns out to be a pretty useful tool that can be used or modified easily for other projects. By the time you are waiting for Vivado to start up the SDK and update the workspace I can execute a single program on my PC that configures the FPGA and captures all fo the data, and save it to my HD. Well, not you since you don't use those tools. So, it is possible to create a ZYNQ HW/SW application that uses the Ethernet port, as a user and data interface and can do a partial configuration of the PL to support one of a number of different PL specific applications, and execute it. If you want to run multiple of these applications simultaneously that becomes a harder problem to solve. If you want to make your life easy and use a lot of generic open source code to reduce your software design burden you will likely try using a Linux based OS. For something like the Eclypse-Z7 this is problematic for a number of reasons: Since you only have 1 DDR memory attached to the PS your AXI pipe(s) between the PL and the DDR has to compete with the PS for access. Your OS wants to use a significant about of the DDR leaving little for large quantities of data. running your fancy multi-core ARM code out of a relatively low speed SD card is problematic. Developing and maintaining ZYNQ HW/SW Linux applications is complicated and hard to do. The first problem to resolve is finding the ZYNQ platform that is designed in a way that allows you to do what you want. This is certainly not impossible. Finding one that's affordable might be. Instead of thinking about AXI when you read this post you should be thinking " Hey using very little resources and using no embedded processor development at all with easily verified and maintainable HDL code can do some interesting things!" Back to the Eclypse-Z7, assuming that this is the target. It doesn't matter how good your AXI virtual FIFO is, it isn't going to compete with my VHDL/Verilog Artix A75T implementation. And this was a lot easier to do, even with having to figure out a lot of Opal Kelly specific stuff. It's also a lot easier to use. If you absolutely need ARM cores and AXI then you have to put up with the extra hassle. Most of the time, for desktop or lab projects you don't. [edit] ** Emphasis on probably because there would have to be compelling reasons to justify using an ARM based approach. I would certainly do a cost/benefit analysis first. ZYNQ is great for some applications that require an embedded processor with floating point hardware. It's an impediment for those that don't.

An update. I did manage to get the Eclypse-Z7 to put out 4 DAC channels. Again, I used the low level controller HDL provided by Digilent to jump start the design. Instead of using the Digilent AXI and SDK support code I re-purposed a previous Eclypse-Z7 test project using BRAM to communicate with my PL HDL. Instead of waveform lookup tables to drive the 4 DAC channels I used my own NCO IP. With the NCO I can get nice sinewaves from a few hertz to a few MHz by writing 1 32-bit word to the IP. But, I got what I needed in about a day's worth of effort instead of wasting weeks trying to unravel the mystery that is the official Digilent ZMOD repository. As anxious as I am to create a few interesting demos for the Eclypse-Z7 I'm hesitant because the product has such poor support. There is still no way to control the FPGA fan from a bare-metal application and the Linux support still can't do basic things like configure the PL and run an application....

Geez, I forgot that the baremetal DAC demo only drives one channel of a two channel DAC. It's not encouraging when a product vendor can't even figure out how to demo their own products satisfactorily... perhaps buying another DAC ZMOD isn't such as swell idea after all. There are easier ways to get the job done.... SIGH!

If I forget to set the ADC gain calibration to something other than 0 I remind myself of a really quick and fast way to initialize 1 GB of DDR to all zeros. Sometimes this is helpful and sometimes not so much...

Yeah, because I'm a salmon in a bathtub when it comes to writing software. Frankly, hopping back and forth between HDL and C doesn't seem to be getting easier with time. I tend to like text based data files for debugging or development because for one, I can usually spot most things that are wrong in NotePad++, and two because I don't have to write a GUI application to render data into a visual format. With graphics application software I'm more of a toad in the toilet.... Of course when it becomes necessary I can put in the effort to do all of that if it becomes an important tool that I can reuse. Otherwise, I tend to make do with what I have readily available. If this project was a full blown complete application I'd have to either format my data to be used with scope waveform viewers or write my own application to handle somewhat large datasets involving plotting, scrolling, zooming etc. Not today. OCTAVE is pretty well written and current so it turns out that, while it might take 20 seconds to read in a 13 MB text file into memory, slicing the matrix and plotting manageable segments is both quick and a workable solution... for now.

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.