VCS Simulation of HammerBlade

[Ruchita]

Hi,

I am master student in Australia, I was doing simulation of hammerblade-example, I am curious to know in ps.cpp at line 229 (https://github.com/black-parrot-hdk/zynq-parrot/blob/master/cosim/hammerblade-example/ps.cpp), mc_epa = (mc_pkt.addr << 2) & 0xffff,  where or how "mc_pkt.addr" is generated or calculated in .v  file or .sv file or .vh file or .svh file?

Thanks,

Ruchita Sonal

[Dan Petrisko]

Hello!

The definition is in bsg_replicant: https://github.com/bespoke-silicon-group/bsg_replicant/blob/main/libraries/bsg_manycore_packet.h

which is an import of ZynqParrot. This is the main software repository for host-manycore interaction.

The software is kept in sync with the hardware definition of the manycore packet here: https://github.com/bespoke-silicon-group/bsg_manycore/blob/master/v/bsg_manycore_defines.svh

Best,

-Dan

--
You received this message because you are subscribed to the Google Groups "black-parrot" group.
To unsubscribe from this group and stop receiving emails from it, send an email to black-parrot...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/black-parrot/5d7ffb81-4c4d-4881-9879-6fde32db5f94n%40googlegroups.com.

[Ruchita]

Thanks Dan. Sorry, I forgot to tell you the reason why I require  mc_pkt.addr, it is because when I run VCS simulation, I am not getting any result/display from BlackParrot, following output shown in blue and red. I guess it is missing packet after "blue color display". I am wondering, where could I debug this problem? 

// bsg_zynq_pl: be sure to run as root
INFO:    ps.cpp: reading three base registers
INFO:    ps.cpp: dram_base=0
Creating Bitbang Driver: 4 16 1
INFO:    Reset Tag Master
Resetting Tag Client 0
Setting Tag Client 0<-1
Setting Tag Client 0<-0
Idling for 50
INFO:    ps.cpp: calling allocate dram with size 209715200
  bsg_zynq_pl: Allocated dummy DRAM
INFO:    ps.cpp: received 0x7f206cc42010 (phys = 7f206cc42010)
INFO:    ps.cpp: wrote and verified base register
INFO:    Starting NBF load
INFO:    ps.cpp: nbf finish command, line 8350
INFO:    Waiting for credit drain
INFO:    Credits drained
INFO:    ps.cpp: Starting scan thread
INFO:    ps.cpp: Starting MC i/o polling thread
INFO:    Errant request packet: 1260 0

Manycore>> Hello from core 0, 0 in group origin=(0,0).
Manycore>> Values in DRAM:ffffffff,00000001,0000000f,80000000,

Manycore stderr>> Hello!
Interrupt array at 0x0
Manycore stderr>> Hello!

INFO:    MC finish packet received 1
INFO:    ps.cpp: Starting BP i/o polling thread
INFO:    Request packet [2000] = 0
INFO:    BP finish packet received 1
bsg_zynq_pl: done() called, exiting

[Daniel Petrisko]

Hmm, that does seem odd. 

>INFO:    Errant request packet: 1260 0

First, I would investigate where this is coming from

>INFO:    BP finish packet received 1

It is getting a BP finish packet, so likely the program is executing correctly and the prints are just not working

I would check if the BP print packets are exiting the system (through the manycore I/O link) or if they are getting dropped somewhere else

-Dan

[Ruchita]

Hello Dan,

It seems I found a problem,  the line no 151 at: https://github.com/black-parrot-hdk/black-parrot-subsystems/blob/9fe39ef27fd0887d693c18ccb52de05e35ca8b9c/manycore/v/bp_me_manycore_mmio.sv "host_epa_lo = mem_fwd_header_cast_i.addr[2+:addr_width_p];"  I am getting only BP Finished packet address of 40800,  in order to print some characters before BP finish packet received 1 , I think  it has to get address of 40400  from mem_fwd_header_cast_i.addr[2+:addr_width_p] and this packet is missing.  I did grep of  mem_fwd_header_cast_i.addr and mem_fwd_header_cast_i, I am unable to locate where this is assigned or generated or defined...can you please tell me  where mem_fwd_header_cast_i.addr or mem_fwd_header_cast_i is assigned or generated?

Thanks,

Ruchita Sonal

[Daniel Petrisko]

Hi Ruchita,

It's an mmio store, so the C program it will generate some number of writes which will bypass the D$ and propagate through the memory system. Is the bp_me_manycore_mmio bridge receiving _any_ packets other than the finish packet? If you look at the disassembly, does the program actually generate them? If they are in the program, then you should be able to see writes in the D$ at leaste

Best,

-Dan

[Ruchita]

Hi Dan,

I printed  bsg_pr_info("Packet  Address: %x\n", mc_pkt.addr);  after line #230 at https://github.com/black-parrot-hdk/zynq-parrot/blob/master/cosim/hammerblade-example/ps.cpp  I printed mc_pkt.addr  I guess it is coming from bp_me_manycore_mmio bridge following is the output shown in Red. It seems to me some packets are lost, but I am unable to figure out where and how?

// bsg_zynq_pl: be sure to run as root
INFO:    ps.cpp: reading three base registers
INFO:    ps.cpp: dram_base=0
Creating Bitbang Driver: 4 16 1
INFO:    Reset Tag Master
Resetting Tag Client 0
Setting Tag Client 0<-1
Setting Tag Client 0<-0
Idling for 50
INFO:    ps.cpp: calling allocate dram with size 209715200
  bsg_zynq_pl: Allocated dummy DRAM

INFO:    ps.cpp: received 0x7fb81c87b010 (phys = 7fb81c87b010)

INFO:    ps.cpp: wrote and verified base register
INFO:    Starting NBF load
INFO:    ps.cpp: nbf finish command, line 8350
INFO:    Waiting for credit drain
INFO:    Credits drained
INFO:    ps.cpp: Starting scan thread
INFO:    ps.cpp: Starting MC i/o polling thread
INFO:    Errant request packet: 1260 0

Manycore>> Hello from core 0, 0 in group origin=(0,0).

Manycore>> Values in DRAM:Manycore>> Values in DRAM:ffffffff,00000001,0000000f,80000000,

Manycore stderr>> Hello!

Interrupt array at 0x0

INFO:    MC finish packet received 1
INFO:    ps.cpp: Starting BP i/o polling thread

INFO:    Packet  Address: 40800

INFO:    BP finish packet received 1
bsg_zynq_pl: done() called, exiting

Best,

-Ruchita

[Dan Petrisko]

Hi Ruchita,

Yeah you’ll definitely need to poke in the RTL of the bridge with either waveform analysis or adding $display statements. I’ll take a look this week to make sure it’s working on my end

Can you share your VCS version? If you can email me (privately) a VPD waveform dump I can diff that a with my local results 

Best,

-Dan

On Aug 31, 2025, at 5:30 AM, Ruchita <sonal.nil...@gmail.com> wrote:

Hi Dan,

To view this discussion visit https://groups.google.com/d/msgid/black-parrot/dd49d216-8b57-440b-8819-6cae2ad5b82dn%40googlegroups.com.

[Dan Petrisko]

Hi Ruchita,

Sorry for the delay, I have been busy with graduation.

I've bumped all the repos to the latest in commit b96c357. I don't see your issue and am successfully observing both BP and MC output. Could you try with this commit and see if the BP input is still missing for you?

It occurs to me that it could be a software issue as well. Perhaps checking the objdump of the BP binary as well as the combined .riscv file could be useful.

BSG-INFO:    ps.cpp: reading three base registers
BSG-INFO:    ps.cpp: dram_base=0
BSG-INFO:    Creating Bitbang Driver: 0x1e751d0 40000004 16 1
BSG-INFO:    Reset Tag Master
BSG-INFO:    Resetting Tag Client 0
BSG-INFO:    Setting Tag Client 0<-1
BSG-INFO:    Setting Tag Client 0<-0
bsg_nonsynth_zynq_testbench.dut.top_fpga_inst.hammerblade.mesh.manycore.py[0].podrow.px[0].pod.mc_y[0].mc_x[0].mc.y[0].x[0].tile.proc.h.z.vcore cfg_pod_r changing to y=000001 x=000001
bsg_nonsynth_zynq_testbench.dut.top_fpga_inst.hammerblade.mesh.manycore.py[0].podrow.px[0].pod.mc_y[0].mc_x[0].mc.y[0].x[1].tile.proc.h.z.vcore cfg_pod_r changing to y=000001 x=000001
bsg_nonsynth_zynq_testbench.dut.top_fpga_inst.hammerblade.mesh.manycore.py[0].podrow.px[0].pod.mc_y[0].mc_x[0].mc.y[1].x[0].tile.proc.h.z.vcore cfg_pod_r changing to y=000001 x=000001
bsg_nonsynth_zynq_testbench.dut.top_fpga_inst.hammerblade.mesh.manycore.py[0].podrow.px[0].pod.mc_y[0].mc_x[0].mc.y[1].x[1].tile.proc.h.z.vcore cfg_pod_r changing to y=000001 x=000001
BSG-INFO:    Idling for 50
BSG-INFO:    ps.cpp: calling allocate dram with size 134217728
BSG-INFO:      bsg_zynq_pl: Allocated dummy DRAM
BSG-INFO:    ps.cpp: received 0x7f2b40d1b010 (phys = 7f2b40d1b010)
BSG-INFO:    ps.cpp: wrote and verified base register
BSG-INFO:    Starting NBF load
BSG-INFO:    ps.cpp: nbf finish command, line 0
BSG-INFO:    Waiting for credit drain
[INFO][RX] Unfreezing tile t=19448500000, x=  2, y=  2
BSG-INFO:    Credits drained
BSG-INFO:    ps.cpp: Starting scan thread
BSG-INFO:    ps.cpp: Starting MC i/o polling thread
BSG-INFO:    Errant request packet: 1260 0

Manycore>> Hello from core 0, 0 in group origin=(0,0).
Manycore>> Values in DRAM:ffffffff,00000001,0000000f,80000000,


Manycore stderr>> Hello!

Interrupt array at 0x0

BSG-INFO:    MC finish packet received 1
BSG-INFO:    ps.cpp: Starting BP i/o polling thread
Hello World!
BSG-INFO:    BP finish packet received 1
BSG-INFO:      bsg_zynq_pl: done() called, exiting
[BSG-INFO]: Finish called for reason: cosim_main return
$finish called from file "/mnt/users/ssd0/no_backup/petrisko/zynq-parrot-stable/cosim/v/bsg_nonsynth_zynq_testbench.sv", line 662.
$finish at simulation time          20368525001

Best,

-Dan

[Ruchita]

Hi Dan,

Some how I got the  BP output  in VCS. Now, I am  planning to deploy this design in Virtex ML 507 board because we have this board in our lab. I am using vcs and vlogan to debug design after synthesis and implementation. What I did was, I generated netlist file for the  top module and replaced all *.sv and *.v files in flist.vcs in vcs directory with top.v netlist file, I left other files for testbench as it is,  like:

/home/lab/zynq-parrot/cosim/hammerblade-example/top.v  #syntheiis netlist file
/home/lab/zynq-parrot/import/basejump_stl/bsg_test/bsg_nonsynth_clock_gen.sv
/home/lab/zynq-parrot/import/basejump_stl/bsg_test/bsg_nonsynth_reset_gen.sv
/home/lab/zynq-parrot/import/basejump_stl/bsg_test/bsg_nonsynth_axi_mem.sv
/home/lab/zynq-parrot/import/basejump_stl/bsg_test/bsg_nonsynth_dpi_clock_gen.cpp
/home/lab/zynq-parrot/import/basejump_stl/bsg_test/bsg_nonsynth_dpi_clock_gen.sv
/home/lab/zynq-parrot/import/basejump_stl/bsg_test/bsg_nonsynth_dpi_gpio.sv
/home/lab/zynq-parrot/cosim/v/bsg_nonsynth_dpi_to_axil.sv
/home/lab/zynq-parrot/cosim/v/bsg_nonsynth_axil_to_dpi.sv
/home/lab/zynq-parrot/cosim/v/bsg_nonsynth_zynq_testbench.sv

When I execute make run after make simv, it is crashing after INFO:    ps.cpp: reading three base registers as shown below

Instantiating AXIL at bsg_nonsynth_zynq_testbench.axil4
bsg_zynq_pl: Entering reset
__________ ___________  _______________________________
\______   \\_   _____/ /   _____/\_   _____/\__    ___/
 |       _/ |    __)_  \_____  \  |    __)_   |    |  
 |    |   \ |        \ /        \ |        \  |    |  1->0 time =     500000
 |____|_  //_______  //_______  //_______  /  |____|  
 ASYNC  \/         \/         \/         \/            
