Eclypse Z7 First Impressions

[zygot]

First off the two ZMOD offerings by Digilent are well designed with uncommonly good documentation. Well done, and thanks for adding SYSYGY support. I would have preferred a non-ZYNQ platform... but.. The Eclypse Z7 with one ADC and one DAC ZMOD is a good value and sets itself apart from anything else in the Xilinx FPGA development board space. .

Software support is another matter. I realize the effort, due to your framework, is immense and hopefully not complete. It's just too complicated.  I spent almost a day before being able to build and run the Linux based demos for the ADC and DAC ZMODs. Started with a WIn10 Vivado installation and still haven't managed to build anything. It took a while but I did manage to build demo executables for the Linux based projects on Unbuntu 19.10 using the Vivado 2019.1 SDK. Admittedly, I'm not a ZYNQ expert but I can create a Vivado project using one of the available hardware interfaces, build a bitstream and a standalone application for any other Z7xxx board in about 30 minutes from scratch. My advice is to use a Linux host for Eclypse development.

It may be that I'll create a Linux application for the Eclypse/ZMOD one day, but I'll want to run the application from within Linux, not the SDK. Hopefully, the lack of an HDMI output won't be an issue. I'm hoping that you have a path envisioned to let users do that.

My expectation for getting started with this system was to use my normal flow by starting in Vivado, creating a bitstream supporting the SYZYGY ports and use the SDK to create an application. Normally, this is almost trivial. For any of the ZMODs this is impossible as things stand.

Will there be a process for creating a bare-metal standalone bitstream and application in the near future that remotely resembles the 'normal' Xilinx tools flow?

P.S. I can kinda understand the costs of providing a bootable SD card to run the pre-built demos but really... you couldn't afford to provide 8 screws to attach the ZMOD modules to the Exlypse Z7?

[zygot]

44 minutes ago, Ciprian said:

Unfortunately the nature of the Zmod connector dose not allow us to create a board-flow for it; this means that you  will have to connect the external ports to the xdc manually.

Well, that and the fact that you provide no means to re-created the SW bitstream and associated export files that go with the SW demo code. I think that user's of this product line would expect to use the SYZYGY ports and pods interchangeably with other SYZYGY platforms and pods. This does touch the entire HW/SW framework for these kinds of platforms. At this point having the ZMOD controller IP available isn't sufficient to create a board design. I'm not too worried about manual location constraints assignments as I usually want to use the VIvado board design wrapper as a component in a higher level hierarchy and have to do this anyway. While there may not be timing constraints required for your current ZMOD offerings I would expect that this is not a general expectation. Currently, placing your ZMOD controller IP in a board design leaves no way to connect it to either the ZYNQ7 or external pins using automation. In the interim perhaps you could provide a 'recipe' for re-creating the hardware in Vivado used with the SW projects.

[edit] I did just now follow the link that you provided above and hadn't noticed the process for adding a heirarchal block... will try it asap. There's a LOT of disconnected material to reference in order to experience your Eclypse Z7 demos in action. Generally, all I want from a demo is to verify that the hardware and supporting code work, and that this is a simple, easy, quick process. When it takes a day or two to run a demo that suggests that things are a bti too complicated, at least to my way of thinking.

44 minutes ago, Ciprian said:

Could you please send me the changes that you have made so that we can look in to it and correct the potential issues?

I do keep notes about what I'm doing but they might not be sufficient to answer your question. I might need to some time to re-create what I've done and run into. I do remember that the part about linking the zmodlib to the projects was problematic on both OSes.

After thinking about it I do remember that un-compressing the sysroot file structure in Windows had warnings about losing links from the 7-ZIP utility that I used in WIN10. This could well be the problem that the SDK had with SYSROOT. The warnings happened decompressing the tar file.

[vicentiu]

7 minutes ago, zygot said:

After thinking about it I do remember that un-compressing the sysroot file structure in Windows had warnings about losing links from the 7-ZIP utility that I used in WIN10. This could well be the problem that the SDK had with SYSROOT. The warnings happened decompressing the tar file.

That is the problem. We'll work on getting a SYSROOT Windows can digest.

[Ciprian]

12 minutes ago, zygot said:

Well, that and the fact that you provide no means to re-created the SW bitstream and associated export files that go with the SW demo code.

