zygot

Yeah, it's a shame that the Eclypse-Z7 only has 2 standard SYZYGY ports ( and 0 transceiver ports ), and that no one makes a SYZYGY pod with 1 ADC and 1 DAC. The single width pods are pretty small for stuffing all of the features of the ADC and DAC ZMODs into 1 combined pod. I would expect that a double-wide pod could do this. The Eclypse-Z7 is capable of using a double-wide pod but no one makes such a thing to my knowledge. Your references to MHz and bandwidth are a bit confusing. If you need 3 ADC channels with an analog bandwidth of 10 MHz, then 2 dual-channel ZMODs would do that. Note that the analog bandwidths of the ADC ZMODs are substantially lower than half of the preferred sampling rate of 100 or 125 MHz for the ZMOD ADCs. At Fs = 100 MHz you can decimate samples by 4 down to a 25 MHz sample rate to ease data management. I assume that you mean that your analog input signal bandwidth of interest is between 0 and 10 MHz. IF you need ADC samples at exactly a 10 MHz rate then you will either have to do rate conversion in software ( if possible ) or come up with an ADC sample clock frequency that supports a different decimation strategy. If you want to use Digilent's higher level sources, you will have your work cut out for you. This depends on how much storage you need for ADC and DAC samples. If you can fit all of your storage into the PL resources then things will be a lot easier. This leaves your 1 MHz DAC output to be implemented. I don't know of any PMODs with DACs that support 1 MHz analog bandwidth. In theory, if you only need a 500 KHz analog output bandwidth, then perhaps you can use one of Digilent's PMODs. Before deciding on how you want to implement your DAC using the PMOD headers ( you might need to make your own DAC circuit ), be sure to read the datasheets for the SN74CBT3384 FET switch. You will be on your own for figuring out how to implement that. If it doesn't need to be connected to the ZYNQ PS then things will be a lot easier. There are a lot of unspecified details that haven't been discussed, like the relationship between your ADC Fs and your DAC Fs. Digilent's vision for SYZYGY is pretty limited. A long time ago they asked for suggestions on what users want to see for future products, but I haven't seen any new ZMOD pods that seem designed to fill customer's needs since then. Actually, I'm a bit disappointed that the SYZYGY standard hasn't be as enthusiastically adopted as I thought that it would be.

The Eclypse-Z7 is not the ideal platform for this kind of project. Consider looking at something along the lines of the XEM7320. everything will be a lot easier and quicker once you get familiar with their closed framework. That said, you can certainly ignore all of the ZYNQ cores on the Eclypse-Z7 and do everything in the PL, without being tied to any vendor IP like AXI bus implementation ( which can be sketchy ). The old but venerable Z7020 PL is pretty much equivalent to an Artix 75T in terms of resources. Here is such a project that I did a while ago: There's an XEM7320 version also posted. If you are going to invest your time and effort into developing an application on an FPGA platform, why not choose one that allows you to use that effort to do more ambitious projects in the future?

I use ISE 14.7 on Win10. Impact doesn't work. Anything requiring JTAG connectivity doesn't work. I just use the Adept Utilities for Windows to do configuration. I only use ISE on WIn10 with Spartan devices. I would imagine that you can target an XC9500 device with the Adept Utility by modifying a few lines in the device text file. Who knows, perhaps support for those devices is already there. [edit] I just checked jtscdvclist.txt, which is where the Adept Utility for Windows keeps it's database of supported devices, and XC95$XL is listed, so this should be all you need to do configuration. Note, this is the file where you can add unsupported devices, like the Artix A50T, which is what I've done. Be careful of archived versions of ISE on the AMD/Xilinx website; I tried their version of 14.7 only to find that Spartan 3 devices weren't supported. I installed ISE on Win10 from a really old DVD ( remember when you could fit the Linux and Windows tool installers on hard media? Installation of ISE on a modern version of Linux may not be trivial as most recent ones have abandoned 32-bit support. Trying to find the correct version of library dependents can be a long slog. I haven't tried installing ISE on any version of Linux that I run. Centos 7 might be worth a try as it uses an older kernel version. @asmi, any recommendations or installation advice from your Linux ISE install experience?

