Installing ZedBoard (Zynq7000) board files under Xilinx Vivado 2021.1

[Daniel Glasser]

I have a ZedBoard (Zynq XC7Z020) on which I wish to prototype some software on a MicroBlaze that will eventually be moved to a ZCU-102, and ultimately to a custom IO card. I was given the ZedBoard and installed the Xilinx software that came with it, but ISE 14.1 seems to have some trouble with Windows 10 (file selection dialogs don't always appear, and it can't seem to talk to the network very well), so I've installed Vivado 2021.1.  Unfortunately, none of the directions I've found for installing the board files work properly under this version of the tools - it seems the stuff on GitHub (XilinxBoardStore / XilinxCEDStore) are not supported (I can't get them to work following the directions I've found, at least), and when I tried editing the Vivado start-up tcl script, the XML files appear available on the Diligent site seem to be incompatible (it breaks Vivado), so I cannot seem to create  a project for the ZedBoard using Vivado 2021.1.

There is a very nice Wiki page on the Diligent site that describes how to do it for the 2019 edition of the Xilinx tools, but it's out of date.

Can anyone offer some advice on what I should do?  Should I uninstall Vivado (both the 2021.1 and 14.1 versions) and try to download and install something in-between?

This is on a Windows 10, 64-bit host.

Thanks in advance.

