zygot

Most readers of the Digilent Forums are aware of nVidia's recently failed attempt to purchase ARM Holdings. Most are aware of the successful purchase of Altera by Intel many years ago, as well as the more recent purchase of Xilinx by rival AMD. ( Did anyone not see this coming? ) Some of us have been in suspension waiting a very long time to see what Intel will do with it's new FPGA/ARM vendor franchise. Perhaps we now have the answer: Software Defined Silicon (SDSi). Speculation is that this is start of a new paradigm in how a few tech "overlords" will control the future. Of course, no one knows the future for certain. But knowing the past isn't all that difficult, though perhaps interpreting the past correctly might be challenging. The new paradigm is that instead of making one design that has features disabled or hobbled in order to confuse customers and users and optimize profits, we will now will have computer chips with hardware that the primary vendor can change, on the fly, in situ on end customer product.. for a price of course. So what do readers of the Digilent Forum think about the (probable) future? Should CPU/GPU vendors be allowed to own programmable logic companies? How do you see the future for companies relying on FPGA devices dependent on the tools owned by direct competitors? Can anyone see a potential flaw to having a "fluid" HW capability in high-end computing platforms connected to world wide network that is increasing being abused by criminal gangs and nation states for nefarious purposes? The Linux Kernel has been increasing its support for "non-static' hardware platforms in recent years, much to the relief of ARM based FPGA product vendors. Of course, not all computing platforms are Linux based or open source. ( Just thought that I'd toss this thought into the mix ) I've seen a depreciation of support for the HDL flow by all programmable logic vendors in recent years in the tools. I'm not optimistic. I hate to think of what companies like FB are imagining. Nothing gets imitated more than a bad idea that makes boatloads of money for a few oligarchs.

For constraints files a '#' character starts a comment Vivado doesn't like having more than 1 timing constraint per input clock pin. Somewhere in the messages is one about over-riding this constraint. For some reason Vivado makes you work to find all of it's IP constraints. Your clk_wiz_0 block put one into your project. You can find it by looking a the IP sources in the project browser window. I personally consider this one of the many bugs introduced into VIvado many many versions ago and preserved for ,er, inscrutable reasons. Always read all messages, especially the warnings and errors. If you can't figure out what the error source is from an error message ( not uncommon ) then you might be able to do so from previous synthesis messages. When you see that a constraint has been ignored, this is usually due to syntax issues. Vivado occasionally changes constraint syntax from version to version so using older ( or ones that haven't been updated ) master constraints files can cause problems. I'd say that you should use the template feature available in the GUI or by using the -help feature in the TCL console.. but I've had Vivado suggest syntax that is then rejected in subsequent build attempts. Then, it's off to google-land... But be very careful when on the multi-colored brick road; you are likely to run into lot's of out of date references. The Vivado Document Navigator helps sync documentation with your tool version. But do avail yourself of the built-in help resources for your tool version; most of the time this will get you past the warnings and unexpected consequences of the tools not being able to understand what you are telling them. What I don't get is why you are using the block diagram IPI flow for such a project. Everything would be much simpler if you just had HDL and constraint files in your project; and you would be able to see what's in the sources... More importantly, many of the Xilinx IP works differently or has a different set of options for the IPI version as opposed to the HDL version. Xilinx has always pushed the IPI design flow, I'm thinking that this is because restricting user's design options is thought to ease support costs. Making users dependent on the FPGA vendor to make important decisions for their designs are certainly better for the bottom line. Vivado works in mysterious ways. A simple way to avoid tool version dependencies would be to put the tool version that the source file was made for in the source file. It would be nice if FPGA vendors followed basic software development documentation practices in their sources, especially, for constraints which do not have fixed syntax through tool version timelines.

@jb9631, Thanks for the information. Interesting.... Xilinx has no incentive to make their IP resource thrifty. They do have an incentive to make their IP consume lots of resources. Just an observation. IO SERDES can be tricky to implement. Fortunately, there are application notes to help. Before trying out a design on hardware I suggest doing a timing simulation ( after the RTL simulation ) on the implemented design.