@artvvb, Well, the two links above provides some more information, as far as it goes. I tracked down the references for the ZMOD 1410 ADC pod on a Gensys ZU board that you provided, as well as the pertinent reference manuals. Looking at the zmod_adc_driver_v1_1.v source, DDR is implemented with the UltraScale IDDRE1 primitive. For what it's worth, according to ug571 UltraScale Select IO Users Manual, IDDRE1 when instantiated in a design is 'translated and implemented by Vivado as ISERDESE3'. HP IO Banks do not support 3.3V or 2.5V signalling. According to the Genesys ZU Reference Manual: The (SZGYGY) differential pairs were prioritized and wired to HP banks, allowing the maximum data rates supported by the SelectI/O architecture. However, the single-ended pins are wired to an HD bank. According to the ZMOD_1410 schematic, all of the ADC DDR data outputs are assigned to single-ended SYZYGY pins except for DOUT_ADC_2, DOUT_ADC_3, DOUT_ADC_4, AND DOUT_ADC_9 all of which share a differential pair with another single-ended signal. The CLKIN_ADC input to the pod is differential and assigned to differential pins while the CLKOUT_ADC signal is single-ended and assigned to a differential pin. From what I gather, the Genesys ZU SYZYGY port is lucky that the data rates for the current batch of ZMOD converters is in the 'low performance' range. I can't assert that the third party demo projects that Digilent uses to promote these boards can't work properly, but I'm not too thrilled at the execution either. It would certainly be better, for everyone, if Digilent engineers bothered to do demo designs for their own boards.

Oops, my fingers quit before finishing the text. I've corrected the original post above. You can not use J6 and J10 at the same time. I suggest picking either the HS2 or the J6 PROG USB connector. Either way, you will be able to use Vivado to configure the FPGA or debug the HDL. For GDB I believe that you will need to make additional provisions for doing software debugging; that is additional FPGA design and resources. These may well be in your cores, if they are designed explicitly for a Series 7 FPGA device.

I think that you have that backwards; you don't need pin locations unless you intend to use the configuration specific pins as general purpose IO post configuration. For a general purpose board like Digilent sells I don't know of any application that needs to do this. The constraint files are for assigning IO to your FPGA HW application. You don't need this information ( usually ) for configuration. Usually, schematics have no errors. Constraint files and other documentation frequently have errors. If, you intend to do software debugging of your CPU cores, then you probably want a different circuit than the board level JTAG chain that the board's FPGA and FLASH devices are connected to. Sometimes ZYNQ boards have a separate header for ARM core debugging that's separate from the hardware JTAG chain.

All of the Series 7 FPGA boards from Digilent use an FTDI USB bridge device for configuration and as a UART. I figure that you would just configure your FPGA and use GDB using J6. As I mentioned, you can cannot connect 2 external USB JTAG devices to your board.

All nicely done, entertaining, and informative. If you are new to FPGA development these are worthwhile resources to investigate. I've been doing programmable logic design for over 40 years and I've enjoyed reading what's being offered. Nifty keen.

More than likely, you will have to figure out how to connect your HS2 to J10. I have an older Digilent USB JTAG cable for use with the old 6-pin header; I imagine that this would work on J10 of your board. Regrettably, Digilent refuses to provide schematics for it's configuration related functionality. Perhaps you don't want to be using a Digilent FPGA board for your project. What utility do you expect to get by using J10 instead of the normal J6 JTAG connectivity?

Vivado readily connects to Digilent and Xilinx JTAG programming hardware. You'll want this if using the ILA or VIO debugging cores. All Digilent boards have a PROG USB header using a USB bridge device from FTDI or Cypress. You OS needs to recognize USB devices as for a specific use. Using the USB connector on a Digilent board that supports JTAG is the easiest way to configure your FPGA. You can use OpenOCD with a bit of work, but what would drive the need to do so?

J6 is the USB connector for FPGA configuration. If you connect a cable to J6 Vivado should see a Digilent device and connect to it. J10 is an alternate way to use the board's JTAG chain. In this case you need a separate USB JTAG controller that Vivado will recognize, like Digilent HS3 or Xilinx cable. Usually, the open JTAG header ( not a USB connection ) is a 14-pin keyed connector. You can't use both at the same time. J10 pins are not provided in the master constraints file because they are generally not used as general purpose IO. Have you reviewed the board's reference manual?

Connecting to a JTAG chain isn't as straight-forward as you might assume. I suggest trying to resolve your connection issues using the normal Digilent means. What is your host OS?

