Understanding the 'Donut Hole'
Beauxrel opened this issue · comments
The FMCOMMS User guide claims "All the Analog Devices Vivado HDL reference designs have inside a ‘donut hole’ to accommodate custom IPs."
My team wants to know if we would be okay just using Vitis Model Composer to design our Mod/Demod chain and have the reference design pass data through axi to that or using HDL-Coder + all the other packages that are required (Very expensive route).
Sell me on these IPs that I can connect to the reference design, would I be able to create a QAM-16 Demod in verilog that the reference design will send IQ data to and use that somewhere else in my system?
Here a basic view of the FPGA datapath with some recommended location of custom IP: https://analogdevicesinc.github.io/TransceiverToolbox/master/hdlrefdesigns/fmcomms2/#reference-design
The signaling is simply data and valid.
If you want to see the design just clone the HDL repo and build the base design: https://wiki.analog.com/resources/fpga/docs/build
Reopen if you have further questions
I think I came to a conclusion.
Both:
- Can produce RF Chains
- Can convert RF Chain to HDL
HDL-Coder - Can Produce HDL that easily Interfaces with FMCOMMS
Vitis - Can Produce HDL that works as simulation on the FPGA that works better on Xilinx FPGAs.
What I need is the interfacing ability so the HDL-Coder would be a better route for me.
@tfcollins Would I be able to access data lines without the HDL coder?
Can you provide more context to your question? In general, you have the entire reference design open to you, which makes your question rather confusing to me.
-Travis
@tfcollins The workflow advisor has you choosing a reference design to build your ip into/for (this bit confuses me). My board is not in the dropdown [FMCOMMS3/VCU108]. Is the generated Hdl the whole reference design again. or Am I just getting the IP core? If it is just the ip-core, can i just drop this ip core into my vcu108 reference design?
For reference
The IP Core Generation workflow with HDL Coder works by generating an IP core from a Simulink subsystem, which is then stitched into an existing reference design. It doesn't create an arbitrary design for an arbitrary carrier for a specific FMC card.
For your design, you would either need generate the core out separate and use Xilinx's IP Integrator or build out a custom reference design target with the IP Core Generation flow.
I think im understanding better, Im trying to generate an ip core from the transmitter below. I will still have the I/O. my concern was functionality of just generating the hdl vs using the workflow advisor
The FMCOMMS3 user guide hints at need to use the workflow advisor, that's why I was stuck on thinking I needed to use that.
But I do have a working reference design already for the vcu108. How can I build out a custom reference design target? @tfcollins
See details here: https://www.mathworks.com/help/hdlcoder/create-a-custom-hardware-platform.html?s_tid=CRUX_lftnav
The Toolbox itself follows this process just with a bit more complexity since we support so many platforms.
Thank you, I will run this down and post my results.
@tfcollins Im having trouble finding the Analog Devices references designs (Im going to base mine off of these). I tried just to import the VCU108 design that works with the FMComms3. But I don't think I have the 'Donut Hole' in my design.
C:\ProgramData\MATLAB\SupportPackages\R2022a\toolbox\hdlcoder\supportpackages\zynq7000
Is where i was putting my reference design, but the ports are not exposed.
The path that MATLAB uses for those Analog Devices reference designs is what I am looking for.
There are two specific HDL targeting options for FMComms3
- Transceiver Toolbox: This is authored by ADI. Source HDL is in the (toolbox install root)/hdl/vivado folder. The toolbox will invoke block design construction through the TCL flow documented here: https://wiki.analog.com/resources/fpga/docs/build#xilinx_auto_tcl_build
- Xilinx Zynq SDR: This is supported by MathWorks and you would need to ask their support if you have questions
I'm a bit confused, I already built the TcL from exporting the block design from Vivado. I just want access to the donut hole. The reference design I built by converting the kcu105 reference design does not have that exposed. Is it just a matter of creating more ports on the UPACK / TXFIFO and CPACK/ RXFIFO?
https://github.com/analogdevicesinc/hdl/tree/master/projects/fmcomms2
This is where I got the initial reference design from.
The path that MATLAB uses for those Analog Devices reference designs is what I am looking for.
You asked where are the reference designs. That is what my answer reflects above. The shipped HDL within the ADI toolboxes comes from the HDL repo (https://github.com/analogdevicesinc/hdl) with minor tweak.
Are you looking for something else?
Yeah, sorry. I want to know how to make those minor changes to my reference design so that when I use the workflow advisor. I will get a prompt like this. which allows me to connect my ip core to the ADC. The bottom 2 pictures are my VCU108 reference design being used. How are you guys seperating the TX/RX reference design also?
and this
and not like this
and this
My question would be "How do I create the donut hole in my reference design"
First you need to create a spot where you would want to insert IP then save the reference design in that form. This usually just requires removing a few nets. Then follow this guide: https://www.mathworks.com/help/hdlcoder/ug/define-and-register-custom-board-and-reference-design-for-zynq-workflow.html
Would my open nets need to be defined as external ports? That's also another reason I wanted to see the .m files of the fmcomms2/zcu102 to see how they are defining these nets for the workforce advisor. I'll continue working on this.
Here is an example of the pruning we do for FMComms2/3: https://github.com/analogdevicesinc/TransceiverToolbox/blob/master/CI/scripts/matlab_processors.tcl#L438
Here is how we connect stuff in MATLAB in a custom demo: https://github.com/analogdevicesinc/TransceiverToolbox/blob/master/trx_examples/targeting/frequency-hopping/%2BAnalogDevicesDemo/%2Badrv9361z7035/%2Bccfmc_lvds_hop/%2Brxtx/add_rx_tx_io.m
@tfcollins I am running into an error at the last step of Generation. My task is not sourcing the correct .tcl scripts, I cross-referenced with the ZCU
ZCU102 Output:
****** Vivado v2022.2 (64-bit)
**** SW Build 3671981 on Fri Oct 14 05:00:03 MDT 2022
**** IP Build 3669848 on Fri Oct 14 08:30:02 MDT 2022
** Copyright 1986-2022 Xilinx, Inc. All Rights Reserved.
Sourcing tcl script 'C:/Users/jacksonlb/AppData/Roaming/Xilinx/Vivado/Vivado_init.tcl'
**
source C:/Users/jacksonlb/Desktop/FMCOMMS3-DEV/zcu-hdl-coder/vivado_ip_prj/library/axi_ad9361/axi_ad9361_ip.tcl
**
# source ../scripts/adi_env.tcl
## set ad_hdl_dir [file normalize [file join [file dirname [info script]] "../.."]]
## set ad_ghdl_dir [file normalize [file join [file dirname [info script]] "../../../ghdl"]]
## if [info exists ::env(ADI_HDL_DIR)] {
## set ad_hdl_dir [file normalize $::env(ADI_HDL_DIR)]
## }
## if [info exists ::env(ADI_GHDL_DIR)] {
## set ad_ghdl_dir [file normalize $::env(ADI_GHDL_DIR)]
## }
VCU108 Output:
Sourcing tcl script 'C:/Users/jacksonlb/AppData/Roaming/Xilinx/Vivado/Vivado_init.tcl'
**source vivado_create_prj.tcl -notrace**
INFO: [IP_Flow 19-234] Refreshing IP repositories
INFO: [IP_Flow 19-1700] Loaded user IP repository 'c:/Users/jacksonlb/Desktop/FMCOMMS3-DEV/vcu108-hdl-coder/qpsk-vcu108-hdlcoder/vivado_ip_prj/ipcore'.
INFO: [IP_Flow 19-2313] Loaded Vivado IP repository 'C:/Xilinx/Vivado/2022.2/data/ip'.
INFO: [IP_Flow 19-1839] IP Catalog is up to date.
INFO: [BD::TCL 103-2003] Currently there is no design <system> in project, so creating one...
Wrote : <C:\Users\jacksonlb\Desktop\FMCOMMS3-DEV\vcu108-hdl-coder\qpsk-vcu108-hdlcoder\vivado_ip_prj\vivado_prj.srcs\sources_1\bd\system\system.bd>
INFO: [BD::TCL 103-2004] Making design <system> as current_bd_design.
INFO: [BD::TCL 103-2005] Currently the variable <design_name> is equal to "system".
INFO: [BD::TCL 103-2011] Checking if the following IPs exist in the project's IP catalog:
xilinx.com:ip:xlconstant:1.1 analog.com:user:axi_ad9361:1.0 analog.com:user:axi_dmac:1.0 analog.com:user:util_rfifo:1.0 xilinx.com:ip:smartconnect:1.0 xilinx.com:ip:ddr4:2.2 xilinx.com:ip:proc_sys_reset:5.0 xilinx.com:ip:axi_ethernet:7.2 xilinx.com:ip:axi_dma:7.1 xilinx.com:ip:axi_gpio:2.0 xilinx.com:ip:axi_iic:2.1 xilinx.com:ip:axi_intc:4.1 xilinx.com:ip:axi_quad_spi:3.2 analog.com:user:axi_sysid:1.0 xilinx.com:ip:axi_timer:2.0 xilinx.com:ip:axi_uartlite:2.0 analog.com:user:sysid_rom:1.0 xilinx.com:ip:xlconcat:2.1 xilinx.com:ip:lmb_v10:3.0 xilinx.com:ip:lmb_bram_if_cntlr:4.0 xilinx.com:ip:blk_mem_gen:8.4 xilinx.com:ip:microblaze:11.0 xilinx.com:ip:mdm:3.2 analog.com:user:util_wfifo:1.0 analog.com:user:util_cpack2:1.0 analog.com:user:util_upack2:1.0 analog.com:user:util_clkdiv:1.0 xilinx.com:ip:util_reduced_logic:2.0 analog.com:user:util_tdd_sync:1.0 .
INFO: [Device 21-403] Loading part xcvu095-ffva2104-2-e
WARNING: [BD 5-699] No address segments matched 'get_bd_addr_segs -of_object /ilmb_cntlr/SLMB/Mem'
WARNING: [BD 5-699] No address segments matched 'get_bd_addr_segs -of_object /second_ilmb_cntlr/SLMB/Mem'
WARNING: [BD 5-699] No address segments matched 'get_bd_addr_segs -of_object /dlmb_cntlr/SLMB/Mem'
WARNING: [BD 5-699] No address segments matched 'get_bd_addr_segs -of_object /second_dlmb_cntlr/SLMB/Mem'
WARNING: [BD 5-699] No address segments matched 'get_bd_addr_segs -of_object /iomodule_0/SLMB/Reg'
WARNING: [BD 5-699] No address segments matched 'get_bd_addr_segs -of_object /iomodule_0/SLMB/IO'
create_bd_cell: Time (s): cpu = 00:00:23 ; elapsed = 00:00:28 . Memory (MB): peak = 2211.812 ; gain = 1093.418
WARNING: [BD 5-699] No address segments matched 'get_bd_addr_segs -of_object /ilmb_cntlr/SLMB/Mem'
WARNING: [BD 5-699] No address segments matched 'get_bd_addr_segs -of_object /second_ilmb_cntlr/SLMB/Mem'
WARNING: [BD 5-699] No address segments matched 'get_bd_addr_segs -of_object /dlmb_cntlr/SLMB/Mem'
WARNING: [BD 5-699] No address segments matched 'get_bd_addr_segs -of_object /second_dlmb_cntlr/SLMB/Mem'
WARNING: [BD 5-699] No address segments matched 'get_bd_addr_segs -of_object /iomodule_0/SLMB/Reg'
WARNING: [BD 5-699] No address segments matched 'get_bd_addr_segs -of_object /iomodule_0/SLMB/IO'
ERROR: [IP_Flow 19-3461] Value 'ddr4_sdram_c1_DR' is out of the range for parameter 'C0 DDR4 BOARD INTERFACE(C0_DDR4_BOARD_INTERFACE)' for BD Cell 'axi_ddr_cntrl' . Valid values are - Custom
ERROR: [IP_Flow 19-3461] Value 'default_sysclk1_300' is out of the range for parameter 'C0 CLOCK BOARD INTERFACE(C0_CLOCK_BOARD_INTERFACE)' for BD Cell 'axi_ddr_cntrl' . Valid values are - Custom
ERROR: [IP_Flow 19-3461] Value 'reset' is out of the range for parameter 'RESET BOARD INTERFACE(RESET_BOARD_INTERFACE)' for BD Cell 'axi_ddr_cntrl' . Valid values are - Custom
INFO: [IP_Flow 19-3438] Customization errors found on 'axi_ddr_cntrl'. Restoring to previous valid configuration.
The correct script is source C:/Users/jacksonlb/Desktop/FMCOMMS3-DEV/zcu-hdl-coder/vivado_ip_prj/library/axi_ad9361/axi_ad9361_ip.tcl
Mine is calling source vivado_create_prj.tcl -notrace
How can I figure out where this initial call is starting from so that mine will take the same route?
vivado_create_prj.tcl is a script MATLAB generates which will map in any special variables and then invoke your script defined by the CustomBlockDesignTcl setting. If you look inside vivado_create_prj.tcl does it point to your CustomBlockDesignTcl defined script?
There is, but I just noticed the ZCU create_prj.tcl is different from mine.
ZCU
create_project vivado_prj {} -part xczu9eg-ffvb1156-2-e -force
set_property target_language Verilog [current_project]
set defaultRepoPath {./ipcore}
set_property ip_repo_paths $defaultRepoPath [current_fileset]
update_ip_catalog
set ipList [glob -nocomplain -directory $defaultRepoPath *.zip]
foreach ipCore $ipList {
set folderList [glob -nocomplain -directory $defaultRepoPath -type d *]
if {[lsearch -exact $folderList [file rootname $ipCore]] == -1} {
catch {update_ip_catalog -add_ip $ipCore -repo_path $defaultRepoPath}
}
}
update_ip_catalog
set project {fmcomms2}
set carrier {zcu102}
set ref_design {rxtx}
set fpga_board {ZCU102}
set preprocess {off}
set postprocess {off}
set number_of_inputs {4}
set number_of_bits {16}
set number_of_valids {1}
set multiple {1}
set HDLVerifierJTAGAXI {off}
source vivado_custom_block_design.tcl
# Use global synthesis for this project
set_property synth_checkpoint_mode None [get_files system.bd]
save_bd_design
close_project
exit
VCU
create_project vivado_prj {} -part xcvu095-ffva2104-2-e -force
set_property target_language Verilog [current_project]
set defaultRepoPath {./ipcore}
set_property ip_repo_paths $defaultRepoPath [current_fileset]
update_ip_catalog
set ipList [glob -nocomplain -directory $defaultRepoPath *.zip]
foreach ipCore $ipList {
set folderList [glob -nocomplain -directory $defaultRepoPath -type d *]
if {[lsearch -exact $folderList [file rootname $ipCore]] == -1} {
catch {update_ip_catalog -add_ip $ipCore -repo_path $defaultRepoPath}
}
}
update_ip_catalog
set HDLVerifierJTAGAXI {off}
source vivado_custom_block_design.tcl
# Use global synthesis for this project
set_property synth_checkpoint_mode None [get_files system.bd]
# Update output frequency on clock wizard based on target frequency
set_property -dict [list CONFIG.CLKOUT1_REQUESTED_OUT_FREQ {50.000}] [get_bd_cells core_clkwiz]
save_bd_design
close_project
exit
CustomBlockDesign Differences
ZCU
set start_dir [pwd]
puts "Starting Transceiver Toolbox HDL build"
if {$preprocess == "on"} {
source $preprocess_script
}
if {$project == "pluto"} {
cd projects/$project/
source ../scripts/adi_make.tcl
} else {
cd projects/$project/$carrier
source ../../scripts/adi_make.tcl
}
adi_make::lib all
VCU
################################################################
# This is a generated script based on design: system
#
# Though there are limitations about the generated script,
# the main purpose of this utility is to make learning
# IP Integrator Tcl commands easier.
################################################################
namespace eval _tcl {
proc get_script_folder {} {
set script_path [file normalize [info script]]
set script_folder [file dirname $script_path]
return $script_folder
}
}
variable script_folder
set script_folder [_tcl::get_script_folder]
################################################################
# Check if script is running in correct Vivado version.
################################################################
set scripts_vivado_version 2022.2
set current_vivado_version [version -short]
source vivado_custom_block_design.tcl will be the CustomBlockDesignTcl script, just copied to vivado_prj and renamed. Is this not the case for you?
I don't think so, because mine doesn't initiate Transceiver Toolbox HDL Build. Unless Im misunderstanding you.
To be honest it doesnt look like its sourcing the vivado_custom_block_design.tcl that is inside the vivado_ip_prj folder. Could it be running it from somewhere else?
To be honest it doesnt look like its sourcing the vivado_custom_block_design.tcl that is inside the vivado_ip_prj folder. Could it be running it from somewhere else?
vivado_ip_prj is where it runs from. Can you paste the script you reference with CustomBlockDesignTcl?
Ok so this is the same as the above snippet. So what is the problem then?
Could I email you? I don't like the formatting of github.
The problem I am having is that my customblockdesignTcL does not have the correct contents. It should, from my observation run the adi scripts at some point.
But there is no reference to ADI scripts in the TcL, so It fails because it's not using the wrappers for the TcL commands.
Another difference I am seeing is that when MATLAB creates the vivado_ip_prj folder it includes the library folder for the zcu with all the ipcores. Currently I have to add those myself under the ipcore folder.
The problem I am having is that my customblockdesignTcL does not have the correct contents. It should, from my observation run the adi scripts at some point.
Run what ADI scripts? All HDL-Coder does is invoke the script you tell it to run.
Another difference I am seeing is that when MATLAB creates the vivado_ip_prj folder it includes the library folder for the zcu with all the ipcores. Currently I have to add those myself under the ipcore folder.
If you need specific folders or source files in vivado_pro this is what CustomFiles does
Maybe this an issue of which matlab package I referenced... I grabbed the ZCU102 pacakge from here and repurposed it to the VCU108. Is there another location where the AnalogDevices packages are with the boards?
This might be it, Please let me know if there is a better directory.
You should not need any HDL code or TCL scripts from Transceiver Toolbox itself or another support package from MathWorks. You have the complete reference design if you exported from Vivado using the TCL export.
The scripted defined by CustomBlockDesignTcl is mean to construct the block design or simply load it before MATLAB will try to insert IP into it.
If you are debugging things, launch Vivado and invoke the vivado_custom_block_design script. At completion it should have a block design built with the necessary components removed so you can insert your IP in a required location.
Not ideal, but I've gotten it to make progress by changing some variable to "Custom" instead of what they were before. But these variables were set when I generated the reference design from the hdl folder.
I wouldve expected the export block design from Vivado to just work... since I have been able to implement it and create a bitstream
Another thing I'm noticing. Export Block Design does not have my ip cores associating themselves with my specific board. Is there a way to get this back?
These 3 variables I was required to change them to custom.
Not ideal, but I've gotten it to make progress by changing some variable to "Custom" instead of what they were before. But these variables were set when I generated the reference design from the hdl folder.
I don't follow you. What is changing to customer... MATLAB or Vivado setting?
Another thing I'm noticing. Export Block Design does not have my ip cores associating themselves with my specific board. Is there a way to get this back?
If something is not save across the export and reload process then you will have to ask Xilinx. Nothing we can do there.
This issue was fixed by changing this
set_property board_part xilinx.com:vcu108:part0:1.7 [current_project]
to this
set_property board_part xilinx.com:vcu108:part0:1.7 [current_project]
reset_property board_connections [get_projects vivado_prj]
Success! Another edit to createblockdesigntcl
Create instance: axi_ddr_cntrl, and set properties
set axi_ddr_cntrl [ create_bd_cell -type ip -vlnv xilinx.com:ip:ddr4:2.2 axi_ddr_cntrl ]
set_property -dict [list
CONFIG.ADDN_UI_CLKOUT1_FREQ_HZ {100} \ <---- This was missing
CONFIG.ADDN_UI_CLKOUT2_FREQ_HZ {200} \
@tfcollins When I copied the ZCU102 plugin_rd.m file this clkwiz interface was in there. - Is the workflow prompting me to make this decision because of that file? or
- Can I take this out and keep my reference design running at 300MHz?
When MATLAB inserts IP it needs to give it a clock. This is used for the data and the control (AXI-LITE) interface. This is required to my knowledge
@tfcollins This one signal is giving me issues, if I have axi stream set for the dma, I get this error.
connect_bd_intf_net -intf_net util_ad9361_adc_pack_packed_fifo_wr [get_bd_intf_pins axi_ad9361_adc_dma/fifo_wr] [get_bd_intf_pins util_ad9361_adc_pack..."
The problem being if I am streaming I cant have the fifo interface
% DMA Ready signal
hRD.addInternalIOInterface( ...
'InterfaceID', 'DMA Ready', ...
'InterfaceType', 'IN', ...
'PortName', 'dma_rdy', ...
'PortWidth', 1, ...
'InterfaceConnection', 'axi_ad9361_adc_dma/s_axis_ready', ...
'IsRequired', false);
This all stems from setting this in the workflow advisor. Which to my knowledge is needed