Board support is provided my Digilent. Visit their GitHub repository for a number of useful things supporting your board. For Vivado 2021.2 you can use the xHub feature to add support for Digilent's boards. For earlier versions you can download or clone the vivado-boards repository and install it manually according to their documentation. Do visit Digilent's GitHub for the master constraints files and vivado-library repository at least. Do avail yourself of all of Digilent's documentation and support. You might find a number of useful things to speed up a project. If you just want to specify a part for your Vivado project rather than a board just highlight the exact part listed on the Digilent documentation. If you are using an HDL design flow ( I hope that you are ) then that and the master constraints file with pin location constraints as a guide is all you need. Always trust the schematic. Always verify the master constraints. The speed grade for the Genesys2 boards is the -2. You want the tools to know this.

"not working correctly" isn't terribly informative to anyone wanting to help. When using the create_clock timing constraint it's a good idea to use the -name field to differentiate it from any other similar constraint in a design. How are you connecting the boards? Clocks require particular attention to proper transmission line details. Make sure that you have the correct pins connected as a starting point. Read through all synthesis and implementation messages and warnings.

Learn Verilog or VHDL. Your quest would be simple. It's amazing what you can do with very few structures like shift registers, 1-bit adder/subtractors ( AKA up/down counters ) storage and simple state machines. All of these are (usually) trivial. the hard part is understanding time, concurrency, and how HDL gets implemented in a programmable device. There's plenty of source code in the Project Vault to use as templates as you learn. There's only one way to learn...take the first step. BTW, before programmable logic these same structures were used to create quite complex logic out of a handful of MSI/LSI devices. The world hasn't changed in the past 50 years as much as many people assume.

Ignoring all previous commentary regarding this post I do have one more suggestion. For such a project I'd start with a high level simulation using OCTAVE or MATLAB. Sometimes, it appropriate to use any functionality as a first pass just to verify that your concept makes sense. Before trying to implement anything in hardware ( whatever that might be ) I'd write an algorithmic OCTAVE implementation that exposes all of the details of the design. This means just using basic logic structures like if-then-else, while and for loops, etc. The idea is to make sure that your implementation doesn't rely on high level function. It also forces you to create and implementation that can be readily translated into programmable logic using the resources available to that hardware. The purpose of this is that after you get to the end, where you have an implementation working in ( in the case of FPGA hardware) simulation and then hardware, you can compare the results to the OCTAVE simulations. More importantly, the effort will circumvent spending time trying to implement an algorithm in logic that can't possibly succeed. Of course, if you're unable write down how you believe your daydream, er concept, is suppose to work and how the implementation is constructed, then you are probably just wasting your time. PS. I use OCTAVE because I can afford it. I've recently discovered that MATLAB now has a 'personal use' license that make the commercial tool available to individuals who couldn't afford it. I haven't tried it yet, but now MATLAB might be a reasonable investment for hobbyists and people not privy to academic discounts.

You may still want to work through more parts of the tutorial as ditching the Mig example core will save resources. Theoretically, there's a lower limit to how fast you can operate DDR memory, but if you are trying to stuff a lot of design into a small part and are having timing closure issues you might try running the DDR controller PHY at a lower data rate. For a lot of applications it might still be plenty fast enough, if all you need is a large storage bucket; see part 2 of the tutorial. Then again, sometimes one has to abuse the piggy bank a bit more vigorously in order to work with a platform more amendable toward fulfilling one's dream of glory. :)

