Problem with Arty S7-25 General IO Demo

[RodRico]

OK, I'm a newbie just trying to run a demo provided for my new Arty S7-25 board, specifically the Arty S7 General I/O Demo, and I'm quite frustrated. I think these demos are intended for newbies like myself, and as such, I expect them to run without a hitch. They don't.

I installed Vivado per the instructions given on the Installing Vivado, Vitis, and Digilent Board Files page. I then downloaded the zip file identified for my Arty S7-25 board and successfully installed it via the instructions given for Vivado (as opposed to SDK Hardware Handoff) on the Using Digilent Github Demo Projects page. I then tried to generate a bitstream and found it wouldn't complete due to the following errors.

I see the identified signals in the VHDL source...

The Arty-S7-25-Master.xdc file provided with the demo has a presumably incorrect comment at the top "## This file is a general .xdc for the Arty S7-50 Rev. B" and everything is commented out except the configuration options (BITSTREAM.CONFIG.CONFIGRATE 50, CONFIG_VOLTAGE 3.3, CFGBVS VCCO, BITSTREAM.CONFIG.SPI_BUSWIDTH 4, CONFIG_MODE SPIx4). Among those pins commented out, I see all the signals that caused errors except "CLK" (the xdc file has "CLK100MHZ" and "CLK12MHZ" but has no "CLK"). I also noted that the xdc file provided with the demo is not the same as the Arty-S7-25-Master.xdc file on GitHub. I decided not to try the GitHub file because the one included with the demo is presumably referenced in the demo's VHDL. 

As an experiment, I uncommented the xdc lines for BTN[0], BTN[1], BTN[2], and BTN[3] then reran bitstream generation and got the same hard errors as before plus new errors for the uncommented lines saying "set_property expects at least one object" so it seems the VHDL isn't referencing the xdc file.

I'm now at a loss for what to do. Any suggestions (other than turning of DRC)?



 

[zygot]

So this is a quandary isn't it? How do you figure out how to use the tools and see your shiny new hardware doing something if you aren't provided with a demo that you can just install, 'compile' and run?

I suggest slowing down the rush for progress and taking the time to speed read through the Xilinx material available through the DocNav application. Read the device, tools and basic reference materials. You want to understand basics like SelectIO, clocking, constraints, etc. There are decent user guide for that. Take sine time to get familiar with the tools. DO read the Vivado reference manuals and about design flows. There are some helpful tutorials through DoNav as well.

I do recommend not assuming that what you think are the reasons for failure to get a bitstream are true and start making imprudent changes to the sources that were provided.  

Digilent, for the most part does MicroBlaze demos; and they have no idea how to do a demo that works on a different versio of Vivado than what it was created on. They are not alone with this problem. The easiest demo projects to help people using a new board are HDL only project with source code. I'm not aware of any for the S7 but it's likely that a good HDL A7 demo could be a place to start. Replicate that demo just to get through a project and then see if you can port it to your S7 board; usually this mostly involves changing pin locations in the constraints file.

In the Digilent Project Vault there are some simple UART based user interfaces that might be a good start. I'm sure that your board has a UART.

If you've been around for awhile, and it sounds like that's the case, it's really galling to be stumbling on basic things. Get over it. This is different stuff you're playing with.

[RodRico]

@zygot I don't think it's "rushing" to install a demo provided by the vendor in order to confirm the board works so I can promptly return it if it does not. I run "acceptance test" on everything I buy shortly after I have it in hand. I think most folks do.

I'm reading through piles of documentation from Digilent and XIlinx to fix the demo... I'm changing the pin names in the xdc file to match the names and case used in the VHDL while also verifying the named pins correspond to the proper pins in the board file and the schematics to prevent smoking something.

The demo I'm trying to run is specifically for the Arty 7-25. It's a simple HDL project and depends only on devices that are on the board. I was fully prepared to have to learn all the nuts and bolts necessary for my project. I just didn't expect to have to do it for a vendor demo specifically targeting the product I bought.

Shame on Xilinx, by the way, if they are changing tools so significantly from version to the next that users have to recode their work for every new version released. The shift from ISE to Vivado was significant, so porting was to be expected. From what I've leaned thus far, however, the problem with this demo has nothing to do with Vivado. It's just sloppy. 

