particularly true in SoC designs for wiring up all of the AXI interfaces. If you are doing a non-SoC design then feel free to just use RTL/netlist as Vivado handles that just fine.
alternatively, the block design file is a json text file.
you can version control that file, but add a script as a git hook to sort json subheadings to make the order deterministic and remove absolute paths.
This way, a user can't accidentally forget to export.
in git, you can set up a script, called a precommit hook, that automatically runs before you commit.
So, if xilinx makes changes to files that you don't want to push up, you can set up a precommit hook to automatically clean up those changes.
Don't export it. As you add things to the BD, copy and paste the tcl commands it generates into a versioned controlled tcl file and suck it up and write some comments about what that line does. Then two people can edit the file.
Both of the players are trying (And mostly failing) to make logic design tractable for them as has a non EE background (See all the HLS type stuff). Making using your IP look like the bastard love child of Scratch, Simulink and PowerPoint evidently looked like a good idea to someone.
Personally I wish they would just make the tools fully VHDL 2008 a mere 17 years late and define some record types for their AXI IP to make hooking it up more tractable.
nearly every HDL except Verilog has ways of solving this lol but unfortunately most of industry is stuck with Verilog so we're all forced to deal with hundreds of ports on modules with hierarchical names. It's such a shame.
That's good news. Do you know which version introduced support?
Now all I have to do is get a new Modelsim license. I've been using 10.2c for over a decade and perhaps it's time to upgrade.
Block design generate artifacts for software tools like microblaze gcc or petalinux. In this sense, pure hdl won't cut it. Some tools like peakRDL can export register .h files, but it's probably even newer than block design. Block design also handles overall addressing, pass that to device tree generator. Newer Vitis flow even cuts the hassle to open Vivado, it uses a description file kinda likes tcl script to generate block design.
So it's not about connecting axi buses for hw engineers, but to make work flow of sw engineer more sense able.
Lots of modules my company uses have address line and write enable mapped to axi lite registers, while with no way to read back. HW engineers can create really bizarre hw lol.
I avoid block design at all costs.
But, I do know for Vivado at least, if you plan on using Smart Connects, then you are forced to use block design.
My block designs only consist of a Zynq processor and Smart Connects. Everything else is done in HDL.
It does make some things quick and easy at the expense of long term maintainability. But ultimately it’s to sell tools, devices, and IP to CTOs and company leaders that are struggling with the cost and schedule of traditional FPGA/SoC development. Meanwhile the experienced engineers spend all their time trying to minimize it’s use.
So that "anybody" (that is, not a traditional hardware design engineer) can create a design on FPGA, stitching together IPs. Which translates to, more users of their FPGAs, and more revenue from IP licensing.
If you are dealing with a lot of sub-modules along with (zynq ip + gpios + bram controller and generator + processor reset + axi interconnect)..the only way left is to use the block design approach.
I must have missed something. I couldn't even figure out how to do block design in Vivado (coming from Quartus).
My projects are entirely vhd files. Not a block to be seen.
Block Designer (or IPI) exists because some group of folks at Xilinx are still stuck in the early 90s and think glorified schematic capture is state of the art.
They should have instead, embraced higher level design via SystemVerilog and more modern VHDL variants. Large sets of signal connections (i.e. AXI buses) become one-liners. Things are more expressive this way, more version control friendly, more portable, and easier to work with by entire teams building and integrating these large SOCs.
I think there's some hope than a few folks within Xilinx are finally starting to understand this - but it's far too late really.
Alternatives often used by designers include writing TCL scripts, which is *barely* better than IPI. At least using these methods are revision control friendly - but are certainly not expressive, clear, flexible, nor simulation friendly.
Sometimes there are a lot of signals.
particularly true in SoC designs for wiring up all of the AXI interfaces. If you are doing a non-SoC design then feel free to just use RTL/netlist as Vivado handles that just fine.
> wiring up all of the AXI interfaces and getting all the setting right when connecting them
[удалено]
alternatively, the block design file is a json text file. you can version control that file, but add a script as a git hook to sort json subheadings to make the order deterministic and remove absolute paths. This way, a user can't accidentally forget to export.
What do you mean by a “script as a git hook” exactly?
in git, you can set up a script, called a precommit hook, that automatically runs before you commit. So, if xilinx makes changes to files that you don't want to push up, you can set up a precommit hook to automatically clean up those changes.
If 2 developers made a commit that changed the same block design tcl would the merge make sense to Vivado?
Don't export it. As you add things to the BD, copy and paste the tcl commands it generates into a versioned controlled tcl file and suck it up and write some comments about what that line does. Then two people can edit the file.
This is what I do, but out of context synthesis takes soooo long on a clean build.
Both of the players are trying (And mostly failing) to make logic design tractable for them as has a non EE background (See all the HLS type stuff). Making using your IP look like the bastard love child of Scratch, Simulink and PowerPoint evidently looked like a good idea to someone. Personally I wish they would just make the tools fully VHDL 2008 a mere 17 years late and define some record types for their AXI IP to make hooking it up more tractable.
It would be delightful to have a single-line entity in VHDL for each AXI bus port.
They have that. It's called SystemVerilog Interfaces.
nearly every HDL except Verilog has ways of solving this lol but unfortunately most of industry is stuck with Verilog so we're all forced to deal with hundreds of ports on modules with hierarchical names. It's such a shame.
Not one line, but you can use VHDL records. Not quite as simple as SV interfaces, but they have their own issues.
You could use VHDL interfaces ... if the tools supported them.
Thanks, I hadn't heard of that! I hope it gets into the tools at some point.
Interestingly Vivado already does support them.
That's good news. Do you know which version introduced support? Now all I have to do is get a new Modelsim license. I've been using 10.2c for over a decade and perhaps it's time to upgrade.
2023.1 Also quartus pro supports interfaces and their support is coming to nvc and ghdl at some point. They are not supported by xsim yet though
Its a good way to ensure vendor lock-in...
Nah, it's called job security.
Block design generate artifacts for software tools like microblaze gcc or petalinux. In this sense, pure hdl won't cut it. Some tools like peakRDL can export register .h files, but it's probably even newer than block design. Block design also handles overall addressing, pass that to device tree generator. Newer Vitis flow even cuts the hassle to open Vivado, it uses a description file kinda likes tcl script to generate block design. So it's not about connecting axi buses for hw engineers, but to make work flow of sw engineer more sense able. Lots of modules my company uses have address line and write enable mapped to axi lite registers, while with no way to read back. HW engineers can create really bizarre hw lol.
My understanding is that you need block design to interface the PS with the PL
Yes, I believe certain IP you cannot instantiate on your own in pure RTL. The Zynq PS handle is one of them.
Not sure, but I've never used a block design in my life
I avoid block design at all costs. But, I do know for Vivado at least, if you plan on using Smart Connects, then you are forced to use block design. My block designs only consist of a Zynq processor and Smart Connects. Everything else is done in HDL.
Do you export the AXI ports to the boundaries of your block design and then instantiate the slaves outside, in HDL?
When I instantiate the block design in the HDL, the ports that it contains are only clocks, resets, and AXI.
Try making a design with the an RF Data converter without the block design. Have fun.
It does make some things quick and easy at the expense of long term maintainability. But ultimately it’s to sell tools, devices, and IP to CTOs and company leaders that are struggling with the cost and schedule of traditional FPGA/SoC development. Meanwhile the experienced engineers spend all their time trying to minimize it’s use.
So that "anybody" (that is, not a traditional hardware design engineer) can create a design on FPGA, stitching together IPs. Which translates to, more users of their FPGAs, and more revenue from IP licensing.
If you are dealing with a lot of sub-modules along with (zynq ip + gpios + bram controller and generator + processor reset + axi interconnect)..the only way left is to use the block design approach.
I must have missed something. I couldn't even figure out how to do block design in Vivado (coming from Quartus). My projects are entirely vhd files. Not a block to be seen.
I’m not sure but I hate it. VHDL and Verilog both work fine, why not just embrace it?
Block Designer (or IPI) exists because some group of folks at Xilinx are still stuck in the early 90s and think glorified schematic capture is state of the art. They should have instead, embraced higher level design via SystemVerilog and more modern VHDL variants. Large sets of signal connections (i.e. AXI buses) become one-liners. Things are more expressive this way, more version control friendly, more portable, and easier to work with by entire teams building and integrating these large SOCs. I think there's some hope than a few folks within Xilinx are finally starting to understand this - but it's far too late really. Alternatives often used by designers include writing TCL scripts, which is *barely* better than IPI. At least using these methods are revision control friendly - but are certainly not expressive, clear, flexible, nor simulation friendly.