@Mathias I have Vivado 2020.2 installed on my Centos box so I brought up your project. I had to "upgrade" the MMCM because Vivado keep changing the way it handles IP. I found problems. I had to change the Mig Project settings to match your imp_top.v source. unchecked the Pin Compatible FPGAs select a 4:1 controller selected 200 MHz for Input Clock Period ( Vivado 2020.2 has a bug that keeps changing this every time you open the IP Wizzard !!) Use the drop-down selector to choose from the list because Vivado has a problem with clock periods specified in ns. selected Use System Clock for Reference clock I hate context sensitive IP Wizards, because they don't show the same choices depending on previous selections and devices.. it can cause a lot of problems. Your ddr3_addr width is wrong in the imp_top port causing placement errors. I had to add this line to the Arty-S7-25-Master constraints file: set_property CLOCK_DEDICATED_ROUTE FALSE [get_nets sysclk] This got me past your DDR problems. You still have some work to do though with constraint assignments. I don't know why Vivado creates an issue with the clock. Likely, you need to assign the location of the MMCM directly, though Vivado should be smart enough to figure this out on its own. It could be for some other restriction that I haven't tracked down yet. I posted some files to help you fix the DDR controller issues. Make sure that the mig_a.prj pin location assignments are correct. The xc7s25 is a really small part in terms of resources so designs involving external DDR memory might be an issue. datasheet.txt mig_a.prj

PLDs and CPLDs have seen their days fade into the sunset for the two programmable vendors who control 80% of the market. The MAX10 has morphed into a device that is practically indistinguishable an FPGA. I wish that I had a better answer than get cracking on your programmable logic skills. You might be able to find a suitable alternative to what I've mentioned but I don't know of anything. The big problem these days might be finding a distributor who has stock of any parts that you might want to use. Try locating any MAX10 devices ready to ship...

You are committed to the LTC2296? I assume that you want to use the analog devices EVB for that device? Designing ADC boards isn't trivial. Jumping into the FPGA development flow from a Micro-controller design flow won't be easy. A lot depends on your application. In theory, buying an ADI ADC EVB that can be connected to an FPGA board using a "standard" connector like the FMC or HSMC might be an easier path, if ADI has pre-built projects for a particular combination of EVB/FPGA platform that suits you needs. There are a lot of potential pitfalls waiting for the unwary. In general ADI has good FPGA support for it's products, but this is limited. Digilent makes a few FPGA boards with SYZYGY interfaces as well as 14-bit dual 100 MHz ADC pods that are well designed for general purpose applications. I wouldn't say that these are suitable for beginners though. The Eclypse-Z7 is, in my opinion, particularly not well suited to beginners. Perhaps a FPGA based instrument like the Analog Discovery, the Red Pitaya, or the ADALM2000 would be a more convenient option? It really depends on how much data you want to collect and how you want to process it. There is a general lack of ADC hardware for FPGA boards in the 2-99 MHz ADC Fs range. There are more possibilities for "14-bit" 100 or 125 MHz ADC sampling. The ADC data width is in quotes because the actual ENOB for ADC devices is rarely close to the advertised word width, even assuming a perfect analog pre-conditioning front end. Until SYZYGY came along, "low cost" converter based projects for FPGA platforms were better supported by Intel based platforms. Terasic's DDC and a Cyclone board with an HSMC connector is a possibility for 100-125 MHz Fs conversion projects.

Are you using the mig project file from Digilent or one that you created through the IP Wizard? I notice that Digilent only supplies sources for the Arty-S7-50. I notice that your constraints file is for the Arty-S7-25 and the mig-a-prj has this line: <selected>7s/xc7s50-csga324</selected> I'm not familiar with the Spartan 7 devices so I don't know if there are any clocking restrictions that are different than for other Series 7 devices. I don't see why the code as presented in your git would make Vivado think that sysclk is a LVCMOS33 signal or "Sub-optimal placement for a clock-capable IO pin". I suspect that you might not be able to follow the tutorial exactly by providing the Mig controller IP a single 200 MHz clock ( or whatever value the datasheet says is in the range for a reference clock. ). You could try following the Digilent Mig reference for your board. The problem is that you will need another clock source for your other system clocks ad they will be unrelated to the DDR clock domain. Vivado has a problem handling multiple create_clock constraints for the same signal. If you connect sysclk to an MMCM it will create it's own constraints file with a create_clock constraint and generate errors. Did you get a synthesis warning about over-riding this timing constraint? If your design connects sysclk to an MMCM then your toplevel constraint file should not have one. If you connect sysclk directly to HDL logic then you need to have the create_clock timing constraint in your constraint file. If you follow the Digilent Mig project and connect the 100 MHz sysclk directly into the Mig Controller IP then it will ( I believe ) create it's own xdc files and a create_clock constraint. Vivado doesn't make it easy to round up all of the constraint file in a design that uses its IP.