Even I can be tempted into using the IPI design flow.. if I can prototype an idea in an hour or so and test it on running hardware. When it comes to programmable controllers that require a closed system, then I lose interest. I'm not you of course, and Dan is correct that for some people, converting a logic design problem into a software problem might seem like an easy short-circuit of an arduous development effort. Personally, I prefer doing everything in Vivado where I can simulate the whole system ( or at least the part that I'm designing ). Sometimes, there are complications like DDR or an SD card interface, or other external hardware that complicates the simulation effort, but I've never found that effort to be wasted. My general rule is that combining blocks are are simple to understand can sometimes lead to very complicated system issues that are hard to figure out and resolve. Combining blocks that are complicated only tend to increase the system complexity exponentially. Using blocks that I don't understand and are controlled by a third party rarely works out in the end. My purpose for addressing your question is to simply expand the question into manageable parts. You job is to decide which approach gets you to a completed project. For me, when i learn something useful that can be applied to future projects, the extra effort is a bonus not an expense.

I don't know for sure why this is true. I've used the low-level ZMOD controller sources and I've done some designs with UltraScale+ ZYNQ devices. I suspect that the problem is that, in UltraScale, the IO is completely different for advanced IO features like DDR. The general purpose IO that was on the Series 7 devices isn't so general purpose on UltraScale devices as they are designed to implement Gbsp+ LVDS in quad groupings. What was fairly straightforward as Series 7 DDR can get really complicated in UltraScale, even if you carefully selected your IO assignments. I believe that someone at Digilent should present a more informative answer to their Genesys ZU customers. If the problem is finding someone to write HDL code that's one thing. If the problem is that the SYZYGY FPGA pins were assigned as if it were a Series 7 device, then that may well be a much bigger problem to solve, if it's even solvable.

No doubt true. MicroBlaze isn't the only soft-processor that can be implemented in an AMD/Xilinx FPGA. I'm not referring to resource hungry programmable controllers like RISC-V either. You can find much simpler soft cores with HDL sources to play with. The big question is whether or not any soft-processor is required or even appropriate. I wouldn't get out the back-hoe to weed my garden when a simple hand-held tool would do a better job and be a lot quicker. If you can design and debug a Verilog module, then do you really need 1 or more processors to get your project completed? Do you really want to spend your time on multiple software development projects using proprietary tools, plus complicated Verilog design only to find that your system concept is too hard to understand and get working?

@ISP, Is your other name Chat GPT-4 by any chance? If it is, then this conversation makes a whole lot more sense...

Great! That's exactly what programmable logic does very well. Why no just ditch MicroBlaze and the SDK and implement the whole thing in Verilog?

To my knowledge Digilent has never published a design that changes the Nexys Video Vadj voltage. According to the boards' reference manual, if VADJ_EN is low, then the regulator providing Vadj is disabled, so 0V. The reference manual is in error about any "default" value for Vadj. Once VADJ_EN is asserted to a logic high state, the regulator drives Vadj to be 1.2V, 1.8V. 2.5V or 3.3V according to the state of the 2 SET_VADJ output pins. There will be a delay before Vadj becomes stable. If you use the high impedance PULL_UP constraint on all of the output pins that control that regulator you will get Vadj = 3.3V, maybe. According to the reference manual you should not change the state of the SET_VADJ outputs while VADJ_EN is asserted. It's possible to assert pin outputs to default value that isn't 0. If you don't want to do that then your design has to bring up the Vadj power supply explicitly. One way to do this is to have an up counter control these pins after configuration. -- a counter to set the Vadj voltage -- Need to use a clock that is always available and isn't from the FMC connector !!! vadj_count_proc : process(clk100,areset) begin if areset = '1' then vcnt <= (others => '0'); elsif (rising_edge(clk100)) then if vcnt < X"FFFFFFFF" then -- important to stop counting before overflow... vcnt <= vcnt + 1; end if; end if; end process vadj_count_proc; -- To change Vadj we need to do this: -- VADJ_EN <= '0' disable the regulator -- SET_VADJ <= sets the Vadj voltage: {0,1,2,3} --> {1.2V, 1.8V, 2.5V, 3.3V} -- VADJ_EN <= '1' enable the regulator -- VADJ_EN = '1' and SET_VADJ = "00" when the FPGA is not driving these signals -- We need Vadj to be 2.5V so set_vadj <= "10" when vcnt > X"00FFFFFF" else (others => 'Z'); -- set to 2.5V 167 ms after configuration vadj_en <= '1' when vcnt > X"01FFFFFF" else '0'; -- enable the Vadj control 336 ms after configuration Some designs using an FMC mezznine card may bot want to reset vcnt after configuration as shown above.T This user selectable Vadj arrangement was poorly thought out. I can't think of case where one would want to change Vadj after configuration. The Genesys2 that followed the Nexys Video has a more practical and safer power supply design. As for "enabling FMC pins", I assume that this is a translate into English artifact. The FPGA IO connected to the FMC connector are always enabled if your design provides proper location constraints and the toplevel entity of your design includes them on the IO port. The problem is making sure that the voltage powering the Vadj banks have compatible IOSTANDARD assignments as the logic on the FMC carrier board. That's the potential problem with how the Nexys Video board sets Vadj.