bsg_zynq_pl: Exiting reset
bsg_zynq_pl: Exiting reset
bsg_zynq_pl: Exiting reset

INFO:    ps.cpp: reading three base registers

An unexpected termination has occurred in ./simv due to a signal: Segmentation fault


During DPI-C function call Function="cosim_main" from /home/lab/zynq-parrot/cosim/v/bsg_nonsynth_zynq_testbench.sv, 470

Command line: ./simv +c_args=hello.hello_world.nbf +bsg_trace +vpdfilesize+512

--- Stack trace follows:

Dumping VCS Annotated Stack:
#0  0x00002aaab5a0960c in waitpid () from /lib64/libc.so.6
#1  0x00002aaab5986f62 in do_system () from /lib64/libc.so.6
#2  0x00002aaaaca475c0 in SNPSle_10ee25eff68cd8461c9146fa1d0b35e87067f3c8015b313e639d2928478c79b3f673f99203bcf8be64600612100082236bffb2007f1e0ef9 () from /home/lab/vcs/vcs/U-2023.03/linux64/lib/liberrorinf.so
#3  0x00002aaaaca4911c in SNPSle_10ee25eff68cd8461c9146fa1d0b35e87067f3c8015b313efba706aab251478fa49e66610e453774633a6c152e7ef778f93045171fb3645d () from /home/lab/vcs/vcs/U-2023.03/linux64/lib/liberrorinf.so
#4  0x00002aaaaca41363 in SNPSle_d35ca1ff70d465c2b9b1a72eee90a50630165806651fae96c1bbda5b5d02066c () from /home/lab/vcs/vcs/U-2023.03/linux64/lib/liberrorinf.so
#5  0x00002aaaaf1ddcbb in SNPSle_64133461705005bb725549e2e6fa1b3f () from /home/lab/vcs/vcs/U-2023.03/linux64/lib/libvcsnew.so
#6  0x00002aaaaee59edd in SNPSle_82244d58c54c18c70d63edc9becab634 () from /home/lab/vcs/vcs/U-2023.03/linux64/lib/libvcsnew.so
#8  0x000000000043af68 in boost::context::detail::invoke<boost::coroutines2::detail::pull_coroutine<void>::control_block::control_block<boost::context::basic_fixedsize_stack<boost::context::stack_traits>, bsg_zynq_pl_simulation::uart_read(int, unsigned long, std::function<void (int)>)::{lambda(boost::coroutines2::detail::push_coroutine<void>&)#1}>(boost::context::preallocated, boost::context::basic_fixedsize_stack<boost::context::stack_traits>&&, bsg_zynq_pl_simulation::uart_read(int, unsigned long, std::function<void (int)>)::{lambda(boost::coroutines2::detail::push_coroutine<void>&)#1}&&)::{lambda(boost::context::fiber&&)#1}&, bsg_zynq_pl_simulation::uart_read(int, unsigned long, std::function<void (int)>)::{lambda(boost::coroutines2::detail::push_coroutine<void>&)#1}&&> ()
#9  0x000000000043b39b in void boost::context::detail::fiber_entry<boost::context::detail::fiber_record<boost::context::fiber, boost::context::basic_fixedsize_stack<boost::context::stack_traits>, boost::coroutines2::detail::pull_coroutine<void>::control_block::control_block<boost::context::basic_fixedsize_stack<boost::context::stack_traits>, bsg_zynq_pl_simulation::uart_read(int, unsigned long, std::function<void (int)>)::{lambda(boost::coroutines2::detail::push_coroutine<void>&)#1}>(boost::context::preallocated, boost::context::basic_fixedsize_stack<boost::context::stack_traits>&&, bsg_zynq_pl_simulation::uart_read(int, unsigned long, std::function<void (int)>)::{lambda(boost::coroutines2::detail::push_coroutine<void>&)#1}&&)::{lambda(boost::context::fiber&&)#1}> >(boost::context::detail::transfer_t) ()
#10 0x000000000045e88f in make_fcontext ()
#11 0x0000000000000000 in ?? ()