Well, I guess that this is more information than before... "So I need to acquire some samples, store them in memory and calculate the autocorrelation" doesn't really tell me how your design is supposed to "measure autocorrelation". At least try and put into words what it is that you believe that your logic circuit does. What is the source of your digital input? Mechanical buttons and switches are notorious for a phenomenon known as contact bounce. Using them without conditioning is dangerous, especially for circuit like yours. It seems to me that your HW/SW approach, ignoring the actual code involved, is complicating your design solution. All hardware or all software approaches might be easier to conceptualize. I'd go for all HDL but that doesn't mean that you should. Anyway, you seem to be reluctant to provide enough insight into your theory of operation for me to be helpful. Perhaps that because you don't think that you need do this step and haven't tried? Normally when someone says that "xil_printf("%d: %d\n\r",my_secs, data);" produces unexpected characters I'd suggest that there's a baud rate issue, but in your case I suspect that it's due to a much more serious problem, a divergence between what you hope that your design is doing and what it's actual;ly doing. I strongly urge you to create a Veriog testbench and get a visual picture of what your hardware is doing. The first iteration will likely not be very good as you will fail to get the button and switch input behavior correct; but you have to start somewhere.

The only thing that you've posted is your solutions to whatever it is that your design is supposed to accomplish. I'm a big fan of creating projects just for the purpose of learning or experimentation. I do it all the time. Even for "hobby" projects that are mostly for experimentation it's best to start off with figuring our a description of the problem, what you want to do, and the theory of how you intend to go about solving the problem. The act of writing this down usually helps raise important questions. For experimentation, knowing the right questions is more important than knowing answers to unimportant questions. I can see your solution. I can't see a anything that tells me what you are trying to do consistent with the stated objectives: "I have a signal. I'd like to read the signal". Trying to solve a problem that is undefined is rarely a productive educational experience, though might be a good way to pass the time.

Before trying to debug your hardware perhaps you might post a brief description of the theory of operation for your design. You start with: "I have an external TTL signal (3.3 V, 1 kHz)"; and from this your intend to receive ascii characters? more informatin needed.

@Mathias, Could you post the entire toplevel source file and the .xdc constraints file in your project? I'm assuming that this is your port of the imp_top.v that implements the DDR controller example design. My guess is that sys_clk_i is not on your toplevel port and constraints. In this case Vivado will just assign it to an arbitrary pin that it picks out of the air ( or if I was an optimist I'd say intentionally picks a pin that will cause a bitgen error so that you know that you have a problem). This is why you are getting a weird message about IOSTANDARD incompatibility. It's important to read all warning messages carefully, especially if you get an error message. It's also important to look at the final pin report after successfully generating a bitstream file to make sure that the pins are correct before running a design on hardware. Don't freak out about how many warning message you might encounter; many can be ignored.