You are limited by how the board is designed. You can configure an FPGA with a software application of your own design. Here's a nifty project that shows how: https://forum.digilent.com/topic/17096-busbridge3-high-speed-ftdifpga-interface/ Of course, there are multiple are multiple tools for configuration via a USB cable.. Vivado Hardware Manager, Digilent Adept Utilitites, etc. Most FPGA boards have a button to accomplish the same thing. You threw me off with the reference to reset.

I frequently connect hardware under development to my working PCs using a free Ethernet port. As Art mentioned, this is better done with a spare Ethernet port using a static IP address instead of DHCP. A router will provide an IP address to devices connected to it but this can change depending on what's connected, and in what order. It's just easier to work with fixed IP addresses. Not all of my work PC have 2 Ethernet ports. I have a number of USB 3 1 GbE and 2.5G Ethernet adapters for this. They are cheap. If you have a spare USB 3 port on you PC just assign it a static address. I want to say that this is easier in Linux than Windows, but there are so many Linux distributions, and changes from version to version, and ways to control Ethernet ports.. it can drive me a bit crazy(er) at times. You'll need to set up your FPGA board with a fixed IP address as well. In order to talk together on an Ethernet cable, the devices on both ends have to have IP addresses and masks that are reachable ( compatible ). This is why I like using a second Ethernet port; the PC doesn't try and connect to the network on the development Ethernet interface, and I can do whatever development activities that I want on the static IP assigned Ethernet interface. I 'd advise making your static IP addresses unreachable from your internet or LAN connection IP addresses. 192.xxx.xxx and 10.xxx.xxx are not reserved and are frequently used for local connections. The first thing that I do before trying to do anything useful is to ping the connection both ways to affirm that they are able to communicate. Of course, both devices need to support basic functionality like ping. It shouldn't be too hard to find information for how to set up Ethernet interfaces with some internet searching. For Linux, the Desktop you choose can complicate things. I was astonished to discover that Ubuntu 22 doesn't even install net-tools by default; had to find out the hard way... but that's what Linux is all about, I suppose. Telnet is the same thing. Make sure that both devices support it and are compatible. If you are going to use an Ethernet interface you will need some basic understanding of how it works. I hope that this post has some useful tips. I never do development work on a PC that is capable of being connected to the internet; I just pull that cable out of the RJ-45 jack.

Well, you had a good question. The answer, "our advertising was a misstatement and we haven't gotten around to fixing this for any of the boards, except the Nexys Video, which we just did this week.." isn't much of an answer. You deserve better. The Arty A7-100T uses a XC7A100T-1CSG324C FPGA and 1 MT41K128M16JT-125K DDR3 memory according to the latest schematic. The Nexys Video uses a XC7A200T-1SBG464C FPGA and 1 MT41K256M16HA-187E DDR3 memory according to the schematic that I use. Both FPGA devices are the same speed grade. Both DDR designs have a 16-bit data bus. The Arty will be advertised as working at a 333.3 MHz PHY clock rate, once the fix to one web page is fixed. The Nexys Video is advertised as working at a 400 MHz PHY clock rate ( was 800 MHz ) Since DDR3 clocks data on every PHY clock edge the MT/s is 2X the PHY clock rate. The DDR memory on the Arty is a faster speed grade than the memory on the Nexys Video which is advertised as working at a higher PHY clock rate. Digilent wants the customer to figure out all of this for themselves. Evidently, there's more to the story than MHz or MT/s as far as DDR performance is concerned. Anyone at Digilent willing to provide a better explanation as to what's going on here (aside from the aforementioned MHz gaff ?

