BMiller

Gee, that's refreshing to read. Perhaps I'm not wasting my time trying to help people with their problems after all...

Hello,
I've posted a new tutorial on Project F covering Tcl build scripts with Vivado:
https://projectf.io/posts/vivado-tcl-build-script/
It's surprisingly easy to automate building your design with Tcl. I wish I'd known this when starting out with my Arty board back in 2018. Anyway, I hope you find this useful, and please do let me know if you have any suggestions or spot any errors.
Cheers,
Flux

I can't speak to the sample program specifically, but when malloc fails it usually returns NULL. So try 
if (flash_env == NULL) {
  return XST_FAILURE;
...
Note, you probably have to include stdio.h to get the definition of NULL. 
Disclaimer: It's been 40+ years since I regularly programmed in C.

According to UG909 (I looked at 2021.1): 
NB: "Dynamic Function eXchange" is what Xilinx is calling the feature they used to call "Partial Reconfiguration".
B/R
 

@BMillerThanks for the correction. UG909 has a list of supported devices and all of the ZYNQ-7000 series are included. I was aware of DFX but hadn't connected it to partial reconfiguration.

According to UG909 (I looked at 2021.1): 
NB: "Dynamic Function eXchange" is what Xilinx is calling the feature they used to call "Partial Reconfiguration".
B/R
 

I've been dealing with programmable logic vendors for a long time. The following is speculation, but perhaps informed speculation. FPGA vendors don't give anything away for free. The first thing that they don't want to do is let customers think that they can use a smaller part or part from a cheaper family to accomplish their goals. So, when they are nice, they just make it hard to use certain device features with cheap parts by either restricting documentation and application notes or making it hard to use their IP with cheaper parts. When they don't feel like being nice, they disable the capability to use a feature in the tools. One example of this is using transceivers for Cyclone V JESD204 applications. They advertise transceivers in Cyclone that can do JESD204. They advertise JESD204 for Cyclone. But I'd be interested if anyone has found a way to actually implement a JESD204 design for Cyclone V using the free IP that comes with Quartus; the tools say nah Stratix only. Transceivers have historically been a feature used to sell more expensive devices. Every Artix device sold has at least 1 transceiver in it. You wouldn't notice reading AMD/Xilinx Application Notes and White Papers.

Besides now wanting a cheap family to undercut sales of expensive devices, vendors really don't want customers thinking that they can port designs to a device from a competitor. That's why FPGA vendors put so much energy into proprietary soft-core processors and SDK tools. You simply can't port them to a competitor's tools. Better yet, you can make customers reliant on soft-core IP to do things like Ethernet connectivity. If an FPGA vendor thought that a particular market sector application was important enough to take away sales from a competitor you can be sure that they will provide the IP to do so. Xilinx, in particular like to restrict some IP, like video., to AXI buss implementations that might make sense for ZYNQ and are required by MicroBlaze because it uses more memory and is more complicated than the average customer wants to invest time in.

Of course, down the chain are "partnerships" with IP and hardware vendors. There's a certain amount of loyalty to those loose agreements; similar to the phrase "loyalty among thieves", depending on the marketing aims of the moment.

You don't necessarily have to buy HDMI IP. While difficult, you can do video applications without it. Long time, but recently absent, user hamster has done valiant work in this arena.

In the end programmable logic vendors are businesses ( though 80% of the FPGA market is now property of CPU vendors with their own agendas ) and businesses have to make money, so I'm not sure that reasons for why they do things are all that important to their users.

As an aside, I've recent read that Intel is going to go to a marketing scheme where a customer can purchase functionality, for a price, that can be "enabled" in their CPU devices on live end-user products. That's where the world is headed, whether you like it or not. The age where companies competed for customer sales by providing a better product, or better service has been dead and buried for a while now.

Thanks, fixed it!

Some of us can't handle the high glycemic index beverages...

This is a good project, though perhaps LEDs aren't the best indicator of functionality...

The Ethernet PHY is a great general purpose interface. It's basically a cable modem. If you understand, or want to understand some basic modem concepts it's a great interface to learn about. A 1 GbE PHY can do over 120 MiB/s, sustained data rates each direction in full-duplex operation. Unlike most serialized interfaces, Ethernet can be highly predictable in terms of timing.

The place to start is to read about how Ethernet works. Unlike most popular serial interfaces, specifications and descriptions of the protocol and physical layer are public knowledge and freely available. It's well worth the effort as all FPGA vendors only provide Ethernet support connected to encrypted MAC IP . With UltraScale, ADM/Xilinx further obfuscates and abstracts even basic PHY DDR connectivity making understanding what they do almost impossible. Who wants that?
The Digilent Project Vault is an un-curated, hard to use mishmash of projects with source code, projects that need someone to debug the code, and inappropriate posts that belong somewhere else so finding useful information there is difficult... but.. there are a number of projects with HDL code that might help bootstrap your project. Regardless, of how you proceed, understanding basic serial communications concepts, and in particular Ethernet physical layer operation and basic packets types is essential if you want to know how to tak advantage of this interface. Ethernet is, by design, packet based but you don't have to use standard packets to use it effectively for point to point communication.

Have you seen this? https://forum.digilent.com/topic/16802-ethernet-phy-test-tool/

There are a few such projects of varying usefulness in the Project Vault. There are also HDL Ethernet projects with code on the Internet.

Hi,
I have progressed to wiring FSMs on an Arty board and I would like to delve deeper into ethernet and get a first hand understanding of it. As a base project I am thinking of creating a circuit that would blink board LEDs if a packet with certain content is received.
I also see that many existing tutorials use ready Ethernet IP cores, which is not what I'd like to do - I want to recreate ethernet from the ground up. How to go about it?
 
Ed

That's an easy question to answer. Everything is your responsibility. That's one reason why FPGA vendors make it so hard to use this interface; it pushes inexperienced FPGA developers and students into using soft-core processors and expensive ( in terms of resource utilization ) IP and bus structures that are incompatible with all other FPGA vendors. There was a version of Quartus, a long time ago, that offered a RGMII-GMII IP with HDL source ( script generated but readable ). ISE provided basic PHY interface source that could, with some difficulty, be worked out.
The first step to using an Ethernet PHY is to get the data interface working. GMII is a SDR ( one bit per clock ) interface and appeared on older Digilent boards like the original Geneis and ATLAS. RGMII is a DDR ( 2 biits per clock ) interface and uses half the required data bit pins and is more common on current boards as it saves IO and is easier to route PCB signals. So, the first step is to understand how all of the PHY interfaces work. You can find this information in some PHY device datasheets ( Marvel is notorious for requiring a NDA to get complete datasheets but became popular because Xilinx boards used it ). The Ti PHY data sheets describe the data interface pretty well.
Now, there's a bit if a issue with PHY devices that support multiple data interfaces. The old Marvel 88E1111 PHY on the ATLYS can do GMII, RGMII or SGMII. The bad news is that the device may come of reset configured with the wrong data interface and you might have to reprogram the control registers using the slow MDA interface. The good news is that Digilent board are set up to use the correct data interface at the maximum data rate. Which brings up the second issue. Ethernet PHY devices are backward compatible to support slower data rates. The PHY on your board only supports 10/100. The 88E111 supports 10/100/1000. The same problem of how the device is configured out of reset applied to data rate. 10BASE-T uses a different modulation scheme than 100BASE-T or 1000BASET, and a different clock. Again, Ethernet PHYs on Digilent boards are configured to use the fastest data rate available for that PHY. There's other similar issues like auto-crossover, what data speed the PHY advertises, etc. These all can be changed via the MDA interface.
What I do is make using the Ethernet PHY as simple as possible. No MAC, only use the maximum data rate ( no clock switching ), minimal functionality in terms of standard packets, no fragmentation support, no re-sending bad packets, etc.
So, let me offer a task list to consider to get you started.
The First step is to get your FPGA design to talk to the PHY. For you board this means the data interface. The second Project Vault link that I posted earlier can help with that. You also need a HDL serial MDA interface to configure the PHY registers as you will see below.
Learn about the different PHY data interfaces and how your PHY is set up. Read and write the PHY control and status registers using the MDC and MDI (bi-directional) pins. Create a data interface supported by how the PHY is connected on your board. You probably have to learn how to use the DDR IO capabilities of your FPGA. This is not trivial and I'd suggest a side project doing just that to get experience. DDR typically requires timing constraints. In trivial designs you can get away without using timing constraints. Generally, advanced IO features require timing constraints like setup for inputs and delay for outputs relative to a clock. If the PHY clock period is much longer than FPAG routing and IO delays you might get away with pretending that timing constraints aren't needed. For 10BASE-T perhaps. For 1000BASE-T no. The more data bit in the interface the more spread in clock to output between them. Once you believe that you have a workable data interface it's time to try and send/receive data. Ethernet PHYs have a loop-back capability that is useful at this point. Whatever data your FPGA application sends to the PHY will be returned. This is a good way to test out just how robust your data interface is. Nothing happens on the cable end of the PHY but the FPGA/PHY data interface can be extensively tested. Once you are writing/reading PHY registers and reading the correct loop-back data from your PHY you are ready to connect it to another Ethernet PHY. This could be a uController, another FPGA board, or a PC. The PC is a whole ball of wax as Ethernet is handled by the OS. My PC has 2 Ethernet PHYs and one uses DHCP for Internet use while the other uses a static IP address and is used to communicate with an FPGA board, Raspberry PI, or other development board. It's always a direct cable connection because switches and routers present more complication and require more supporting packet types. Here's a tip. You don't need standard packets to use an Ethernet PHY, but the PHY is a modem so it needs timing information that needs to be refreshed periodically. This means that you can't just send 1 MB through a PHY. You need to send packets of data of reasonable size, say <16 KB) Every packet has to start with the same synchronization preamble. This identifies the first data bit in the serial stream and keeps the modulation/demodulation working over time. After the preamble you can have all data, header fields and payload data, a CRC field or not... anything that is appropriate for your application. If you FPGA wants to talk to a standard Ethernet node, then your FPGA application will have to support a few standard packets. You don't need a processor to do this. Verilog or VHDL is more than capable.
I learned of of this stuff the hard way. It took me a year or so to find and work out all of the surprises. If you want to proceed with this be prepared to expend some time and energy on it and not expect to be an expert or complete a real world application any time soon. Don't have a goal of connecting your FPGA board to the internet. Windows, Linux and other OSs can't keep my PCs safely connected to the Internet so the chances of my FPGA doing that is pretty  much zero.
 

I (almost) always specify a device part number rather than a board in the project setting because I do an HDL design flow rather than the IPI design flow. I mention this because I do run into this situation for larger designs using multiple clock domains sourced by unrelated external clocks. Being unaware of all of the constraints in a design can indeed cause problems. Your observation about the MMCM placement being correct for an external clock that might be good for an external clock pin assignment in the board file sources is more than interesting and worth tracking down. I figure that one needs to be familiar with the quirks and habits of one's team mates if one wants to win games. In the case of FPGA vendor tools it's not always clear that they are on the same team as I am. I decided a long time ago that letting the tools be in charge was not in my best interests even if that meant more work for me. I keep coming across reasons to continue with that strategy every once in a while. New tool versions introduce new bugs and odd behaviors as documentation doesn't keep up with syntax or database changes and updating scripts get overlooked. The trend with the big FPGA vendors is to 'encourage' ( or force ) users into letting the tools manage the details of a project, so I find myself fighting with the tool even more than previously.

You'd think that the tools would find a problem with an initial placement strategy that would lead to a hard error early in the analysis phase and terminate processing well before going through a complete analysis and implementation run. You'd think that making a 'pre-processor' that identifies confusing source constraints very early in the operation of the tools and notifies the user wouldn't be that hard to do. No doubt, companies that run the tools from home-grown scripts rather than the GUI interface do this as finding some problems before going through the algorithm crunching phase should save a lot of time.

FPGA vendor tools don't reveal all of the 'tricks' behind the curtain. Sometimes this causes consternation and mysterious and seemingly bizarre behavior. Either you investigate or just move on. In general modern FPGA devices are so good that most designs never need that much hand holding in terms of timing closure. It might be wise to just put off worrying about having designs that are 'non-optimal' until timing closure becomes a problem... or not. I tend to stick with older tool devils ( versions ) that I know unless there's a compelling reaons not to so spending the time to resolve such quirks makes more sense. When I do need to use a newer version of the tools there tends to be a limit on how much time I'm willing to choose to spend fighting the tools verses how much time I have no other choice.

[edit] It might be an easy and simple experiment to create a separate project, using the same sources, but targeting the proper device rather than your board. I do similar sanity checks when confronted with odd issues that seem to be very weird. A/B testing is a tried and true form of debugging, particularly when you are debugging the tools. More often, I find myself doing this with a different version of the tools on a different PC host to help expose release bugs and quirks. This works best with HDL designs of course as breaking old IP is a constant feature of new tools. I'm very cautious of letting the tools know more than they need to about my designs and platform because what exactly they do with board files isn't well documented or transparent. I do know, based on experience that the same IP, when used in native mode for the HDL design flow, doesn't get implemented the same way or work the same way as when used in the IPI flow... at least for the few times that I've tried doing this to test out new FMC mezzanine cards. Generally, the time saving and detail hiding options of FPGA vendor tools ends up giving me more problems than any imagined benefit. I do recommend that no one ever try and run two instances of the tool on the same host as this is a good way to expose some really bad coding practices on the part of the tool developers, in particular for Vivado.

Hi @DougM,
Not a direct example no. The main thing that I am curious about (but have not directly looked into) is to see if Xilinx's own built in SREC Bootloader example has made the switch over from the now depreciated xilisf library to the (Xilinx) SPI library.
Based on this Xilinx article, https://support.xilinx.com/s/article/73329?language=en_US, it would seem that most of the functions offered by the xilisf library have been consolidated into single functions (like the transfer, erase, read, write, GetDeviceInfo, WriteEnable, etc.; all have their functionality achieved through XSpi_Transfer), leaving a lot of the specific functionality up to the end user. In theory, it would be a straightforward port of library functions, albeit time consuming, but I do not know if Xilinx has done this for their own examples.
Everything on the Digilent side of things in terms of following the tutorial you linked should be good to go since we don't directly use the depreciated xilisf library as far as I know.
Thanks,
JColvin

Well, I've got this working (mostly). I found the following guides quite helpful.
https://shadowcode.io/microblaze-srec-spi-bootloader-hardware/
https://shadowcode.io/vitis-srec-spi-bootloader-software/
I still don't have the system booting without help on power-up. I have to press the "prog button" but the configuration and app are loading and running correctly. That's the next thing to track down.
cheers
doug
 

Thank you very much for your information Zygot, but given my interest, as long as the DSP48E works and the NetList is available, I can work without problems with MATLAB DSP HDL Toolbox, HDL Coder and HDL Verifier. I don't want interference, I don't need complications, just versatility and simplicity, to work as fast as possible.
The Versal Premium board is much better for me because it has everything I need to implement my projects in different ways, but I don't think I'm in a position to mortgage my apartment to get the Xilinx VPK120 Evaluation Kit.
I need something simple and fast, so that later I can scale up and have some luck to get into some technology project incubator, so for the moment I'm on my own.