You should definitely use the 100 MHz DDR3_CLK100 for the source of any MMCM clocks generated for use with the DDR controller clock domain. The Digilent master constraints files assigns the DDR3_CLK100 pin IOSTANDARD as SSTL135 so you should follow those settings in your main constraints file. The 12 MHz UCLK is on IO bank 15 should use the IOSTANDARD assigned in the master constraints file. The error message about conflicting IOSTANDARDS means that bitgen DRC has found inconsistencies of compatible IOSTANDARD assignments for pins in the same bank. Somewhere, you've connected sys_clk_i to the wrong pin. The signal names in your toplevel entity port have to match exactly the names in your constraint files. I always refer to the master constraint file and schematic to understand connectivity before doing a design involving external interfaces that I haven't used before. Sometimes the master constraint file is wrong, but the schematic for Digilent boards can be considered as "golden". I don't always use the same name as either the master constraints file or the schematic... but all of my project sources must be consistent and. One needs to check connectivity from pin number through to the toplevel entity port name making sure that the name is exactly the same in all project source files. It's easy to get confused by signal naming. Even the Digilent master constraints files aren't always consistent with the schematic or demo HDL source files. Don't mindlessly use the same signal names in demo HDL files; check pin connectivity to the schematic pin numbers. Your board is a rarity among Digilent FPGA boards in that is has a external clock module connected to the same IO bank as the DDR interface. You shouldn't be getting a warning about Sub-optimal placement for a clock-capable IO pin and MMCM pair if the input clock to your MMCM clock input is connected to pin R2.

