11-20-2019 08:05 AM - edited 11-20-2019 08:07 AM
I am using Vivado 2019.1.
In my project I am drowning in the jungle of wires.
My questions are:
1) Block Design.. Since inputs enter the rectangles on the left side and outputs exit on the right, connecting two boxes with each other via signals of opposite directions makes it chaotic compared to a common-sense drawing on a piece of paper. Is there a solution to this? In other words I wish Block Design could handle SystemVerilog interfaces just like it can recognize AXI signals. Anything close?
2) How to connect an IP-core via AXI with a custom RTL module that uses an AXI (SystemVerilog) interface? Sure you can pull up a wrapper around the SV module, but then the essence of SV interfaces is lost. Way too many signals, especiall if you have many AXI interfaces on one module.
3) Is there a way to include an AXI/Lite/Stream group of signals in the RTL module - automatically? Or in a SV interface? Or maybe a predefinied AXI interface type in SV?
This is just plain crazy how much time is spent on typing these AXI signals. :((
Thank you very much.
11-22-2019 06:15 AM
Hi - I feel your pain ;) I'm not a SystemVerilog expert but I can tell you how I deal with this in VHDL to limit the amount of wasted time on interconnect:
1. For internal levels of hierarchy (e.g. modules not in block design view) we use records for the AXI4 and other protocols. That way you have only two connections to each module to connect the entire AXI4 protocol. Then we use arrays of these records for the N:x slave interconnects to keep it tidy.
2. This doesnt work in block design as the Xact IP standard/Xilinx Block Design doesnt support records for interconnect unfortunately. So if its top level interconnect the next best thing you can do is make sure Block Design correctly infers an interface from your signals. See UG994 (Designing IP Subsystems using IP Integrator) chapter 13. If you use a naming convention, and add attributes to your code you can infer the interfaces (such as AXI4, AXIS etc).
3. The actual interface definition files are located in :$XILINX/Vivado/<version>/data/ip/.... various locations.
- on Linux if you search: find /<Path to your Xilinx Instal> -name '*_rtl.xml' | grep -i axi
- you'll find all the AXI specific ones.
4. Lastly if you find yourself creating a lot of wrappers or typing something over and over that is not complicated, but tedious work - then generally its likely to be error prone and a waste of your time. So in those situations I recommend writting a script (python, perl, etc) or program (C++ etc) to automate the process. E.g. if I had 10's of modules with AXI records for interfaces and needed to migrate them to block design, I'd write a script to parse the entities and automatically generate wrapper files that output signals compatible with block design. You can even generate the TCL connectivity commands this way too. Just a thought.
11-22-2019 10:30 AM - edited 11-22-2019 10:33 AM
I've also been frustrated with block design's lack of support for generating SV code using interfaces. Afterall, the block design graphically uses interfaces, but the generated code is still plain old-school Verilog. I don't see why Xilinx has not yet updated to SV for the Block Designer.
I'm an SV developer and a big fan of SV, and have defined my own separate parameterized interface files for AXIS, AXIL and AXI. I then create SV wrapper files for any code generated by the block designer and utilize my defined interfaces to provide connections to the jumbles of wires needed to connect to instance of the generated block design. Unfortunately, until Xilinx starts supporting SV for Block Designer, I don't see a way around the need for generating your own SV wrapper file for each Block Design.
06-23-2020 03:34 PM
Thank you, egrigor. I couldn't agree more.
Not sure how Xilinx allocates its engineering resources but things like this (supporting SV with Block Design) should have much higher precedence than those such as HLS or the array of DNN frameworks that help neither HW architects nor SW programmers.
Please, Xilinx, make FPGA design easier and less error prone. People who design for FPGA want to play with hardware architecture. Make that easy for them. If I didn't care about hardware architecture, I'd go for nVivida, Intel, ARM, AMD, you name it. Not Xilinx.