This is also sloppy... the part number for the part at the lower left is for a 100 MHz clock, but its output is labeled "12MHZ/UCLK" and the xdc files (both the one with the demo and the more current one on GitHub) call the signal of pin F14 "CLK12MHZ" and define a period accordingly. There is another page of the schematic with a 100 MHz clock in pin R2 which is properly called "CLK100MHz" in the xdc file. I'm going to assume they put the wrong part number on the schematic for the 12 MHz clock, but I shouldn't have to be making assumptions. 


OK, I've fixed the errors preventing bitstream generation, confirmed all the pin name match across the VHDL and xdc file, verified the xdc file matches the schematic, programmed the board, and observed it's working as expected. Yay! I can keep the board and return to working on my project! I have no doubt it will require I learn a lot more before I'm ready to program the board again, but at least I know it works.

[zygot]

OK, You're farther ahead than I thought you were so... nice. And I'm glad that you could get it working.

It's clear that most of the documentation and source code that Digilent publishes is 'farmed out' and not checked before release. If I post a project to a public forum I always download the archive and build the project on a different computer than it was developed on. You'd think that a vendor would be as conscientious with what they provide their paying customers. Clearly, you are the first to have bothered to get the demo working. 

Thanks for the nice documentation of your efforts.

In a number of ways ISE is superior to Vivado. So were the non-XML versions of Vivado. But no one is going to be doing Spartan 7 development on those older tools. 

[RodRico]

16 hours ago, zygot said:

If I post a project to a public forum I always download the archive and build the project on a different computer than it was developed on.

That's good practice, but I'd be happy if they simply got the xdc file and VHDL sync'd up. It's obvious the author didn't actually run the project as posted because all the entries in the xdc file were still commented out except for those associated with configuration. It would also be nice if folks actually made the comments in their VHDL relate to the VHDL. In the demo VHDL, there are comments at the top of the file referring to a seven segment display that doesn't exist on the target and isn't coded in the demo, for example. Part of me wonders if they didn't intentionally set up the demo as a "learning exercise" or something. It was that bad.

16 hours ago, zygot said:

In a number of ways ISE is superior to Vivado. 

I rather miss the old hierarchal schematic method. For what I'm doing, I have no problem placing and connecting Spartan-7 primitives. I'm so used to that method that I'm blocking out my FORTH core in KiCAd's hierarchal schematic tools before writing the verilog version. There's a part of me that's thinking "wouldn't it be cool if someone put all the 7 series primitives in a KiCad library then wrote a tool to turn KiCad hierarchal schematics directly into verilog?" I know this isn't how professionals would implement large FPGA designs, but I'm not doing large designs and I find the visual representation helps me think through what I'm doing better than textual code. I even draw out real time embedded software... block diagrams with illustrations of data structures come first and code follows. Maybe I'm old or maybe I'm just a visual thinker.

[zygot]

1 hour ago, RodRico said:

I'd be happy if they simply got the xdc file and VHDL sync'd up

Something is horribly wrong if you post an HDL project that can't be replicated using simple instructions. It's just inexcusable.

 

1 hour ago, RodRico said:

rather miss the old hierarchal schematic method

I had experience with this for Altera and Xilinx back when I was still creating hand drawn schematics for PCB level designs. Have to say that I'm glad that this is all in the past. Mostly, companies that used that did it to avoid creating documentation that had errors and was more stuff to maintain. They simply chose to ignore all of the problems with creating and maintaining custom schematic components. I don't miss ISE IMPACT at all and the integrated ILA GUI in Vivado is a lot more useful and easy to use ( usually ). Unfortunately, newer versions of Vivado make working with reports much harder or simply won't provide it in a form that you need. On my last project build I wanted a utilization report. After an hour or so I managed to get the opened implementation to show me what I was looking for and when I tried saving the report was left with something that had none of it. Vivado has cost me hours and hours of wasted time, which is not what you want your tool to do because it encourages cutting corners to avoid spinning your wheels. It used to be a lot easier to run down timing using reports.

The world needs a list of suitable tool versions for development with particular devices. Vivado 2016.3 might be good for a lot of Digilent customers if it supports their OS and devices. I'm just not a fan of XML for building applications or using development tools like Vivado.

[zygot]

2 hours ago, RodRico said:

There's a part of me that's thinking "wouldn't it be cool if someone put all the 7 series primitives in a KiCad library then wrote a tool to turn KiCad hierarchal schematics directly into verilog?"