I imagine that the correct answer is; any version that you want to go to the trouble of porting to a Z7020 using the version of tools you want to work with. There's no HW limitation for ZYNQ devices with respect to some version of any OS. I imagine that on would run Windows if one had access to the required source code**. Have you been able to find a reference of someone running Android on ZYNQ anywhere on the internet? ** I have no idea why anyone would want to do this, but it's surprising that Microsoft hasn't made this happen as it would allow them to claim even higher inflated installed user number claims than it already does.

Reset buttons on Digilent boards go to logic in the device. Any application that the device is configured with may or may not use that input; it depends on the design. Any effect on using the Reset button is purely dependent on how, and whether, it's used in a configured device. Configuration takes place on specialized pins and, at least during power up or configuration, are independent of any application already in a configured FPGA device. The Program button does initiate the configuration process and the FPGA will use a number of sources for loading a bitstream depending on the mode pin settings. If JP1 is jumpered and you have a valid bitstream in the attached FLASH, then the device gets configured from FLASH. You can configure the FPGA using JTAG at any time. There's a configuration guide for Seried 7 devices. What kind of behavior were you looking for?

Not all FMC mezzanine cards are compatible with any FPGA carrier board ADI has fairly good FPGA support for it's FMC evaluation boards but it doesn't extend to all of them. If they provide example projects for your FPGA board or one that's similar ( KC705 and Genesys2 ) then the odd are pretty much in your favor. For this EVM it appears that the user is supposed to purchase a special evaluation platform. No demo project provided. The only way to determine compatibility is to compare schematics for the carrier and mezzanine boards. A problem that you are likely to face is IP for JES204B in Vivado. The ADI ADS7-V2EBZ HIGH SPEED EVALUATION BOARD would seem to render that unnecessary. Is it possible to circumvent the expense of a limited use evaluation platform and connect an EVM to a 3rd party vendor's FPGA board? If you can find evidence that someone has done it, perhaps. If you can't are you willing to spend a lot of money and time to find out? Note: the ADS7-V2EBZ is based on a Virtex 7 device and likely uses transceivers not available on a Kintex 7. I haven't bothered to check that out but it's fairly likely as Xilinx tends to segregate transceiver types by families ( cost point ).

IDELAY works fine. They are often required for even small bus widths at moderate clock rates, like 125 MHz DDR Ethernet PHY RGMII interfaces. You need to instantiate one IDELAYCTRL primitive clocked at (typically) 200 MHz plus one IDELAY2 primitive for each pin in your bus. If you had issues with Vivado then you were doing something wrong. IDELAY is good for fine delay control, up to about 1 ns or so. Trying to do this with logic is going to be tough. Even at 500 MHz you only get 2 ns granularity. Perhaps you know something that I don't know about FPGA design. Again, for 32 signals, from more than one IO bank you are going to have a hard time with place and route to give good control, even if you are willing to provide location constraints for your logic. The single ground pin on the CMODs are going to be a problem driving 32 outputs much less 32 simultaneous outputs ( if that's your plan ). I forgot to mention that the Mimas-A7 uses proprietary software for configuration, which was the first thing that I resolved. You can't use an ILA or VIO, or Vivado Hardware Manager with it. Fortunately, the board has a JTAG connector. Unfortunately, you have to make an adapter to make it work with the Digilent Hx JTAG cables ( I think that they still sell one version of these ). Their header is wired for a much more expensive Xilinx configuration cable. The alternate way to do this is to make an adapter board that connect your FPGA platform to whatever you are working with. That way you can compensate length mismatches in copper. Sounds like a lot of work. If you are going to do you own adapter SYZYGY or FMC might be worth consideration. Digilent has provided length reports for those. I'm not understanding your "_p/_n balanced pair" distinction from differential, in terms of connecting to external hardware. I don't see 16 n/p pairs of pins going to headers on your board. A few more tips. read about recommendations for driving simultaneous outputs from the same IO bank in the Series 7 SelectIO user manual FPGA outputs are not really well suited for driving lots of high currents on lots of pins. Board design may limit this as well. FPGA outputs are not designed to drive reactive loads, particularly those with significant inductive kick-back. There are protection diodes but they are not there as a design resource. I'm sure that there's a way to get your project implemented. There just aren't many (inexpensive) boards in the AMD/Xilinx sphere geared toward prototyping these kinds of projects.