News:

Attention: For security reasons,please choose a user name *different* from your login name.
Also make sure to choose a secure password and change it regularly.

Main Menu

Best practice / migration path / porting receipe for updated reference design

Started by masc, August 10, 2021, 04:52:59 PM

Previous topic - Next topic

masc

Hello!

We have a working TE0720 design based upon 2018.3 reference design https://shop.trenz-electronic.de/de/Download/?path=Trenz_Electronic/Modules_and_Module_Carriers/4x5/TE0720/Reference_Design/2018.3/test_board.
The day has come where we want to use new Vivado versions and also the new reference designs. E.g. 2020.2 https://shop.trenz-electronic.de/de/Download/?path=Trenz_Electronic/Modules_and_Module_Carriers/4x5/TE0720/Reference_Design/2020.2/test_board.

Question: Since it is quite a complex design, what would be the best practice to port the design based upon old reference design into a new reference design?
(In case I've overlooked a wiki page, please excuse and point me there..)

Thank you in advance!

Bye, Marc.

neels

I did porting of a custom design (based on reference design of TE0720 board) from 2016.2 to 2020.2, below are some observations:

HW
In terms of porting the hardware, it was relatively simple.
Just make sure when you upgrade to 2020.2, the IPs might have a newer version. Check the revision history of the IP and make sure it is compatible with the design.
The system.bd file format has changed from xml to json, so if you have scripts extracting info, you might need to update regex accordingly.

SW
There was a lot of changes while porting the software/petalinux from 2016.2 to 2020.2 because xilinx have aligned more towards Yocto builds
Understand the folder structure of the project as a starting point and see how it all fits.
Experiment changing some kernel and rootfs config and track through where your changes are made. They are generally made in the yocto workspace, you need to use the devtool to pull the changes into your user area.
You need to familiarize with cloning xilinx repo, making changes (to kernel, fsbl), generating patch files and adding the patch files as recipes. You can find them all around the web.

I have found that the petalinux kickstart tutorial from Trenz  gives good info to get you started. Try seeing how it is different between the version of interest. I expect the port from 2018 to 2020 should be ok compared to mine.

Some useful links
https://www.xilinx.com/support/documentation/sw_manuals/xilinx2020_2/ug1144-petalinux-tools-reference-guide.pdf
https://wiki.trenz-electronic.de/display/PD/PetaLinux+KICKstart

HTH,
Neels




masc

Hi Neels!

Thanks for the info, @neels.
Could you add some details on how you merge into the new reference design?
I like the Trenz scripts and created the project via vivado_create_project_guimode and open a project with vivado_open_existing_project_guimode.
But these scripts check the Vivado version... What is the right order to do what?

Thanks again!
Bye, Marc.

neels

Hi Marc,

Unfortunately, I wasn't heavily reliant on the custom scripts provided by Trenz to run the vivado tools and port the design.
I basically had a look at their scripts to see how the project is configured and see how to pull the right files to build the project.
Trenz provides you a top level tcl file that generates the block level design for the reference projects. This file is should be pretty
easy to port across platforms if you remove the trenz specific stuff from the tcl file.

But going back to your original question, why do you want to port the reference design, when it is already done by Trenz in the links that you provided ? What is your objective, do you have your own project that you wish to port ?

Thanks,
Neels

masc

Hi!

I ended up in a handcrafted migration (source is the current (old) project folder, destination folder is the new te reference design):
- create a reference design with right target device with te scripts, close design.
- copy block design tcl file
- copy all HDL, xdc, etc files
- copy all IPs
- copy own scripts
- use git log / diff to identify all occurrences of modification in te scripts and port them into new scripts. (This is the most comprehensive part)
- open project with te script again.

During first opening I had some problems with HLS generated IPs. I cannot reconstruct if this was my fault or a general problem but it was solved by copy (again) generated HDL code.

The generated bitstream works as expected.

HTH.

Bye Marc.

JH

Hi,
you can find some general note of our scripts and design delivery here:
https://wiki.trenz-electronic.de/display/PD/Project+Delivery+-+Xilinx+devices

Scripts will be tested only for the given Vivado version (sometimes  Xilinx changed functions and process flow, so it can happens that no all will work if you use older scripts on newer vivado version). Mostly it will be stable for some Vivado versions.
Block Design is exported as tcl (this is a functionality from Vivado itself), is IP Version included. For older design, it's possible to change the block design TCL directly or you create the project one time with the scripts and the older vivado version. And open(only open) it again with newer Vivado Version(change version on design_basic_settings.cmd), start IP update and save new bd file with "TE::hw_blockdesign_export_tcl" --> note this will be exported bd design with all information and in this case it's only for given version (bd tcl is not modified to get assembly variant specific information from board files), for more details see: https://wiki.trenz-electronic.de/display/PD/Project+Delivery+-+Xilinx+devices#ProjectDeliveryXilinxdevices-TE-TCL-Extentions

On 20.2 design,  I've removed the version control  of every IP from exported tcl files.  Simple change version in "design_basic_settings.cmd" and open the design with "_create_win_setup.cmd" and start the selection guide. It will try to generate the design also with other vivado version(you must agree only one time that you know that creation can failed in this case).


Wenn you try to use newer script version on older projects(replace script files of your older projects with newer one), than you must check also version of some additional CSV files, which I use for specific configuration:
https://wiki.trenz-electronic.de/display/PD/Project+Delivery+-+Xilinx+devices#ProjectDeliveryXilinxdevices-LastsupportedRelease
--> if it differs, that you must also update style of the csv

PS: Xilinx has done break with the software flow from 18.x to 19.x an newer. SDK script part has completely changed and is not compatible for older designs.

For your HSL generated IP problem, did you put the IP into the ./ip_lib folder? This folder will be load as local IP repository automatically.

br
John

masc

Hello John,

thanx for the reply.

Quote from: JH on September 14, 2021, 11:22:52 AM
For your HSL generated IP problem, did you put the IP into the ./ip_lib folder? This folder will be load as local IP repository automatically.

Yes, i did. After copying hdl files again into e.g. .\ip_lib\some_hls_ip\solution1\impl\verilog it worked well.

Quote from: JH on September 14, 2021, 11:22:52 AM
PS: Xilinx has done break with the software flow from 18.x to 19.x an newer. SDK script part has completely changed and is not compatible for older designs.
Can you elaborate? Anything i should have an eye on?

Bye, Marc.

JH

Hi,
QuoteYes, i did. After copying hdl files again into e.g. .\ip_lib\some_hls_ip\solution1\impl\verilog it worked well.
check the source file of the generated IP --> I think there are some absolute path in some of the xml files if this IP.

QuoteCan you elaborate? Anything i should have an eye on?
Completely SW generation procedure has changed and also some smaller parts in vivado.
I would recommend to download one of our 2020.2 design, for example this one from TE0720.
replace exported  block design tcl file (block_design folder), constrains (constraints folder), ip libs(ip_lib folder) and (if you use other board also board files an the board file csv (board_files folder)) with this one from your design and try to generate the project.
for software part,  you must check "sw_lib" software template and the corresponding csv file (style has completly changed, so you can't replace with older one, there are some notes included). In case you has Zynq, you must also generate own template version with xilinx 2020.2 fsbl sources and our changes.

br
John


masc

OK, thank you.
I think this was the recipe I was looking for in the first place.