Actually, there is a way of recreating the Vivado project from which the .hdf is obtained. You can do this by using the digilent-vivado-scripts inside the Eclypse-Z7-HW repo. This approach requires you to have the Eclypse Z7 board file, otherwise it will fail. You can use it with both python and from within Vivado... the README.md inside will provide all the information you need.

-Ciprian

[zygot]

42 minutes ago, Ciprian said:

Actually, there is a way of recreating the Vivado project from which the .hdf is obtained. You can do this by using the digilent-vivado-scripts inside the Eclypse-Z7-HW repo.

Again, too complicated, too many balls to juggle.

But, I will try using the scripts because using the vivado-heirarchies supporting code didn't get me a validated board design.

I did clone the vivado-heirarchies and use the provided tcl script to add it to my WIN10 test project block diagram. After running the connection automation the DAC had no issues but the input clocks for the ADC were unconnected and there was an orphan clock-wizard block with it's outputs disconnected. The external pin nomenclature does seem to be consistent with the hierarchy constraints for each ZMOD though not the EclypseZ7 master constraints file.

[edit] THe above is partially, correct. Actually, both the ADC and DAC hierarchys had input clocks that were unconnected. I could make a guess about the sysclk inputs but the clock-wizard block only had one output clock...

[zygot]

1 hour ago, Ciprian said:

You can use it with both python and from within Vivado... the README.md inside will provide all the information you need.

So, what come to mind is the old saw " We can do this the easy way, or we can do this the hard way..."

As a customer I don't mind doing it the hard way as long as the hard part only involves the vendor and my time isn't wasted hunting down specifics or exploring dead end trails. Let me suggest that the easy way for Digilent when releasing a product is to have someone at Digilent with minimal technical skill run through all of the steps in verifying that the customer experience matches what the developer's believe that the customer's experience will be. The extra step seems counter intuitive and expensive in terms of time and resource management but at the end of the day is far more efficient, less embarrassing, and makes for happy customers who find extra money to spend on more stuff.

So frankly, I do remember looking at the HW git repository and seeing that it was largely unpopulated and skimming through the readme files ( so many readme files and links and references to work through just to see a demo run...) and deciding that there must be a better way than figuring out how to run the versioning scripts. As it turns out it appears to be the only way for users of the Eclypse Z7 at the moment.

