Moving From Ultra96v1 to Ultra96v2

Quickly adding to my previous message, I have since manually changed the DDR configuration to match the Ultra96v2 board, rebuilt, and was able to generate a BOOT.BIN that boots the system. While that's great, I don't have a lot of confidence in the system. Again, if the DDR configuration wasn't upgraded to the Ultra96v2 board, what else might be wrong?

Did you update your board definition file to use the Ultra96-V2?

Besides the LPDDR4, there are no other differences at the FSBL level. Once you get to Linux, then the Wi-Fi / Bluetooth drivers change. A detailed description of the differences is listed here:

Introducing Ultra96-V2

Bryan

I updated the "Project Device" by going to Tools|Settings|General|Project device and choosing the Ultra96v2. If there is another way to upgrade a design from Ultra96v1 to Ultra96v2, I don't know it.

There were three blocks that were "locked" in the design. None of those blocks were the Zynq, but is it possible that if you have any blocks locked, then the DDR configuration parameters wouldn't be updated?

I think changing the Project Device does not update the Block Design that is already generated. You would have to manually go do that. Updating an existing design from one board to a different board or from one device to a different device isn't a simple process. If it affects things at the FSBL/hardware level, then you have to regenerate and rebuild your sources anyway. That's one reason why we advocate using scripted flows as described in the blog below, which essentially starts you with a clean slate that is easily repeatable.

Avnet HDL git HOWTO (Vivado 2020.1 and earlier)

Bryan

bhfletcher, what scripted flow are you referring to exactly?  I had the same problem as the OP, John and after reading your post, I was under the impression that using a scripted flow would fix the issue.  However, after much wrangling, it did not.  Maybe I wasn't using a scripted flow properly.  The fix was to update the DDR configuration as John mentioned and explained in your post LPDDR4 Memory differences between Ultra96-V1 and Ultra96-V2 (linked from Introducing Ultra96-V2).

Regarding the scripted flow, I tried following Avnet HDL git HOWTO.  It refers to make_ultra96_oob.tcl, which I could not find in https://github.com/Avnet/hdl/tree/master/Scripts.  So I tried using my project script instead, but found that does not capture the pin constraints and did not fix the issue.  It also contains the same DDR configuration from before for the Ultra96-V1, so the problem would remain.  After attempting to try a scripted flow, my understanding is that the issue is the DDR configuration and it does not matter whether it gets fixed in the script or in the block design directly.  There is nothing in the project script that automates the DDR configuration based on the board design file, rather it reproduces the design exactly as before.

Hi all,

I think there is confusion about the blog.

Bryan was referring to our recommended flow, which is mentioned in the blog and a host of other design documentation.  Compared to the article, and what you posted, there appears to be two issues you have.  First, you are missing a v2 in the name.

make_ultra96v2_oob.tcl not make_ultra96_oob.tcl

Second, you need to move to the proper branch.  In the case of the article, 2019.1.  Or whatever branch / tag you want to be on.

you can see this line listed in the HDL checkout section of the article:  git checkout 2019.1

There are a host of tags you could leverage - depending on the design / prebuilt image you are working with.

Once I switched to the 2019.1 branch, you can see the build script is there:

Here is a direct link to the Webpage if you would like to explore:

https://github.com/Avnet/hdl/tree/2019.1/Scripts

Specific to the DDR issue, I'm not sure about your project script, but you have two main ways to configure things.  You can use a script or a BDF.  We have examples of both, however, the BDF is the preferred and recommended way at this time.  This is why the 1 line below will reconfigure your entire project to the new settings.

https://github.com/Avnet/hdl/blob/2019.1/Scripts/ProjectScripts/ultra96v2_oob.tcl#L87

For the vast majority of designs, that is really all you need to port from system to system - especially if they are similar systems.  Sometimes the memory mappings might get mucked up, but I'd say that almost NEVER happens with common memory.  I've personally only seen that happen when using exotic memory (UltraRAM or VCU buffers).  Porting from an Ultra96v1 to an Ultra96V2 design has not failed for me in the handful of times I did it - and it was really just changing that one line.  The other method, if you dig into the scripting flow we have for the Ultra96V2, line 79

https://github.com/Avnet/hdl/blob/2019.1/Scripts/ProjectScripts/ultra96v2_oob.tcl#L79

You will see a call to a board preset tcl.  In this case, it doesn't really do anything, as the BDF does all the work.  However, that script:

https://github.com/Avnet/hdl/blob/2019.1/Boards/ULTRA96V2/ultra96v2_oob.tcl

CAN setup memory and other settings.  For example, check out the PicoZed7010 TCL:

https://github.com/Avnet/hdl/blob/2019.1/Boards/PZ7010_FMC2/PZ7010_FMC2.tcl

Start about line 135.  All of that is essentially what the BDF does.

Now for the rest of the question, first, let me start out by saying the tools are 100's even 1000's of times better than they were and the below is just observation about the behavior.  That is in fact one of my jobs.  I go through designs and build things up and work out what should be the best way to create reproducible and reliable results.  MOST of that time, it is just following directions from the suppliers.  Sometimes, due to the exact way we are using it, there is a different way.

I can say from experience, you should NOT update any design using:
"Project Device" by going to Tools|Settings|General|Project device and choosing the Ultra96v2.

There are a LOT of dependent things that are built on top of each other to produce a design and in the case of what this allows - especially with a LOT of stuff on the design, you will sometimes have to manually rebuild in order to trigger Vivado to RECREATE those pieces.  I would agree that you should be weary of this design.

Generally, the tool sees pieces already built and won't rebuild unless forced.  As that list of things and the permutations involved in that list are near infinite depending on what you put together for a design, we have been promoting a scripted build for a LONG time.  It also helps in porting between versions as TYPICALLY when the tool breaks, it will tell you EXACTLY where it did, and you can easily correct it.  For example, 2018.3 --> 2019.1, you might inherit a new fifo.  So the version number might need to be updated.  This is fantastic as it not only SHOWS you exactly where to look, but also makes a human inspect the element to make certain that it is still meeting your needs.

If you are using a script, in order to update to a new board - RELIABLY, as long as you are leveraging a BDF, really there is only 1 line to update in the make script as mentioned above.  Then allow the REST of the design to mold itself around that preset

Look for this:
set_property board_part em.avnet.com:ultra96v2:part0:1.0 [current_project]

Somewhere you will see that in your script (be it a custom script or a write_bd_tcl command).  If you do not see that, you are most likely using a specific part.  At that point it is really on you to redesign the whole thing (see the PicoZed script above).  It is a challenge and we find most customers do NOT want to deal with that, so we do - however you have to use the mechanisms that we put in place to use them.  This entire thing is of COURSE made easier the more similar the targets are.  Going Zynq to Zynq MPSoC is more challenging.  And actually one of the arguments for SDSoC  / Vitis.  All of this is extrapolated away - and even going Zynq to MPSoC to Versal, is nothing more than a few mouse clicks.  You target the solution space to a new platform and Vitis/SDSoC will force re-do everything it needs in order to properly generate the solution with the targeted performance metrics you provide.

--

All that said, I'm not sure what constraints you are missing from the project script, but Vivado does not forget about stuff.  If you are including an XDC, it should be included in the script.  The only time I've seen issues, is if you did not internalize the XDC.  Then it is part of the GUI design, not the project output itself - hard to explain in just a forum setting.  I know, it is confusing, but you will want to ensure you have imported the files:

import_files

Prior to running that you will also want to update the compile order

update_compile_order -fileset sources_1

That command forces all the project files to be copied in - vs always just assuming they are there.  This is especially important for working with DSA/XSA files.

So lastly, your comment about the script not automating the memory - you are right, it is generally done by applying board automation, which then refers to the BDF, which as I pointed out, if you change the BDF, a different set of values / configurations will get applied.

--Dan

Dan, thanks for the very detailed post!  It has been a wealth of information for me!

I was looking for make_ultra96v2_oob.tcl, but mistyped it in my post; thanks for pointing that out.  Also, thanks for pointing out where to find it, though I would have also expected it to be in the master branch since normally I expect the master branch to have the latest code, but that does not seem to be the case here.

Regarding the script, I completely understand the power of being able to automate the block design based on the BDF, but had problems reducing it to practice.  I think understand my mistake now.  I was trying to generate the desired script via the GUI by running File > Project > Write Project to Tcl with Copy sources to new project and Recreate Block Designs using Tcl.  However, Write Project to Tcl runs write_project_tcl, which includes DDR and other configuration, instead of write_bd_tcl, which I believe does not contain DDR and other configuration and would automate such configuration using the BDF.  I'll have to try this out.

For the constraints, if I understand you correctly about it being "part of the GUI design", I think you mean creating the constraint in the GUI (in Flow Navigator > RTL ANALYSIS > Open Elaborated Design) which saves the constraint in <project_path>/<project_name>.srcs/constrs_1/new/<project_name>.xdc.  In which case, I tried running import_files, then Write Project to Tcl, but I still don't see pin constraints or a reference to the XDC file in the tcl script or other project files.