03-01-2021 08:07 AM - edited 03-01-2021 08:12 AM
Trying an immediate trigger:
I believe there is a clock and running
After a trigger:
It should be halfway but it didn't trigger anything. Also this in the console:
ERROR: [Labtools 27-3428] Ila core [hw_ila_1] clock has stopped. Unable to arm ILA core.
Again, the clock comes from a PS block, there's nothing fancy with the clock.
Another proof that there is a clock is that I have a VIO where I can start some action and I see the result (inputs activity), so there is a clock.
Interestingly, yesterday this project was ILA-wise fine with some clock (12.5 MHz). Then I realized I needed some blocks to run faster so I added a 15 MHz clock and now it's completely screwed.
Also, yesterday's design is a rebuilt from scratch from another design that was causing trouble with ILA:
Unreliable ILA - Community Forums (xilinx.com)
Am I someone specially unlucky with system ILA or is it always that flaky?
03-01-2021 12:04 PM - edited 03-01-2021 12:07 PM
I've always had good luck with ILA / System ILA.
Sometimes there are issues with SoC debug and ILAs when loading the PL bitstream from Hardware Manager but not first configuring the PS. If you don't run the FSBL, which configures the PS system, it will not enable/configure the PS FCLK0/1/2/3 outputs properly.
If you are loading directly from Hardware Manager into the PL and not initializing the PS, I would use the following steps.
connect
targets
targets 3 (PL)
loadhw <filename>.xsa
fpga <dir_to_bit>/<filename>.bit
targets 8 (APU)
source psu_init.tcl
psu_init
psu_ps_pl_isolation_removal
psu_ps_pl_reset_config
targets 9 (A53-0)
rst -processor
Please note you don't have to perform these steps each time. You only need to perform these steps when powering on the SoC. If you power-down, you need to run these steps again otherwise you can just load the updated debug bitstreams via Hardware Manager because the FCLKs are already configured. OR, if you modify the PS system (i.e. FCLKs enabled, frequency, etc.) then you would need to run these steps again.
03-01-2021 01:15 PM
I'm suspecting the root of my problems is for having the PS as clock source but this b***dy board doesn't have any clock to the PL
03-02-2021 01:59 AM
I tried on a new computer, fresh windows, fresh install of Vivado 2020.2, recreated the design from sources (no script) and same (mis)behaviour.
03-02-2021 05:52 AM - edited 03-02-2021 06:04 AM
It seems to be fine now, the changes from the previous non-working (wrt ILA) designs are:
- I'm including pmu fw (originally just FSBL and bitstream, although I also tried FSBL + PMU fw + bitstream and failed as well)
- I have a dummy app that says hello every second.
- Instead of having all the 3 clocks I need from the PS, I have the PS clocking an MMCM.
Et voilà. Now that's the Vivado I like!
I can't mark this as a solution as I really don't know the reason and why any of the above fixed it, but this may help anyone facing similar problems.
03-04-2021 08:46 AM
What is your JTAG clock frequency? Please make sure the debug_hub in your design is operating atleast 2.5 times JTAG clock frequency. By default, debug_hub will pick one of your debug core (ILA / VIO) clocks. Based on teh debug_hub clock, set the JTAG clock while connecting to the board in HW manager.