Process VmPeak: 916872 kb, VmSize: 916868 kb
System Free Memory: 6250500 kb, System Free Swap: 32833532 kb

I am wondering where it is going wrong? I am curious, how did you debug the design for FPGA implementation especially after synthesis and implementation? It could  be post synthesis functional simulation or post synthesis timing  simulation similarly for implementation simulation.

Regards,

Ruchita

 

 

[Dan Petrisko]

>Some how I got the  BP output  in VCS.

Cool. Did you update to the latest version or was there a fix you applied to the old version?

>I am wondering where it is going wrong? I am curious, how did you debug the design for FPGA implementation especially after synthesis and implementation? It could  be post synthesis functional simulation or post synthesis timing  simulation similarly for implementation simulation.

I haven't seen much value in post-synthesis FPGA simulations for this type of design (single clock domain, no third-party IP) so we haven't really explored that. I somewhat doubt that's what's happening here, since it is a segfault which implies a DPI issue. For functional simulation, you may need to insert a global unit delay (as you would do in an ASIC post-synth simulation) so that the DPI GPIOs sync properly with the clock.  We have not tested this flow for ZynqParrot but we did verify at some point that it worked with BlackParrot itself.

When debugging simulation/board mismatches, we typically insert an ILA probe on the AXI shell and DRAM interfaces. Then we can query design information through synthesizable hierarchical references.

