Compilation of designs with no AXI bram / software registers fail

[SergeyMushinsky]

Hi,
If I create a simulink model containing red_pitaya_dac block with no software_register block or snapshot block, compilation process fails with the following error:

INFO: Launching helper process for spawning children vivado processes
INFO: Helper process launched with PID 799

Starting RTL Elaboration : Time (s): cpu = 00:00:02 ; elapsed = 00:00:03 . Memory (MB): peak = 1831.582 ; gain = 153.715 ; free physical = 2945 ; free virtual = 7209

ERROR: [Synth 8-2772] type t_axi4lite_mmap_addr_arr does not match with a string literal [/home/ub/work/mlib_devel/jasper_library/test_models/test_red_pitaya_adc_dac/myproj/myproj.srcs/sources_1/imports/xml2vhdl_hdl_output/axi4lite_axi4lite_top_mmap_pkg.vhd:94]
ERROR: [Synth 8-2772] type t_axi4lite_mmap_addr_arr does not match with a string literal [/home/ub/work/mlib_devel/jasper_library/test_models/test_red_pitaya_adc_dac/myproj/myproj.srcs/sources_1/imports/xml2vhdl_hdl_output/axi4lite_axi4lite_top_mmap_pkg.vhd:95]
INFO: [Synth 8-2810] unit axi4lite_axi4lite_top_mmap_pkg ignored due to previous errors [/home/ub/work/mlib_devel/jasper_library/test_models/test_red_pitaya_adc_dac/myproj/myproj.srcs/sources_1/imports/xml2vhdl_hdl_output/axi4lite_axi4lite_top_mmap_pkg.vhd:67]

Finished RTL Elaboration : Time (s): cpu = 00:00:02 ; elapsed = 00:00:04 . Memory (MB): peak = 1886.301 ; gain = 208.434 ; free physical = 2970 ; free virtual = 7234

RTL Elaboration failed
INFO: [Common 17-83] Releasing license: Synthesis
7 Infos, 0 Warnings, 0 Critical Warnings and 3 Errors encountered.
synth_design failed
ERROR: [Common 17-69] Command failed: Synthesis failed - please see the console or run log file for details
INFO: [Common 17-206] Exiting Vivado at Fri Apr 2 20:58:24 2021...

The bug is easy to reproduce using test_red_pitaya_adc_dac.slx model which is a part of tutorial. Original model compiles with no errors but if you delete software_register blocks (and other block connected to them - in the right bottom part of model) you get error.

[AdamI75]

@serega2138: Thanks for your post. This is interesting. Please can you attach your slx and we will investigate further. I will be back in the office on 7th April 2021.

[SergeyMushinsky]

Thank you for your reply. test_red_pitaya_adc_dac.slx is a file from tutorial - it is fine. test_red_pitaya_adc_dac_no_regs.slx is a modifed file - it is not ok. [models.zip](https://github.com/casper-astro/tutorials_devel/files/6258832/models.zip)

[AdamI75]

@serega2138 Thanks, I will check it out this week and let you know.

[AdamI75]

@serega2138: Yes, I can confirm what you are seeing. We will investigate further and let you know.

[AdamI75]

@serega2138: Yes, I can confirm that the code definitely expects there to be at least two AXI slaves: the sys_block and at least one sw_reg. This is how XML2VHDL currently works. I see the option as follows:

1. Change the code in www.github.com/casper-astro/xml2vhdl to support no software registers or snap shots i.e. if the number of AXI slaves are 1 (sys_block only) then change the code to handle that.
2. Add code to the toolflow to check if there are no yellow block software and snap shot yellow block registers and then warn the users and refuse to compile further.
3. Make no changes and always ensure that you have at least one software register or snap shot block.

The thing is that most models use the software register and snap blocks to add control, status read back and read back a snap shot of data. @jkocz and @jack-h: what do you think? It is not a major bug, but it can be frustrating for users to have their compile bomb out. Most users who use the tutorials as is will not encounter this bug.

[SergeyMushinsky]

I agree, this is not a major bug. I believe options 2 or 3 are good enough. Also it might be worth mentioning in tutorials.

[AdamI75]

@serega2138: I will put this on the agenda for the CASPER tech dev meeting that is happening on Thursday and let you know. Thanks for your inputs.

[AdamI75]

@jkocz I had forgotten about this. Is this something we would like resolved, in your opinion? I am sure a plan could be made. Let me know.

[jack-h]

I _think_ one relatively easy improvement would be to add a `drc` method ( https://github.com/casper-astro/mlib_devel/blob/bc2bc99c27793ead0cfddf4c9c399624dfde0f98/jasper_library/yellow_blocks/yellow_block.py#L202) to https://github.com/casper-astro/mlib_devel/blob/m2021a/jasper_library/yellow_blocks/axi4lite_interconnect.py It looks like the axi interconnect yellow block should know enough via it's `memory_map` attribute to flag if these aren't enough BRAMs / regs. Obviously this wouldn't fix the underlying issue, but at least the user could be told something useful about what is wrong rather than the current cryptic messages

…

On Fri, 16 Sept 2022 at 09:35, AdamI75 ***@***.***> wrote: @jkocz <https://github.com/jkocz> I had forgotten about this. Is this something we would like resolved, in your opinion? I am sure a plan could be made. Let me know. — Reply to this email directly, view it on GitHub <#178 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKWM7CV255ZAKSV6QYJGULV6QWMFANCNFSM6AAAAAAQN5FIY4> . You are receiving this because you were mentioned.Message ID: ***@***.***>