fred-framework / dart Goto Github PK

Currently DART uses standard Xilinx busses to interconnect the reconfigurable regions. bus manager should be supported by DART, providing a more complete system composability and better control of system timing requirements.

Zynq-7000 devices are 32 bits, therefore, C_M_AXI_MEM_BUS_ADDR_WIDTH = 32.
However, for Ultrascale devices, C_M_AXI_MEM_BUS_ADDR_WIDTH could be 64 bits
if the IPs are synthesized with config_interface -m_axi_addr64

At this moment, even for Ultrascale devices, DART uses C_M_AXI_MEM_BUS_ADDR_WIDTH is fixed to 32 bits. Thus, when using a dart-generated design, make sure that FRED server is compiled without the define HW_TASKS_A64, to make it compatible with 32 bits.

This part of the code could easily be executed in parallel, reducing DART runtime when using several IPs.

This is a configuration matrix for the test/minimal:

N.I.: not implemented.

Tests on the board are still not implemented.

DART exists in error when running with partitioning mode in both ON or OFF, and targeting Zynq:

source /home/aamory/repos/dart/dart/tests/minimal/build_ON_zynq/static.tcl -notrace
WARNING: [Project 1-153] The current project device 'xc7z010clg400-1' does not match with the device on the 'WWW.DIGILENTINC.COM:PYNQ-Z1:PART0:1.0' board part. A device change to match the device on 'WWW.DIGILENTINC.COM:PYNQ-Z1:PART0:1.0' board part is being done. Please upgrade the IP in the project via the upgrade_ip command or by selecting Reports => Reports IP Status.
INFO: [Project 1-152] Project part set to zynq (xc7z020clg400-1)
INFO: [IP_Flow 19-234] Refreshing IP repositories
INFO: [IP_Flow 19-1700] Loaded user IP repository '/home/aamory/repos/dart/dart/tests/minimal/build_ON_zynq/Sources/ip_repo'.
INFO: [IP_Flow 19-2313] Loaded Vivado IP repository '/storage/Xilinx/Vivado/2020.2/data/ip'.
Wrote : </home/aamory/repos/dart/dart/tests/minimal/build_ON_zynq/static_hw/dart_project.srcs/sources_1/bd/dart/dart.bd>
CRITICAL WARNING: [filemgmt 20-730] Could not find a top module in the fileset sources_1.
Resolution: With the gui up, review the source files in the Sources window. Use Add Sources to add any needed sources. If the files are disabled, enable them. You can also select the file and choose Set Used In from the pop-up menu. Review if they are being used at the proper points of the flow.
ERROR: [BD 41-758] The following clock pins are not connected to a valid clock source:
/processing_system7_0/M_AXI_GP0_ACLK
/acc_0/ap_clk
/pr_decoupler_0/aclk
/axi_interconnect_0/ACLK
/axi_interconnect_0/S00_ACLK
/axi_interconnect_0/M00_ACLK
/axi_interconnect_0/M01_ACLK
/axi_interconnect_1/ACLK
/axi_interconnect_1/S00_ACLK
/axi_interconnect_1/M00_ACLK

Seems to be some inconsistency in the IP interface with the static part.

Currently DART uses a hard-coded devicetree generation. Here are some references about a better approach to generate the devicetree for dart designs:

• https://support.xilinx.com/s/article/1157624?language=en_US
• https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842279/Build+Device+Tree+Blob
• hsi::create_dt_tree
• Customizing/Extending DTG for Custom Hardware and Drivers
• https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841693/HSI+debugging+and+optimization+techniques
• https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/341082130/Quick+guide+to+Debugging+Device+Tree+Generator+Issues
• https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841722/ZCU102+Image+creation+in+OSL+flow see section Build device-tree
• https://xilinx.github.io/Embedded-Design-Tutorials/docs/2021.1/build/html/docs/Introduction/ZynqMPSoC-EDT/8-boot-and-configuration.html

Instead of manually checking the YAML format like it is done here, DART could use a YAML schema validator, like this one.

For example, when using an input file like this, with 2 RRs and one IP per RR,

dart:
    partitions: 
      - hw_ips:
        - ip_name: "sum_vec"
          top_name: "sum_vec_top"
          timeout: 1000
          buffers: [32768, 32768, 32768]
      - hw_ips:
        - ip_name: "sub_vec"
          top_name: "sub_vec_top"
          timeout: 1000
          buffers: [32768, 32768, 32769]

It generates an error at the physical synthesis because one of the RR has BRAMs at the right hand side border, which is not allowed.
This error happens with any configuration with more than 1 RR.

When the YAML file has the debug key word, it adds ILA in the reconfigurable region. But it works only for the Pynq board.
Add ILA support for the other boards.

Most errors when using dart is related to interfaces mismatches from the IPs. This produces valid vivado designs that actually dont work when running in the board. This leads to long debugging sections. The idea is to implement some IP interface checking before the IP synthesis phase of dart, to catch the error ASAP.

FRED runtime supports multiple slots per partitions. However, DART doesnt.
Multiple slots per partition would give to a certain IP multiple reconfigurable regions to be used in runtime.
It means that the FRED scheduler could choose where (i.e. which reconfigurable region) to deploy a certain IP.

Note that, in pr_tool::generate_fred_files, in the part that writes the arch.csv file, the slot information is fixed to 1 since dart only supports 1 slot per partition..

• PG037 AXI Performance Monitor v5.0
• https://xilinx.github.io/Embedded-Design-Tutorials/master/docs/SPA-UG/README.html
• https://xilinx.github.io/Embedded-Design-Tutorials/master/docs/SPA-UG/docs/3-monitor-framework.html
• In design phase, this would allow the designed to quickly check the timing of the design produced by dart
• In runtime, there could be a kind of system supervisor that monitors the timing and emit alerts in case of any violation.

ILA are inserted only in the partitioning OFF mode.

DART currently has 2 modes and support 4 boards. For each cross-configuration, it would be required to run multiple tests.
The idea is to provide some minimal automated testing environment, like a CI.

DART has 4 main steps: ip synthesis, static part synthesis, floorplan optimization, implementation. It would be beneficial to support a user defined static part, since this part typically depends on the interfaces used in a design. For instance, a video processing application would have a camera interface to receive the input frames. Currently DART only implements a basic static part, setting up only the reconfigurable regions. The idea would be the user to define a static part DCP file. In this case DART would skipping its 2nd step and continue executing its remaining steps.

The compile-time configurations:

• PARTITIONING_MODE=ON and FPGA=zcu_102;
• PARTITIONING_MODE=ON and FPGA=us_96.

are not implemented yet.