So please help me out with a short recipe that fills out the HW repository with a Vivado project supporting both ZMODs in their respective port locations that exports SDK sources compatible with the demos. ( BTW, none of the bare-metal demos compiled either for me on either OS but I'm not too concerned with that yet. )

PS. Your versioning system might be great for your developers but it shouldn't force a customer to change the way they structure their development.

[zygot]

@ramanf,

It's a shame about the ZMOD demos. So the Eclypse-Z7 demonstrates the difference between saying "let's do our usual thing leveraging what we've done in the past and slap a few standard SYZYGY ports on it" and saying "Let's embrace the SYZYGY standard with something new that shows off what it (and we ) can do".

Clearly, while the ZMOD demo code shows that the pods work, the overall design approach and IP settles for a limited capability and restricted application use case. I don't understand it either.

The hardware is still useful, though I doubt that anyone is going to capture  5 million 100 MHz samples of anything with it.  I suppose that Digilent could prove me wrong with a better demo but I'm not waiting around for it ( as anyone can see from reading this thread so far support has mostly been along the lines of "I don't see any problem, you just haven't' read the documentation") . There are still plenty of problems that can be solved with the hardware and your own IP involving a much reduced final data rate to whatever storage is available. Unfortunately, for the Eclypse-Z7 that's all on the PS side, so data processing and reduction has to be done on the PL side. Not great, but not necessarily a show-stopper for every application.  What's disappointing is that hitting the target wouldn't have been either expensive or difficult.

[zygot]

On 2/14/2020 at 10:41 AM, Ciprian said:

Actually, there is a way of recreating the Vivado project from which the .hdf is obtained. You can do this by using the digilent-vivado-scripts inside the Eclypse-Z7-HW repo. This approach requires you to have the Eclypse Z7 board file, otherwise it will fail. You can use it with both python and from within Vivado... the README.md inside will provide all the information you need.

I have to assume that this statement is based on experience. So how, exactly, did you do this based on the repository documentation?

[zygot]

Anyone can order an Eclypse Z7 with an ADC and DAC module as I did. This provides 4 channels of 100 million samples of data per second. This aggregates to about 800 million bytes of data per second. One way to handle this on a ZYNQ based platform would be to put the PS DDR external memory in the data path of all four channels. How 4 DMA channels of nearly 200 MB/s per channel would work out on a ZYNQ7 system with the ARM cores using the same memory is not something that I've worked out or even have a clue about. I have both of the only two ZYNQ based SYZYGY platforms that exists and neither vendor has demonstrated that they've figured this out yet either,

Fortunately, none of the projects that I have in mind for the Eclypse Z7  require the PS external memory to be in the data path of all 4 converter channels. There is only one non-ZYNQ based SYZYGY platform that I know of and for which this isn't an issue. I just thought that it would be productive to point out the elephant hiding in the corner of the room. He's hard to miss. As long as he doesn't know that you see him I don't think that he's all that scary. Perhaps someone else has figured out how to make acquaintances with him and enjoyed the encounter and can share.

[artvvb]

On 2/17/2020 at 6:31 AM, zygot said:

I have to assume that this statement is based on experience. So how, exactly, did you do this based on the repository documentation?

With regards to this, the process is described in Workflow 5 of the digilent-vivado-scripts readme. In addition to these, the steps in the Eclypse Z7 Git Repo Documentation's Navigating and HW sections should be used after cloning, and before running any scripts. I am looking into getting these steps all in one place.

-Arthur

[zygot]

3 hours ago, artvvb said:

I am looking into getting these steps all in one place.

Thanks. You understand that any process for building a project that involves a Git repository will work differently on Windows and Linux platforms. I appreciate the complexity that's involved. Xilinx is the source of much of the difficulty but adding more layers of complexity onto layers of source material that is constantly being broken may not be the answer. For customers the goal is to be able to quickly and easily verify that newly acquired hardware works as expected and demonstrates that there's a path to moving on to the effort of putting that hardware to work doing what it was purchased for. Because the Eclypse Z7 adopts the SYZYGY plug and play framework you have the extra work of meeting customer expectation of inter-operability inherent in the framework. Personally I believe that SYZYGY is a big deal. Being an early adopter has market advantages but this comes with an out-sized burden of effort; and this is likely an instance where "work smarter not harder" is an appropriate admonition. 

[zygot]

@artvvb,

I'm busy trying to do other things but I have read through all of the material you reference and still have not been able to figure out how to re-create the ZMOD SW Vivado hardware export files, on either Win10 or Linux hosts. It doesn't help that there are multiple Eclypse Z7 hardware repositories. I really don't see the point of the OOB demo at all.

[artvvb]

The material I referenced discusses how to recreate an HDF file from the sources. After this, using the demos in baremetal should only require updating the hardware specification for the SDK hardware platform to the new HDF in the SDK workspace in the SW submodule. Using them in Linux requires retargetting the petalinux project (the OS submodule) to the new HDF and rebuilding it (I am less clear on this process, but the Adding Zmod Support in Petalinux guide should cover the relevant commands) - this is only possible in Linux, due to the Petalinux installation requirements.

The OOB is the source for the demo programmed into flash during manufacturing. It's really barebones, but is intended to be enough to know that the Zynq can be programmed and actually works. There is currently some duplication of these sources between the OOB branch/es of the Eclypse-Z7 repo and the Eclypse-Z7-OOB repo - I am looking into resolving this.

-Arthur

[zygot]

2 hours ago, artvvb said:

The material I referenced discusses how to recreate an HDF file from the sources.

Well I've tried following the material that you've referenced and have not gotten a board design that is gets validated or is complete. I've tired it on Win10 and Linux. The Eclypse Z7 has a vivado-library that is different than what you get if you just clone or obtain a zip of the git vivado-library repository. I'm pretty convinced by now that no one from Digilent has tried this on a PC that isn't connected to Digilent's IT network. If anyone had it wouldn't take more than 10 minutes to write out what they did and on what platform they did it, and certainly not more than a few lines.

[zygot]

Suggestions:

•  Don't try to build the linux ZMOD demos on Windows until Digilent figures out how to deliver the SYSROOT file system to Windows
•   Importing both the bare-metal and Linux ZMOD projects into the same SDK workspace doesn't work
•   Don't get Digilent Git Repositories on Windows in a zip archive.
•   Don't collect all of the Eclypse Git repositories individually.
•   Don't try and create a custom board design for ZMODs using the normal flow. I was able to install the Digilen vivado-library and vivado-heirarchy repos in Vivado to get a not quite complete design. I'm not sure what Digilent's end game is for making their SYZYGY platforms truly plug and play.

  To build the bare-metal ZMOD demos on Windows:

•  First you need to have installed the Windows Git terminal Application
•  Open the Windows GIT application, and in the terminal 'cd' to wherever you want the new project. I used D:\Projects\Vivado_2019_1
•  Execute git clone https://github.com/Digilent/Eclypse-Z7 --recursive -b zmod_adc_dac/master in the GIT terminal. This created D:\Projects\Vivado_2019_1\Eclypse-Z7
•  In the Git terminal cd to another location where you want the Eclypse-Z7 repositories. I used D:\Updates\EclypseZ7
•  Execute git clone --recursive https://github.com/Digilent/Eclypse-Z7.This created two folders:  D:\Updates\EclypseZ7\ECLYPSE-Z7 and D:\Updates\EclypseZ7\ECLYPSE-Z7-SW
• Open Vivado 2019.1
•  In the TCL Console change the directory to D:\Projects\Vivado_2019_1\Eclypse-Z7\hw\digilent-vivado_scripts
•  In the TCL Console ran: set argv ""; source digilent_vivado_checkout.tcl. This created a validated block design and HDL wrapper
•  Generate a bitstream
• Export the hardware and bitstream
• Launch the SDK from Vivado but don't change the workspace ( keep as local to project )
• Import the non-Linux projects from D:\Updates\EclypseZ7\Eclypse-Z7-SW. Make sure to check the copy to workspace box! We want to use the HW export files that we just created, not those in Eclypse-Z7-SW

The SDK should build the demos without error. Make sure that your Eclypse-Z7 is set to startup in JTAG mode. Configure the FPGA from within the SDK. Run either of the demos as hardware. You should see a very linear 27.78 KHz ( as I recall ) 3V pk-pk  triangle waveform on the DAC ZMOD CH1 SMA.[edit] I just checked this again on my way to doing something else and the DAC demo puts out a nice triangle waveform that's 3V pk-pk when using a 10X 1 Mohm probe. When connecting the output directly to a scope through 50 ohm cables with 50 ohm termination I get a much larger waveform with an offset that's clipped at the top. For some reason Digilent didn't see fit to use both channels of the DAC even though the hardware and board design support doing so.

I don't know what to make of the ADC demo; guess I'll have to pore over the application source code; but the SDK console did spit out some ADC measurements.

The Vivado SDK IDE maintains it's own database and can be difficult to work with. I didn't manage to run the bare-metal ZMOD demo on the first 3-4 tries and had to go through the Vivado HW export process a few times overwriting previous local workspaces.

For the ZMOD Linux demos life is more difficult. Currently, you can't build the demos on Windows due to SYSROOT issues. The documentation in the ZMOD Base Library User's Guide for linking the demo projects to the zmodlib source just didn't work for me.

The whole "support delivery' structure is a mess as far as the user is concerned. I wasted way more time than should be expected just trying to do what should have taken an hour or so to accomplish.

[zygot]

If you haven't worked this out yet the following information might be interesting:

The Eclypse-7 XC7Z020-1CLG484C has Artix equivalent PL and the 7020 fits between the 75T and 100T devices
                             Z-7020    XCA75T           XCA100T   
  Logic Cells     85K           73.75K            102K
  LUTs                53200      47200               63200
  BlockRam     560 KB     472.5 KB         607.5 KB
  Flip-Flops      106400    94400              126400
  DSP Slices     220            180                   240
- The -1 has 667 MHz Dual ARM cores

- for reasons that only Xilinx knows, the values for the listed resources for the ZYNQ and ARTIX families are incompatible with each other. I assumed that the for the ZYNQ 85K means 85x1024 so I adjusted the Artix values accordingly,  LUT and Flip-Flop values for the Artix devices were based on 4 LUTs and 8 Flip-Flops per slice. I guess that Intel isn't the only company that uses confusion to make money.

The SYZYGY interface is capable of high performance designs worthy of a larger FPGA device with its own external memory resources, say a Kintex 160T. Though the free version of Vivado supports this device I suppose that the lack of platforms available for it must be due to price.