Creating a minimal TCL based Vivado non-project

[lhochstetter]

Hi everyone (probably and mostly Nils and pavel),

it is me once more with another huge post about the inner workings of the FPGA part of the Red Pitaya.

It'll differ somewhat from previous posts as I'll refrain from posting large amounts source code and I won't
be refering solely to the Red Pitaya Github Repo but also to pavel's Github Repo.

---

This time I'm interested in what happens when you run 'make' in 'fpga/' or 'fpga2/'. From what I've gathered
TCL scripts are used to control Vivado i.e. running the synthesis, implementation, and generate the bitstream.

I also know from failed experiments that you need some form of physical constraints definition telling Vivado at which voltage,
slew rate etc. the pins are to be set, otherwise Vivado will complain.

The Red Pitaya team got the definition in system_bd.tcland pavel as a neat .xml file - pavel, why and how did you create the .xml file?

I should add that the system_bd.tcl does also take care of initializing and configuring some IP Cores as well as defining positions for the blocks if you are running 'make project' to start the GUI. The TCL file does also take care of creating a memory mapping for the AXI Interfaces ...

To interact with the user defined pins you will need a constraints file telling Vivado which 'data structure' maps to which physical pin
of the ZYNQ.

The Red Pitaya team created one large .xdc file.

pavel created three different files (ports.tcl, ports.xdc, clocks.xdc) presumably doing the same what the RPT's file does.

Regardless if you're using IP Cores (own or third party) or like the Red Pitaya .v Verilog / .sv SystemVerilog files you have to have something
taking care of initializing / connecting them properly.

As mentioned above the RPT did do so in their system_bd.tcl file.

pavel split the initialization partand the connection part.

Finally you'll run a script taking care of synthesis, implementation, and bitstream generation ... and report creation.

The RPT wrote serveral scripts: the complete synthesis-implementaion-bitstream, creating the GUI project, and three more scripts (dram_test, fsbl, device tree) I don't understand as well as the other two.

pavel wrote several scripts aswell (mostly guessing): bare-metal app, bitstream generation, device tree, fsbl, hardware definition (maybe generating the net list), creating an IP Core and this monster(which is partially explained here)

Now my go to question: Nils, pavel - did I get it right?

Where do I go from here if I want to end up with a TCL based minimal FPGA non-project, ideally with a 'complete' hardware constraints file(s)? To elaborate: I'd like to use it as a test bed to test my HLS IP Cores without having to worry about other IP Cores etc. interfering ...

[pavel]

Now my go to question: Nils, pavel - did I get it right?

Yes, more or less. I'm not sure if I agree with the following:

pavel split the initialization part and the connection part

I wouldn't call axi_sts_register_v1_0/core_config.tcl an initialization part. It's used together with scripts/core.tcl to generate an IP core. The output of this part is the same kind of IP core as produced by the HLS tools or any other tools that generate IP cores.

BTW, scripts/core.tcl could be also extended to generate IP cores using the HLS tools.

Where do I go from here if I want to end up with a TCL based minimal FPGA non-project, ideally with a 'complete' hardware constraints file(s)?

I tried the non-project approach and didn't like it. The only difference between project and non-project is whether project files are saved to the disk or recreated in memory every time you need them. It helps a lot to be able to open a project in the Vivado GUI.

If you want to try my scripts, then copy your packaged cores to tmp/cores and add them to a block design as it's done in led_blinker/block_design.tcl.

[Nils Roos]

And I have my 2 cents to add to these sections:

The Red Pitaya team got the definition in system_bd.tcland pavel as a neat .xml file - pavel, why and how did you create the .xml file?

I should add that the system_bd.tcl does also take care of initializing and configuring some IP Cores as well as defining positions for the blocks if you are running 'make project' to start the GUI. The TCL file does also take care of creating a memory mapping for the AXI Interfaces ...

The content of Pavel's cfg/red_pitaya.xml and the corresponding pieces of system_bd.tcl are the configuration of the ZYNQ IP core. The definition of the physical characteristics of the pins belonging to on-chip peripherals is an important part of it, but there is also lots of other configuration - like which AXI interfaces are active, the operating parameters of the external DDR memory, etc.

To interact with the user defined pins you will need a constraints file telling Vivado which 'data structure' maps to which physical pin
of the ZYNQ.

The Red Pitaya team created one large .xdc file.

pavel created three different files (ports.tcl, ports.xdc, clocks.xdc) presumably doing the same what the RPT's file does.

Pavel's cfg/ports.xdc and cfg/clocks.xdc are basically the red_pitaya.xdc devided into two functional units (1. physical parameters and internal association of the custom defined pins and 2. clock constraints). cfg/ports.tcl is a script that adds all the custom external connections of the Red Pitaya to a given block design.

[...] three more scripts (dram_test, fsbl, device tree) I don't understand as well as the other two. [...]
device tree, fsbl, hardware definition (maybe generating the net list), creating an IP Core and this monster(which is partially explained here)

dram_test is an alternate (but broken - forget about it) version of the fsbl. fsbl is the first stage bootloader, the first piece of user supplied code that is executed by the ARMs. It is assembled by Vivado to fit the configured options of the ZYNQ and load all other software. The devicetree is likewise generated by Vivado to make Linux aware of the configured options of the ZYNQ.

Pavel's 'monster' is the tcl code that instantiates and connects all of his cores and optional Verilog / SystemVerilog modules together into one block design.

[lhochstetter]

Thanks you two for answering so quick.

If I take the things you mentioned in consideration I end up with the following aspects:

1. hardware definition (physical) / constraints (logical) (one time unless I rename something)

2. instantiation, configuration, and connection of IP Cores (per bitstream / project)

3. running the required steps (synth, impl, gen) to generate a bitstream (per bitstream / project if I need different settings)

About the non-project part: sounds reasonable ... it definitely offers another perspective for debuging