The Series 7 devices have internal level translators to pass signals between IO banks having different Vccio voltages. Not all FPGA vendors have global clock distribution to all areas of the devices in such a flexible way. So, it is possible to have a clock module connected to a clock capable pin on one bank powered by 3.3V and use it in an IO bank powered by 1.35V. If you think about it, any FPGA device capable of having multiple IO voltage regions need this ability since the main logic power supply voltage is rarely the same as any common IO logic standard. For MiG DDR3 controllers you can connect the external clock to a PLL or MMCM and generate a number of related clocks of various frequencies. This is what I've done for all of the tutorial HDL examples. I'm pretty sure that your board has an external clock module ( likely 3.3V) connected to a clock capable pin that you can use in the same way. ( I haven't checked this but boards with DDR require a decent clock source. I guess that I neglected to include the Series 7 Clocking Reference Manual in the list of required reading. Actually, before starting a design you should have at least done a quick speed-read through all of the device feature reference manuals for your device family regardless of vendor. Clocking is an area where one might expect to run into unexpected surprises. There are a lot of use case limitations with clocking depending on what type of IO resources are being used so having a good understanding of the material in the Series 7 Select IO and Clocking manuals is a necessity.

The basic 1-bit modulator ADC concept is pretty old. As for implementing it on any particular FPGA platform at the sampling rates that are of interest to you are concerned, let's just say that the devil is in the details. Make sure that you understand what the important details are. 5 GHz sampling would be beyond the datasheet capabilities of many low end Artix transceivers and well beyond ISERDES rates or even the internal clocking infrastructure. The tools tend to restrict bitstream generation to reasonable operational conditions, though I'm sure that there is a way to get around that. Direct conversion ADC implementations might involve a bit of "magic"...

It's always fascinating when someone claims to use hardware in an unusual way to implement a function totally foreign to the hardware's design purpose. I looked at your reference and there seems to be some confusion as to what the author is really talking about. The author refers to GTP SERDES operating at 5 Ghz. I don't know what that is. Some Artix FPGA boards make the Artix GTP MGT transceiver hardware available and provide power and clocking on the board to use them. On the other hand the IO SERDES available on Series 7 FPGA devices hardly run at 5 GHz rates. So it's not clear to me what exactly is going on with the author's hardware and software design. I certainly don't discount the idea of using a digital logic input buffer as a general purpose analog receiver, and most certainly don't discount the idea of using a digital logic output buffer as a general purpose transmitter. Implementing Zigbee this way though seems to be a stretch for my (limited) imagination. But if you are curious I'd start with figuring out how to resolve the basic questions that the material raises before trying to implement the concept on your hardware. Implementing a low quality AM/FM receiver using an external ADC connected to an antenna is amazing enough and more than plausible.

Certain FPGA devices are not supported by free versions of vendor tools. Such is the case for the KC325T on the Genesys2. Yes, the board comes with a voucher for obtaining a node-locked license to create a bitstream file for this device. These licenses are perpetual and are tied to either a HD ID or MAC ID so you can use them on the PC that is tied to your computer for as long as the PC is operable. Xilinx provides documentation on how licensing works. I have a license for the KC325T that came with my Genesys2 board and dual-boot to Win10 or Ubuntu 20 and can develop projects for that device on either OS host ( same machine and MAC ID ). I was able to transfer my node-locked ZU7EV license from a WIN7 box to the this box; but the current version of the tools now support that device anyway so even though the Xilinx License Manager says that my license has expired for Vivado/Vitis 2021.2 I can still develop project for the ZCU106. Don't expect the KC325T to ever be supported on free tools. Xilinx is more generous for ZYNQ devices. A device locked license is just like the full, paid for tool license except that it includes, along with all of the devices that the free tools support, the ability to create bitstreams for a particular device. You can develop projects for any board having a KC325T, including other packages. I use my node-locked license to develop projects on the Genesys2, KC705 and the NetFPGA-1G-CML; each has the KC325T but not all have the same pin count or package. Simulation using Vivado ISIM is always free. Node-locked licenses are perpetual but you can only use them on one host for your current version of Vivado and up to 1 year of tool version releases. This means that you might have to install multiple tool versions on the same host over time and use an older version for a specific platform. While not perfect Xilinx is a whole lot better than any other FPGA vendor with regards to providing support for devices not normally included with the free tool versions. I have some Lattice and MicroSemi FPGA boards that are useless because the tools expire after a year unless you start paying for tools.

Any PMOD Ethernet solution is going to be a 10 Mbps device. The PmodNIC100 is not particularly well supported, especially for FPGA platforms. While there are boards that could do what you want, your problem is going to be finding a platform that has a pre-built PYNQ image and potential for multiple Ethernet PHYs. It won't be cheap. The Zedboard plus an FMC quad mezzanine card might be the cheapest Xilinx possibility. OPSERO has good support for their FMC Ethernet cards. Evidently, there are people who've created a PYNQ build for the Zedboard but I have no experience with that. There just aren't many cheap Xilinx platforms with 2 1 GbE PHYs.

Never mind... it's already been done. One just has to figure out how to update the xHub catalog in Vivado....

Some "quests" are more lonely than others. If you want to do a 3 day hike in the wilderness and stick to known trails there are probably maps available to make the journey easier. If you want to just strike out in an arbitrary direction avoiding human and animal trails, and you know what you are doing you're on your own. You know where the support resources for your board are and what's available as far as canned projects and code go. I think that I've provided some hints to get you started on alternate paths but it's likely that you will have to create your own trails. You haven't really provided a clear picture of what you want to do with your platform or what you plan for accomplishing an end goal is; so it's hard to provide assistance.

Perhaps you want a platform supported by a pre-built PYNQ image? You can instantiate 10 I2C masters using a uController or Raspberry Pi connected to a simple FPGA via UART or SPI interface, or even USB 2.0. I'm not trying to discourage you from you goal... just thinking that it'd just be a lot easier marrying the right HW platform and software to your project goals. It's a matter of understanding resource requirements, complexity, and effort to achieve your design goals. Something that seems easy on one platform might involve a lot more effort on another. Supposing that you manage to get a Linux OS running on your board. And supposing that you had the resources to implement your Pl design. Do you know how to connect the PL to your PS? And do you know how to write a Linux device driver to access you hardware in your OS? Lots of parts to connect. The image in my mind is of a large box into which has been thrown a bunch of loose resistors, capacitors, stepper motors, lego blocks, Lincoln logs ( yeah, I'm that old; I think that before these kids got a box of stones to play with ), and other stuff and decided to do a robotic project. Sure, perhaps it can be done; if you can conceptualize how to integrate the right selection of parts. It sure would be quicker to start off with a robot project kit with an assembly guide. So, do all of the tools that you want to use fit in the tiniest ZYNQ box for your platform? If you're committed to a platform scale the project to the platform. If you're committed to a project spec. consider selecting a platform that makes development easier. Or come up with a plan that I haven't thought about. But do make a plan.