>bsg_zynq_pl_simulation::uart_read

It seems a wrong flag is being passed in the testbench infrastructure, as the AXIL interface to the shell is the default. There are a lot of `defines being passed during the normal simulation flow. For instance, the HOST_ZYNQ define is used to select between the AXIL shell and the UART shell:

https://github.com/black-parrot-hdk/zynq-parrot/blob/master/cosim/include/common/zynq_headers.h

https://github.com/black-parrot-hdk/zynq-parrot/blob/7a1be3aaab29d40b55b7fd9db4ecf34aecadf791/cosim/include/common/bsg_zynq_pl_simulation.h#L158

If the usage is intentional, the UART shell is not well tested in simulation. I would try passing CFLAGS to VCS to increase debugging verbosity and stack traces to see what's actually happening. 

Best,

-Dan

To view this discussion visit https://groups.google.com/d/msgid/black-parrot/ea7a035a-c616-43c5-9ad3-a2bd361ca3a9n%40googlegroups.com.

[Ruchita]

Hi Dan,

> Cool. Did you update to the latest version or was there a fix you applied to the old version?

I applied fix to the older version for the file: https://github.com/black-parrot-hdk/black-parrot-subsystems/blob/fd9177f7b00ae9daf90928519c32c1cf786f212c/manycore/v/bp_me_manycore_mmio.sv line 334 I changed  always_comb to always @ (posedge clk_i)

I disabled the UART flag in VCS it worked for VCS simulation after synthesis  (functional simulation)  but it took more than 30 mins to simulate completely and to get Hello World! from BP. For timing simulation (after synthesis) it is taking more than 5 hours. For post timing simulation after implementation, there are lot of critical warnings. I have attached the file for your consideration. How did you fix these critical warnings?  I am wondering, have you tested hammerblade-example in any FPGA board? If not tested on any FPGA board, may I ask why? It seems to me, hammerblade-example is not a good fit for FPGA especially if the design operating in the range 20MHz-40Mhz with very complex fabric, however I might be completely wrong.

Regards,

-Ruchita.

[Dan Petrisko]

>I applied fix to the older version for the file: https://github.com/black-parrot-hdk/black-parrot-subsystems/blob/fd9177f7b00ae9daf90928519c32c1cf786f212c/manycore/v/bp_me_manycore_mmio.sv line 334 I changed  always_comb to always @ (posedge clk_i)

Hm, that doesn't seem like a correct fix as the intention is combinational logic. Hard to say what that's actually doing.

>I disabled the UART flag in VCS it worked for VCS simulation after synthesis  (functional simulation) 

Great, I would recommend doing that. Those times don't seem crazy to me. I've roughly observed RTL (1x) -> synth (5x) -> apr (2x) -> timing annotated gate sims (10x) for ASIC simulations if you have a big enough server. On smaller servers, the multiples can be higher if you need to swap. Depending on what you're doing, swapping out slower modules for C++ or unsynthesized RTL models can be a useful trick to increase speed.

>there are lot of critical warnings

Briefly looking through the log, they seem fine. For the most part they are just flops getting disconnected from the clock fabric. I'm not sure why these aren't being optimized away, but it's likely due to an optimization flag preserving unloaded flops.

> I am wondering, have you tested hammerblade-example in any FPGA board?

We've tested HammerBlade on VU37P, though not with the ZynqParrot infrastructure.

>It seems to me, hammerblade-example is not a good fit for FPGA especially if the design

HammerBlade is an ASIC design we're prototyping using FPGA. It's been taped out multiple times for ~1-2 GHz in 12nm and 28nm. While optimizations could make the current RTL map better, manycores are generally a poor fit for FGPAs as they have a high routing to flop ratio (as you've noted).

In general, I want to note that ZynqParrot is intended for prototyping and bringup, so the examples aim to demonstrate the infrastructure's different features. It's not intended for PPA optimality. That said, post-synthesis simulations could be a neat addition to the debugging process. Can you share the scripts or modifications you needed to make to get those working?

Best,

-Dan

To view this discussion visit https://groups.google.com/d/msgid/black-parrot/e0331752-64f7-4b5b-ad66-693f109bae45n%40googlegroups.com.

[Ruchita]

Sorry,  I deleted my previous email because there were some spelling mistakes. Now, I am writing same email with corrections. 

Thanks Dan.  I have attached Makefiles and flist_impl.vcs file to make things working.  I have hope now since it is tested on VU37P. I guess you are referring to this board: https://www.hitechglobal.com/Boards/UltraScale+_VU37P_HBM.htm  ? But this is a non zynq family, one has to communicate through UART or PCIe, I guess one has to modify  https://github.com/black-parrot-hdk/zynq-parrot/blob/master/cosim/v/bsg_zynq_pl_shell.sv for UART, in this case, there could be one master but I don't know how and corresponding ps.cpp should need to modify communicate with this shell. Can you please share me these files? Or VU37P supporting files? In case of PCIe, I guess one need not to modify bsg_zynq_pl_shell.sv, xdma IP can connect to multiple slaves.

I have implemented the design using PCIe and ran ps.cpp on the board, again it  is getting stuck at: "INFO:    ps.cpp: Starting BP i/o polling thread"
I then looked at critical warnings, please see attached Critical_Warnigs.txt file. Similar critical warnings I have seen for blackparrot-example for pynq z2 board. I am wondering, if blackparrot-example tested on pynqz2 board with these critical warnings, same should work for ML 507 board?

When I look at critical warnings, for example

The clock pin design_1_i/Hammerblade_0/inst/top_fpga_inst/hammerblade/mesh.manycore/py[0].px[0].btc/op_r_r_reg/C is not reached by a timing clock

I guess this warning is telling the clock used bsg_tag_i.clk is not proper, use clock from direct clock source, for example, it could be directly from clock wizard IP or from DRAM output clocks, etc. If I replace always_ff @(posedge bsg_tag_i.clk) in /home/lab/zynq-parrot/import/basejump_stl/bsg_tag/bsg_tag_client.sv with always_ff @(posedge recv_clk_i), at line numbers: 60, 97, 105, etc. then no critical warnings on this net.

I guess, if I follow similar approach for other nets, then there will be no critical warnings. I guess you might have got these kind of critical warnings for VU37P board, how did you solve it?

Regards,
-Ruchita.

[Ruchita]

Hello Dan,

Can you point why it is getting stuck at:   is getting stuck at: "INFO:    ps.cpp: Starting BP i/o polling thread" ?

Ruchita

[Dan Petrisko]

Hi Ruchita,

It could be any number of things. All that means is that the BP program is not running to completion.  You’ll have to look at the waveforms to debug. I would suggest tracing the BP config bus, memory ports and PC to start. 

If you have made any changes from the defaults, or are using different tools than are exercised in CI then it is likely those deltas.

Best,

-Dan

To view this discussion visit https://groups.google.com/d/msgid/black-parrot/f4bf62a5-fddc-401a-86bb-b78159689f1cn%40googlegroups.com.

[Ruchita]

Hello Dan,

I did try to insert ILA core for AXI transactions, especially for memory ports, top_zynq.sv, etc. I can see all the transactions happening in VCS when I use $display command but in ILA core I see only one or few AXI transactions. I then changed trigger conditions in ILA core to ==, =>, etc. and also increased sample depth but still I see only one or few AXI transactions. How did you overcome this problem?

Regards,

-Ruchita

[Ruchita]

Hi Dan,

Any suggestion how to overcome above ILA problem?

Regards,

-Ruchita 

[Dan Petrisko]

Hi Ruchita,

Here is a guide for debugging boot, intended for the simulation infrastructure but still relevant in this case: https://github.com/black-parrot/black-parrot/blob/master/docs/debug_boot.md

I'd suggest placing one or more of the probes described in the guide. Notably, the PC and configuration bus are most relevant. I would go step by step, find the first mismatched value and debug the root cause.

Best,

-Dan

To view this discussion visit https://groups.google.com/d/msgid/black-parrot/a7355c62-f217-442c-85e8-ac72d4f98b25n%40googlegroups.com.

[Ruchita]

Thanks Dan. I guess  the configuration bus you are referring to: https://github.com/black-parrot-hdk/zynq-parrot/blob/master/cosim/hammerblade-example/v/bp_common_pkg.sv ? By default the bus is configured to 'bp_unicore_hammerblade_cfg' If not please point .sv/v file 

Regards,

-Ruchita