I've come across some interesting ideas along those lines with a few compelling demos but nothing that I'd want to rely on as a standard design flow. A lot of people would like to make the FPGA  design flow more about the design rather than the tools. You can spend half of your project time and effort just fighting the tools because of new bugs, stupid changes to the UI, depreciated but necessary functionality and reports.... really, the old tools that had one universal OS install that fit on a single layer DVD did the same stuff as Vivado 2020.2,as far as getting to a bitstream goes. For me Vitis 2020.2 was a 35h 40 m nightmare; and that was better than previous version installs. This is what happens when the people designing FPGA boards and software don't ever have to or want to used them.

If your tools take up 100 GB of HD space using XML, TCL, script code generators everyone has an unmanageable problem, mostly the users who have to deal with what they've been given. The world has changed since the ISE days.

[RodRico]

3 hours ago, zygot said:

A lot of people would like to make the FPGA  design flow more about the design rather than the tools.

Translated into the software world, you've just expressed the motivation behind FORTH. The language is simple but immensely rich, and the development environment couldn't be simpler. I've written incredibly complex applications that are remarkably brief using nothing more than a text editor and the integral interpreter to complete unit and application test. Hello World in FORTH is simply : HELLO-WORLD ." Hello World." CR  ; typed into the interpreter/compiler. Once I finish my FORTH core, the whole environment will reside on the board and there won't be a "development flow," just typing the same things into a text editor that you would otherwise type at the console. I wish FPGA design could be made so simple. Maybe it can.

[RodRico]

@zygot You, know, maybe I'm looking at this upside down. Early in my career, I introduced FPGAs (and DSP) to the subsidiary I worked in. Over time, the number of FPGA programmers increased dramatically. Among that group, I was unusual in my use of hierarchical design using schematic blocks; most folks just made big flat designs. The hierarchical method is, however, the only way to deal with the very large designs made possible with the huge FPGAs of today that are programmed by teams rather than individuals. This should have pushed our tools toward hierarchy, so I went looking for it in the tools. I think I found it in the IP Integrator. 

I tend to think of IP as a vendor product, but when I read Designing IP Subsystems Using IP Integrator (UG994), I see I can create my own IP using methods very similar to the hierarchal blocks I am most familiar with. While clearly geared toward using 3rd party IP, I don't yet see anything preventing me from defining the IP in its entirety without referencing 3rd party modules. I also see promise in Hierarchical Design (UG905) which describes how to make prerouted and preplaced modules are generated. 

Bottom line, I've been so focused on small projects that use a couple of verilog or VHDL files that I missed the more sophisticated options of the IP Integrator and hierarchal design. I still have a lot of reading and experimenting to do, but I'm beginning to come around to how the opinion that the modern tool set is well suited to hierarchal block style design.

[zygot]

Get used to having those "Oh did someone just flip the light switch?" moments. The more you learn the more open becomes the space to explore. A lot of constraints that hold back designers from being free to design revolve around simple conceptual blocks that have little to do with actual problem solving or basic knowledge and skill. This is, in my experience a universal truth, no doubt due to how human brains work.

Also, get used to the notion that one breakthrough sending you i one direction can lead to another, sending you back the other way after having enough experience. Be aware that FPGA vendors don't provide IP and an IP design flows out of the goodness of their hearts and to encourage their customers to be independent. Why would they? So yes you can create and integrate your own IP using Xilinx board design flow ( don't expect help in providing encrypted source IP like they do though... ). I've done this as a learning exercise.  I don't do this as a normal way of designing because it's just a lot of extra work and I haven't found any benefit for my efforts outside of ZYNQ AXI PS/PL integration. But that's just me.

Unless your goal is to release embarrassing demo projects sticking with VHDL and Verilog as design sources ( what you write is your IP isn't it? ), and intelligent use of a few basic vendor IP for resources like clocking, you have the opportunity to produce robust, easy to replicate  HDL projects that won't be crippled with every new tool release. In the end most people want as much control over their work as is possible.

I can't, and don't have any interest in trying to tell anyone what paths to take for their own personal goals. I can dispense general insight based on a lot of experience that might be helpful.

I will add that I've recently used AXI IP on a current project in Vivbado 2019.1 using packaged IP for a ZYNQ project that I created years ago in Vivado 2014.2. So, at least Xilinx has decided that breaking user's packaged IP isn't worth the hassle. This isn't true for a lot of what is provided with the tools. In fact, a recent tool release made fundamental changes to how even basic IP like clocking is done so that every project created by older versions of the tools are broken until you re-create the IP with the current version.