Sorry about typos and odd spacing (I've tried to clean it up as I type), but the laptop keyboard I'm using is not agreeing with my fingers, and I keep typing the wrong keys and extra spaces.

[elodg]

Yeah, ISE is no good as it does not work on Win 10. It last worked on Win 7, but that is outdated as well. You need to go with Vivado.

OPTION#1 Vivado 2021.1 can pull in the board catalog form XilinxBoardStore, which is has the Zedboard defined. Just click Refresh.

The XilinxBoardStore lists it under avnet.com as vendor:

 

OPTION#2: You can install our board files using the steps from https://digilent.com/reference/vivado/installing-vivado/2018.2?s[]=vivado&s[]=init&s[]=tcl#installing_digilent_board_files.

Edited August 26, 2021 by elodg
fixed link to vivado-boards steps

[zygot]

1 hour ago, elodg said:

Yeah, ISE is no good as it does not work on Win 10. It last worked on Win 7, but that is outdated as well. You need to go with Vivado.

I beg to differ. In fact Vivado is no good for doing PCIe based designs for the NetFPGA-1G-CML board that Digilent sells. I know, because I've tried. The Vivado support for PCIe simply doesn't work ( at least on Vivado 2019.1 forward ) for the XC7K325T-1FFG676 part for this board because it only has 4 transceiver lanes, because of the lanes that the board designers chose to use, and because Vivado refuses to let you select the correct GTX bank. If anyone has discovered how to do this I'd like to know the secret.

So, I've been using ISE on WIN10 for over a year for devices that aren't supported by Vivado and for the aforementioned platform. I didn't use the latest archived version of ISE 14.7 from Xilinx to install it, but used an old DVD from Xilinx.. from back when the tools installer fit one DVD. Installation wasn't straightforward for sure but that version of ISE 14.7 supports Spartan 3, unlike the archived version available from the Xilinx download site. But the tools needed to create a bitstream do work on WIn10.

I haven't tried ChipScope or IMPACT, and ISIM has issues on Win10, but on occasion ISE is the only option for some projects. The ISE installer is less than 4 GB. Compare that to Vivado. ISE has bugs but not to the extent that every new version of Vivado has.

I would suggest that an earlier version of Vivado, say 2018.4, might be the best option for the Zedboard. I've done Vivado development for that board on Win10. One thing to you need to do is figure out if the version of your board is supported by Vivado. I have an older one had to spend some time trying to figure out what board version to choose and what the revision changes were because the Vivado installations that I have on Win10 don't support my board explicitly.

In some ways ISE is easier to work with than Vivado. I haven't seen any dramatic improvement in synthesis or P&R with Vivado. IMPACT can be a pain in the neck but I use the very useful Adept Utility for Windows to configure the FPGA. The one thing that Vivado does improve on is the integration of the debug tools into the GUI. ChipScope is clunky and you need a license to use it.

Can you do development work for the Zedboard using VITIS? I don't know because I haven't had the time to work my way through the maze. Unless you need VITIS experience I suggest that using a version of the tools that were new about the time that your platform was designed is the easiest way to get to a working project development cycle. You can spend weeks trying to convert old demo projects to the newer Vivado releases. Who has the time for that? Certainly not Digilent, though they still sell the board. That should tell you something. Understand that for ZYNQ development you have 2 toolchains to debug; HW and SW. VITIS simply wasn't designed for the Zedboard.

Last thought on the subject. I've had to eschew using flags and word counts for Vivado FIFO IP because they just aren't reliable. Vivado has messed up the FIFO IP for quite a few version now. ISE didn't have this problem, so it's the tool software that's the issue. If I spent some time thinking about it I'm sure that I could come up with other examples of how Vivado is frustrating to work with.

BTW, though Quartus for Intel FPGA devices is riddled with bugs, and finding the version that works with a particular device can take hours of research it does install relatively painlessly on just about any OS and is under 8 GB.

Edited August 26, 2021 by zygot

[thinkthinkthink]

Hey hey hey, we actually do upgrades of old demo projects. We'd done that last year and we've done it again this year. Check the <board_version>/<DEMO>/update branches of some of our github repos. As for the Vitis development for the Zedboard, the only issues I had last year with upgrading the Zedboard FMC-Pcam-Adapter demo from Xilinx SDK 2019.1 to Vitis 2020.1 were some makefile errors that I solved easily with a search through xilinx's forums where I found the solution which required modifying some makefiles. Now upgrading this Zed project from 2020.1 to 2021.1 should be pretty straightforward as it's all just Vitis.

[zygot]

2 hours ago, thinkthinkthink said:

Hey hey hey, we actually do upgrades of old demo projects. We'd done that last year and we've done it again this year.

Well, OK, there have been some demo projects that have been upgraded to support popular hardware, like the PCAM board. I didn't mean to suggest that none of your demos would work, as is, on the latest tools. But what percentage of the demos pointed to by product support pages can the latest version of Vivado or VIVIS open and create HW/SW that runs the demo? A quick perusal through Digilent's main pages and github pages suggests that the percentage is not very high. And since almost all of Digilent's demos use either MicroBlaze or ZYNQ that's a lot of demos tied to old versions of the tools e.g. Vivado 2018.x...

I read the questions posted to the Digilent Forums almost daily, so while I didn't intend to offend anyone working to support Digilent's products I'm not quite ready to walk back my comments above either. Mainly, those comments were to provide a different viewpoint to the statements about ISE and Vivado.

What I did notice was how sparse the list of FPGA boards on the Digilent sales page has gotten.

[Daniel Glasser]

I'm still having a number of problems.  Maybe I'm using the wrong wizard, but there is no "Refresh"  button on the particular dialog that is showing up for me in Vivado 2021.1.  I'm doing this on Linux (I was told by a co-worker that I should try installing under Linux).

I choose "Create Project" and see an informational page, then click on the "Next>" button to get the following:

Selecting "Example Project" (there seems to be no better choice offered),  I select "Next>" and get:

At this point, if I hit "Refresh", the left-side "Templates" panel clears, and I have to select the "vendor" checkbox in the "group by"  drop-down on the upper-right corner of the Template toolbar to get this list back. I have tried "MicroBlaze Design Presets"  and "Zynq-7000 Design Presets" (I've also looked at a few others) and hit "Next >", and I get something that looks like:

No "Refresh" button. "Default board or part" only offers 2 choices, and I find no means of extending that list as shown in the screenshots provided.

I get the sense that either Vivado 2021.1 has changed things around since those screenshots were taken, or I'm doing this all terribly wrong.  I have the definite impression that I'm an idiot, and while that's probably true, I still need to get going with a MicroBlaze instance so I can be certain that I have a working FreeRTOS configuration prior to having to write custom drivers for the peripherals being designed for the next phase of this project.

If anyone can point out what I'm doing wrong here, I'd appreciate it.

Thanks.

----

Update:

I noticed that the Tcl console on the main GUI has the following:

So perhaps the lack of a "Refresh"  button is because the GitHub repository has no board files updated for 2021.1; I'm not sure how to rectify this - I know Tcl well enough, but there's a lot of it in the various directories, and I'm pretty sure that changing things arbitrarily is not the key to a smooth experience.

Edited August 26, 2021 by Daniel Glasser
Add Tcl error screenshot

[thinkthinkthink]

You're supposed to choose RTL project with the "Do not specify sources at this time" checked. That's the default option and the best for beginners.

[Daniel Glasser]

Because of  the errors I was getting for 2021.1,  I uninstalled 2021.1 and installed 2020.1, which is the latest version that I've seen screenshots for, and the Diligent instructions on the page "Getting Started with Vivado IP Integrator and Vitis" write-up asserts that 2020.1 has been tested to have the same screens and behavior as 2019.2.

With this,  I can now get the board files from GitHub as indicated.

Are there any tutorials that walk you through creating a MicroBlaze on a board that does contain a Zynq device (the tutorial I linked abovve is very explicit that the instructions for the MicroBlaze should not be used with a Zynq device), connecting it to a serial port and some GPIOs, and running some sort of "Hello World" application on that? I created a project with a MicroBlaze and added a GPIO block, but am unsure what to do next to connect a UART either from the Zynq PS or add one to the fabric and route it to the pins that connect to the serial-to-USB on connector J14. I'm a software engineer, so my experience with these tools is somewhat minimal, so I need a bit of hand-holding.

If there is an example project I can import for the ZedBoard, that might help,  too.

Thanks for all the help so far.

Edited August 27, 2021 by Daniel Glasser
Clarify the question, fix some editing errors

[JColvin]

Hi @Daniel Glasser,

The Getting Started with Vivado IP Integrator and Vitis walks through you through a Hello World application for Microblaze and Zynq based designs; is that not what you are looking for?

I haven't explicitly tried using the board files from the Xilinx store (I usually copy the materials Digilent has on our Github, https://github.com/Digilent/vivado-boards, into the Xilinx/Vivado/<version>/data/boards/board_file directory and then create a project from there. The Zynq IP block that you add in through the Getting Started with Vivado IP Integrator guide handles the UART connections for you and walks you through adding GPIO connections.

The reason you usually don't add a Microblaze IP into a Zynq based design is because you'd be adding a softcore CPU alongside the already existing ARM Core that is in the SoC, so it's a bit redundant. There are a couple of materials on how to do this here and here though.

I'll be able to provide a project that you can import for the Zedboard next week.

Thanks,
JColvin

[Daniel Glasser]

1 hour ago, JColvin said:

The Getting Started with Vivado IP Integrator and Vitis walks through you through a Hello World application for Microblaze and Zynq based designs; is that not what you are looking for?

Actually, no.  I'm looking to set up a MicroBlaze in a Zynq device, whereas the linked document is a "Hello World" for either a MicroBlaze in a device without the Zynq PS or the A9 core in a device with the Zynq PS.  It is very clear on that, and the instructions do not work for the ZedBoard if you want to set up a MicroBlaze along side the Zynq PS.

Why do I need to do this?  I need to get a feel for the MicroBlaze performance, and bring up a FreeRTOS framework with a number of threads, the next step is to (with the help of the FPGA engineers in my department) bring up the A9 and have a shared memory interface between the software running in PetaLinux on the ARM A9 applications processor and the MicroBlaze in the fabric.  The MicroBlaze will also interface with some other hardware that is time critical and requires deterministic response times while  the applications processor will be doing network communications and running a number of other applications.

This is a prototype for a system that won't be on a Zynq board - it's going to be in a Kintex conneted to the applications processor via PCIe.  I'm doing this stuff on my own because when the funding comes to do it for real, I will have less than 3 months to bring it all together, and I have never done anything with a MicroBlaze before.  At the same time, I hope to learn a bit more about FPGA designs and capabilities.  I've worked on several embedded FPGA SoC projects before, but all of those have been Cortex-M microcontrollers.  I'm not looking for anyone to solve the shared-memory or other inter-processor communications issues, I just want enough experience with the environment that I can hit the ground running.  The ZedBoard was available for me to borrow to take home - I'm looking at this as professional development.  I will not be implementing the actual application on this board, but what I learn will help immeasurably when the funding at my work gets turned on.

I do thank you for your offer to help, and look forward to anything you can offer.

Thanks

Edited August 28, 2021 by Daniel Glasser
Forgot to finish the message

[zygot]

There's nothing wrong about what you want to do. It's a shame tha you have to work with a ZYNQ based board though because this will likely double the work and learning curve. But one has to work with what one has.

If you look around I'm sure that you can find application notes or project sources for implementing an ARM/Soft-Processor design. You can tie off the ARM and just proceed as if you were working with an Artix 75 device because that's roughly the equivalent of what the Zedboard PL has in terms of resources. There are applications notes for that. My suspicion is that your will largely have to work from scratch because you won't find a tutorial that has everything worked out for you. This isn't a bad thing as you are correctly trying to get up to speed before deadline craziness becomes a impediment to progress.

"The MicroBlaze will also interface with some other hardware that is time critical and requires deterministic response times"
I don't associate soft-processors with concepts like 'time critical' or 'deterministic'. Logic and state machines perhaps. But again you have to work with the requirements, and time budget, that you have been given.

On the bright side perhaps you can compartmentalize you objectives. If you aren't familiar with working with FreeRTOS and Xilinx tools then the Zedboard can provide that for your platform using ARM instead of MicroBlaze. The working theory here is that whoever designed the system architecture and decided to save time by using MicroBlaze has reason to believe that it was up to the task(s) in terms of latency and throughput. I'm not sure that MicroBlaze saves time or complexity over standard logic development, but this depends on a lot of factors.

As for PCIe I'm not sure that your platform can help much in terms of getting a 'feel' for how well the MicroBlaze will work. You can certainly to experiments with DMAing data from the PL to the Zedboard memory. The maximum possible is about 1200 MB/s which is likely way lower than any multi-lane PCIe you will have in the final hardware. A big consideration is whether or not your Kintex PCIe <--> MicroBlaze uses external memory for data buffer(s). On the Zedboard, like most ZYNQ platforms, the only DDR is connected to the PS memory controller.

The biggest problem for you to solve, at least from my perspective, is to figure out how many pound of learning effort you can stuff into the time sack that is now to when things get serious. Personally, I'd want to minimize the number of extraneous unknowns and try and concentrate on a few specific areas of investigation and learning.

Edited August 28, 2021 by zygot

[Daniel Glasser]

6 hours ago, zygot said:

If you aren't familiar with working with FreeRTOS and Xilinx tools then the Zedboard can provide that for your platform using ARM instead of MicroBlaze.

Thank you for your interest.  I am familiar with FreeRTOS, but not the Xilinx tools. I've used FreeRTOS on Cortex-M3, 4, and 7 in SmartFusion2 FPGAs and STM32 microcontrollers.  I have a lighter-weight event driven executive that I wrote that I'd love to see if I can port to MicroBlaze, but FreeRTOS is proven, thus for work I'll stick to that.

The thing that the MicroBlaze will be doing is talking to a SPI peripheral over a 40MHz connection for control and receiving messages. To service an event on the device takes at least 3 and more often 5 to 7 transfers of varying length. The eventual target of this is a large-ish Kintex FPGA on an I/O board that is already built. The I/O board connects to a processor board that has a single core PowerPC SoC. For reasons I won't go into here, we cannot use DMA between the main memory and the I/O card, and the RTOS on the PPC is a hard time/space partitioned secure kernel. All I/O access is done from user space, and the schedule gives about 3ms out of every 10 to the partition that relays data between an outboard processor connected via Ethernet and the peripheral (another communications controller). The 3ms of execution time is shared amongst several threads doing different things, not just relaying the data between the two end-points.  The current implementation cannot do more than about 20 messages per second due to the latency introduced by periods processing on the APU, so the MicroBlaze will be able to respond to events on the peripheral and put received data into a buffer queue in shared memory, another queue for outbound data from the APU will also be set up. The MicroBlaze will be dedicated to handling the data flow through the peripheral, and all the APU will need to do is to service the queues in shared memory (most of the time).  The hope is that we can improve the throughput to about 150 messages/second from the current cap of about 30.  The FPGA currently has a specialized SPI master interface that is accessed via the PCIe to AXI bridge, this is being replaced by the MicroBlaze and the shared memory (plus a few other bits).  Same Kintex FPGA has 5 GB Ethernet MACs, a heap of UARTs, and a number of other application specific IP blocks.  We're going to be using internal BRAM for the MicroBlazes.

I really can't go into much more detail, but this should give you the general idea.  We're doing this to fix a design decision made years ago without having to redesign an existing I/O board.  This is a case of having software fix problems in the hardware design.

(I have to run, so this is somewhat unedited.)

[zygot]

You've probably overshot the TMI threshold but the basic idea is pretty clear. Of course the devil is in the details and those should be confidential.

The Kintex, especially of it's a faster speed grade, is a pretty good device for products that aren't in the 'price is no object' category.

I haven't had the interest, incentive or time to do anything with Vitis, mostly because it doesn't support any of the platforms that I have to work with directly. Vivado 2019.1 and the SDK support freeRTOS natively, but don't underestimate issues learning the Xilinx version of the Eclipse IDE. You will no doubt have to make adjustments to the default settings. It might take some time even for a seasoned SW engineer to get comfortable with. By comfortable, I mean familiar with it's idiosyncrasies and bugs. So don't underestimate the learning curve. You should be able to build a ZYNQ HW system using the board presets ( assuming that you are using the correct board version ) and create a freeRTOS BSP and applications without many issues. At least the second time should be pretty simple.

There are a lot of ways to do FPGA logic development so who knows if you can achieve your goals... on time. The Kintex family is more capable than Artix which you loaner board PL is akin to. I'd expect that you can run a MicroBlaze quite a bit faster than in the Zedboard PL. Don't ask how much because I wouldn't want to hazard a guess, which would be hazardous to anyone reading it.

If I were in your position, I'd concentrate on trying to get competent with the tools as a first step. This means having problems and being able to quickly find answers from the extensive Xilinx documentation, which is frequently out of date.

BTW, I really haven't a clue as to how a MicroBlaze in a X7020 PL debugging session would look like... I doubt that the tools are going to automatically download code to the PL buffers... better spend some time seeing if anyone has done that.

Edited August 28, 2021 by zygot

[Daniel Glasser]

Update, of sorts...

I have spent the last few months working on the ZCU102 using a design provided by an FPGA engineer. Those particular questions are now answered.

I thank all who replied to my earlier questions.

I'm now starting to play with the Zedboard at home, and am running into constraint problems (Vivado/Vitis 2021.2) with a simple project, but that's another topic.

[zygot]

I hate to sound like a broken record, but the newer version of FPGA tools are frequently not the best for development with a older board, or some IP like DDR ( see my DDR tutorial )

I recently used my Zedboard with Vivado 2019.1 to produce a tutorial on using the unused UART on the Zedboard to read and write HDL registers in a PL design. The only unexpected hiccup involved WIn10 failing to enumerate the Zedboard UART. Which is another issue. Sometimes the problem with Xilinx tools is due o the state of the OS. Even for a group of PCs running Win10 and up to date with patches and "improvements" are not running the exact same OS, due to various factors. There's always something....

[Daniel Glasser]

Thanks for the response.

I have noticed that support for older dev boards is lacking in newer tools.  That's not just a problem in the FPGA world; I have some FreeScale reference/development boards that are of an earlier hardware revision, and the Freescale SDK doesn't support them anymore. I also have several SnapDragon development boards that are no longer supported by the manufacturers, and the old support files were removed from their websites.

I'm not trying to do anything fancy with the ZedBoard, but it's the only FPGA dev board I have at home.

 

[zygot]

In general, newer tools try and sell newer devices. One way to do this is to provide free IP and good support to encourage customers to spend money on the latest and greatest. Conversely, there are opposing forces to support the ever growing list of older and obsolete devices that use older fab technology with decreasing capacity.  

The Zedboard is still a great platform for basic FPGA projects. In the not too distant future Series 7 devices will go the way of Spartan 6 and older devices. It's not that these devices are no longer useful, it's just that at some point you can't make and sell them cost effectively.

I tend to view versions of FPGA development tools that were released around the time that a device was "hot" as appropriate, as long as your OS supports it. I don't use my Win7 box as much as I used to these days, but sometimes the fastest way to complete a project is to go back in time and implement a project on 5-6 year old tools.

 

[asmi]

On 8/26/2021 at 8:53 AM, zygot said:

I beg to differ. In fact Vivado is no good for doing PCIe based designs for the NetFPGA-1G-CML board that Digilent sells. I know, because I've tried. The Vivado support for PCIe simply doesn't work ( at least on Vivado 2019.1 forward ) for the XC7K325T-1FFG676 part for this board because it only has 4 transceiver lanes, because of the lanes that the board designers chose to use, and because Vivado refuses to let you select the correct GTX bank. If anyone has discovered how to do this I'd like to know the secret.

Just tried it in 2020.1 (that's the latest version I have K325 license for) - it works just fine, like I expected.

 

You simply need to elaborate or synthesize a design, and then go to I/O planning and set ball assignments to what you need.

...which is something you'd know how to do if you ever worked on a custom board (which wouldn't have any board files of course). On Kintex-7 you can use any of GTX transceivers with PCI Express Hard IP block (unlike Artix, where you have to use transceivers from the same half of device where PCIE block is).

Edited December 21, 2021 by asmi

[zygot]

On 12/21/2021 at 5:25 PM, asmi said:

I beg to differ. In fact Vivado is no good for doing PCIe based designs for the NetFPGA-1G-CML board that Digilent sells. I know, because I've tried. The Vivado support for PCIe simply doesn't work ( at least on Vivado 2019.1 forward ) for the XC7K325T-1FFG676 part for this board because it only has 4 transceiver lanes, because of the lanes that the board designers chose to use, and because Vivado refuses to let you select the correct GTX bank. If anyone has discovered how to do this I'd like to know the secret.

Trying and failing isn't proof of anything except failure. I have working PCIe based NetFPGA-1G-CML projects built with both VIvado 2019.1 and Vivado 2020.2.

Like most of the non-board design IP, the PCIe Wizard is pretty buggy and in need of some attention.  In particular, for PCIe which requires transceivers in order to work plus the PCIe hard block, you can't assign MGT banks when setting up the IP. Evidently Xilinx engineers don't ever use the tools that it's customers have to use.. or no one who makes managerial decisions cares. I've posted to the Xilinx community forum about this and the official Xilinx position is "problem? what problem? we don't have problems."

The NetFPGA-1G-CML board designers unfortunately choose MGT pins that highlight just how bad the Xilinx PCIe IP really is. There are ways to beat the tools into submission though.

• After Implementation you can open up the design and change the transceiver RX pins. This will also fix the TX pins.
• You can add MGT location assignments to your project constraints file to override the built-in, hard coded preferences of the synthesis tool.

Recent versions of the Xilinx tools just seem to be buggier and buggier with every release. The PCIe IP isn't the only one that I've had to take corrective measures with because of tool bugs or poor IP design. User experiences will vary because the tools and IP can behave differently depending on the project device or board selection. I had no problem ( well on the third try anyway ) doing a DDR design for the NetFPGA-1G-CML and my other Kintex 325T boards in Vivado 2020.2 but wasted days trying to implement one for an Artix board until I just went to Vivado 2019.1. 

For the record my experiences with Quartus is similar. I've found that for some designs there are tool versions that work out well and tool versions that don't depending on the host OS. Both Intel nor Xilinx (now AMD) have seemed to have lost control over their tool development processes... 

 

[asmi]

27 minutes ago, zygot said:

Trying and failing isn't proof of anything except failure. I have working PCIe based NetFPGA-1G-CML projects built with both VIvado 2019.1 and Vivado 2020.2.

You are quoting yourself here.

27 minutes ago, zygot said:

Like most of the non-board design IP, the PCIe Wizard is pretty buggy and in need of some attention.  In particular, for PCIe which requires transceivers in order to work plus the PCIe hard block, you can't assign MGT banks when setting up the IP. Evidently Xilinx engineers don't ever use the tools that it's customers have to use.. or no one who makes managerial decisions cares. I've posted to the Xilinx community forum about this and the official Xilinx position is "problem? what problem? we don't have problems."

The NetFPGA-1G-CML board designers unfortunately choose MGT pins that highlight just how bad the Xilinx PCIe IP really is. There are ways to beat the tools into submission though.

• After Implementation you can open up the design and change the transceiver RX pins. This will also fix the TX pins.
• You can add MGT location assignments to your project constraints file to override the built-in, hard coded preferences of the synthesis tool.

That's actually a good thing, because all pin assignments needs to happen in the single place - in I/O planning window. Which is what they did for MIG starting from UltraScale. This way if you migrate design to another device, you won't have to re-configure IPs. So assigning IO right in the IPI is an artefact of the past. The fact that you've used to it does not change anything. You will have to adapt.

28 minutes ago, zygot said:

Recent versions of the Xilinx tools just seem to be buggier and buggier with every release. The PCIe IP isn't the only one that I've had to take corrective measures with because of tool bugs or poor IP design. User experiences will vary because the tools and IP can behave differently depending on the project device or board selection. I had no problem ( well on the third try anyway ) doing a DDR design for the NetFPGA-1G-CML and my other Kintex 325T boards in Vivado 2020.2 but wasted days trying to implement one for an Artix board until I just went to Vivado 2019.1. 

Recent version of Xilinx tools are getting better and better with every release. This is especially so if you work with something more modern than 7 series. You simply fail to realize that the primary usage mode is with custom boards, which is why board support is secondary and ultimately not important, as vast majority of use cases revolve around custom boards, which is why a change to having all IO assignments in the single place (and a single file) is a positive change, not the other way around.

[zygot]

1 hour ago, asmi said:

You are quoting yourself here.

Yikes!

1 hour ago, asmi said:

all pin assignments needs to happen in the single place - in I/O planning window. Which is what they did for MIG starting from UltraScale.

For an all HDL flow IPI isn't involved. These projects use text-based constraint files for pin and timing constraints, not GUI based tools. Most commercial setting development never use the GUI version of FPGA tools for anything. Still, I do sometimes find it easier to fix problems that that tools create using this means. I've had more than a few instances of synthesis ignoring constraints and assigning different pin parameters than what was in the constraints file.

As for UltraScale, what Xilinx did depends on whether you have a device or board as a target in you project settings. If you choose the ZCU106 as a target, instead of the device, and you want to do a design for the PL connected DDR4, what Xilinx did was come up with the BOARD_PIN so that no place in your project has a text file that allows you to see what the pin constraints are. Perhaps you find this as welcome progress, but I don't.  

1 hour ago, asmi said:

You simply fail to realize that the primary usage mode is with custom boards, which is why board support is secondary and ultimately not important, as vast majority of use cases revolve around custom boards,

If this was a Reddit forum or one dedicated to board designers I might agree with that statement. This is a forum for Digilent product users. Even on Xilinx's community forums a high percentage of questions are about specific boards, not custom designs. If board vendors never had errors in their master constraints or board files, and FPGA vendor tools never made changes to their tools that weren't backward-compatible, and you ignored the code maintenance, then perhaps there's something to allowing the tools to manage projects. Unfortunately, those things aren't true, so I prefer to handle project maintenance using text based source code. I haven't into very many companies where this isn't the case.

 

1 hour ago, asmi said:

Recent version of Xilinx tools are getting better and better with every release. This is especially so if you work with something more modern than 7 series

Well, we disagree on this. I especially disagree with the suggestion that Series7 is somehow obsolete ( whatever one might infer from "more modern"). As for UltraScale, aside from being built on more modern Fab processes, is not always better, at least for those using board vendor platforms. For the simple case of 1 GbE RGMII the tools and IP are definitely worse than for Series 7 boards. Recent experience with the ZU7EV suggest that UltraScale botched HP IO for simple 125 MHz DDR interfaces. Perhaps there are ideal applications for UltraScale HP bank IO, but migrating from series7 to UltraScale can be problematic. And the tools hide the details. What the new tool versions certainly do is make it harder to use the HDL flow in a commercial setting. They do this in the IP and in the tools themselves. I don't believe that this is for the benefit of customers, but to constrain support costs.

Edited December 23, 2021 by zygot

[asmi]

1 hour ago, zygot said:

For an all HDL flow IPI isn't involved. These projects use text-based constraint files for pin and timing constraints, not GUI based tools. Most commercial setting development never use the GUI version of FPGA tools for anything. Still, I do sometimes find it easier to fix problems that that tools create using this means. I've had more than a few instances of synthesis ignoring constraints and assigning different pin parameters than what was in the constraints file.

It's the same flow for any designs, whether IPI, HDL or mixed. You can use IO planning GUI for pin assignment in all cases, or you can manually write constraints file - again, for all types of designs, and the former simply automates generating said constraints file.

1 hour ago, zygot said:

If this was a Reddit forum or one dedicated to board designers I might agree with that statement. This is a forum for Digilent product users. Even on Xilinx's community forums a high percentage of questions are about specific boards, not custom designs. If board vendors never had errors in their master constraints or board files, and FPGA vendor tools never made changes to their tools that weren't backward-compatible, and you ignored the code maintenance, then perhaps there's something to allowing the tools to manage projects. Unfortunately, those things aren't true, so I prefer to handle project maintenance using text based source code. I haven't into very many companies where this isn't the case.

I'm just explaining why they have made changes in their tools. Their main customers are not the types who buy pre-built boards, but those who design custom ones, hence those scenarios gets a priority. All constraints done via IO planning GUI are saved in a regular text-based constraints file, and so this way is functionally the same as writing these constraints manually. Some IPs are still not updated to do pin assignments in the IO planner, but I'm hopeful it will happen shortly, because it's much more convenient when all of that stuff is done in the single place, and stored in a single file.

1 hour ago, zygot said:

What the new tool versions certainly do is make it harder to use the HDL flow in a commercial setting. They do this in the IP and in the tools themselves. I don't believe that this is for the benefit of customers, but to constrain support costs.

Not even the slightest. I use HDL or mixed flow all the time, and all I noticed is that becoming easier as you move up to newer versions and devices, not harder. I especially love their move to keep sources directory clean of generated files - this was the single best improvement they've made in recent years. So I don't know what are you going on about here.

As for 7 series being obsolete - no, it's not obsolete, heck even Spartan-6 devices are still in production, but they do put most of their effort on newer devices, and 7 series is pretty much in a support-only mode. That long-standing 7 series MIG bug when a wizard doesn't preserve the frequency across runs is there for like a decade, and they could not be bothered to fix it. Same goes for lack of direct support of dual-rank memory configs - currently you can only do it via insane workaround (by declaring that you are going to use a dual-rank DIMM, then hacking around parameters to fit what you actually going to do). This sucks, but I also can't really blame them for focusing on cutting-edge stuff - this is where all money is. Remember, their cash cows are communication, aerospace and defense industries, and all of them have essentially blank cheques for components - they don't care if device is 100$ or 100K$, if the latter is what's standing between them and their goal of being ahead of others - they will not think even for a second to shell out that much. We are simply getting spoils from that table. That's why they can come out on stage and say with the straight face that $1000 devices are "low cost".

[zygot]

1 hour ago, asmi said:

Not even the slightest. I use HDL or mixed flow all the time, and all I noticed is that becoming easier as you move up to newer versions and devices, not harder.

So, let's take the example of Ethernet RGMII. I've been using the same basic RGMII interface design for not only Series7 devices but low cost Intel devices. UltraScale broke my HDL because there's no ODDR or IDDR anymore due to the way that UltraScale IO is designed. Yes, you can instantiate ODDRE1 and IDDRE1 into you HDL but that's not what the synthesis tools are going to implement. 

I recently wanted to use a FMC Ethernet card compatible with the ZCU106. The vendor has plenty of demos, all using a board design flow, all using the Xilinx rgmii-gmii IP. Now get this. Whether you instantiate this IP into an board design flow or into your HDL all of the IP core is hidden from view. In older versions of VIvado, a similar rgmii-gmii bridge IP was provided as all Verilog or VHDL code. Not the one for UltraScale in VIvado 2019.1 or later. In fact, this IP incorporates the MDI into the core, even though the PHY programming interface has nothing to do with the data interface and is the same whether you have GMII, RGMII, SGMII. Moreover, the IP now has a "virtual" PHY embedded into the core so that it's useless you setup registers to the "virtual" PHY. The IP documentation suggests the reason for this is so that the core can detect the post-negotiation condition of the PHY. The truth is that the "virtual" PHY can't communicate directly to the physical PHY, it only connects to the physical PHY as a pass-through connection... so the only purpose is to make it harder to use logic connected Ethernet PHYs without a MicroBlaze or ZYNQ. So, if I have 4 Ethernet PHYs in a design do I want to have 8 sets of PHY registers to deal with that require serial programming? NO, I do not. Is this easier? NO it is not. If I only want to do 1 GbE with my 1 GbE Ethernet PHY is it easier for me to have the thing come out of reset ready to rock and roll or is it easier to have to write to 4 separate "virtual" PHYs that have no justification for existence?

If the tools are getting better and better for you, then I'm happy for you. For a company that has to support demo code that gets broken with every new tool version and most people, I suspect that their perspective is different. UltraScale IO is more complicated, less well documentation, more restrictive in terms of pin placement if you want to use advanced features, and possibly less reliable for some interfaces.

[asmi]

38 minutes ago, zygot said:

So, let's take the example of Ethernet RGMII. I've been using the same basic RGMII interface design for not only Series7 devices but low cost Intel devices. UltraScale broke my HDL because there's no ODDR or IDDR anymore due to the way that UltraScale IO is designed. Yes, you can instantiate ODDRE1 and IDDRE1 into you HDL but that's not what the synthesis tools are going to implement.

So you've moved to another device family and expected the code to be 100% compatible? Like, really? Sorry, but that one is on you. You are just too used to vertical compatibility across all devices of 7 series family. But the reality is this is an exception in the industry, not a rule, and most other FPGA families have unique features and HW blocks not available on other series, or available but which work differently. Take a look at Cyclone II, III, IV and V - they all have different IO blocks and other HW IPs.

39 minutes ago, zygot said:

I recently wanted to use a FMC Ethernet card compatible with the ZCU106. The vendor has plenty of demos, all using a board design flow, all using the Xilinx rgmii-gmii IP. Now get this. Whether you instantiate this IP into an board design flow or into your HDL all of the IP core is hidden from view. In older versions of VIvado, a similar rgmii-gmii bridge IP was provided as all Verilog or VHDL code. Not the one for UltraScale in VIvado 2019.1 or later. In fact, this IP incorporates the MDI into the core, even though the PHY programming interface has nothing to do with the data interface and is the same whether you have GMII, RGMII, SGMII. Moreover, the IP now has a "virtual" PHY embedded into the core so that it's useless you setup registers to the "virtual" PHY. The IP documentation suggests the reason for this is so that the core can detect the post-negotiation condition of the PHY. The truth is that the "virtual" PHY can't communicate directly to the physical PHY, it only connects to the physical PHY as a pass-through connection... so the only purpose is to make it harder to use logic connected Ethernet PHYs without a MicroBlaze or ZYNQ. So, if I have 4 Ethernet PHYs in a design do I want to have 8 sets of PHY registers to deal with that require serial programming? NO, I do not. Is this easier? NO it is not. If I only want to do 1 GbE with my 1 GbE Ethernet PHY is it easier for me to have the thing come out of reset ready to rock and roll or is it easier to have to write to 4 separate "virtual" PHYs that have no justification for existence?

I don't understand your problem here. You don't like IP provided by Xilinx - no problems, just design your own. What prevents you from doing that?

43 minutes ago, zygot said:

UltraScale IO is more complicated, less well documentation, more restrictive in terms of pin placement if you want to use advanced features, and possibly less reliable for some interfaces.

Again, you are too used to 7 series, which have only two types of IO blocks (HP and HR) across entire family, and all IO pins in a single bank except for two are identical. Take a look at Cyclone V, for example - you will see that the pinout restrictions will drive you nuts in no time. The reality is that as IO speed increases, you are going to have to have specialized pins because multiplexing causes signal degradation. In that sense I still believe that US/US+ devices have less IO restrictions than competing products, which makes them more versatile. But I agree that it's more restrictive than 7 series, even if for valid reasons.

But all of that doesn't have anything to do with your claims that Vivado/Vitis somehow get "worse" with each version. I think each version bring useful improvements, even if some of those are not immediately beneficial to me.