Closed Yuan-Mao closed 1 year ago
oh that's awesome! My guess is yeah, there's an outstanding axi transaction that gets interrupted when you do the BP reset. We probably need a way to fence so that all transactions complete before the reset set
PS.cc does not assert PL reset; only bitstream reloading does that. But most likely when PS quits, BP is stalled waiting on I/O (as we have said should be fixed) and then PS restarts and reads from BP, and a deadlock is caused…
M
On Thu, Jan 13, 2022 at 12:42 AM Dan Petrisko @.***> wrote:
oh that's awesome! My guess is yeah, there's an outstanding axi transaction that gets interrupted when you do the BP reset. We probably need a way to fence so that all transactions complete before the reset set
— Reply to this email directly, view it on GitHub https://github.com/black-parrot-hdk/zynq-parrot/issues/20#issuecomment-1011917110, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEFG5AGX3KVPWU3XKBREBQDUV2F7NANCNFSM5L3EDHVA . You are receiving this because you are subscribed to this thread.Message ID: @.***>
Reset (of BP, not the whole PL) is done by the ps.cpp: https://github.com/black-parrot-hdk/zynq-parrot/blob/master/cosim/black-parrot-example/v/top_zynq.sv#L510.
I think this is an issue regardless of blocking / non-blocking. Since BP is now doing AXI transactions, a reset can interrupt it and leave the state in a partially completed way
Yeah I don't expect a BP only reset to work.
M
On Thu, Jan 13, 2022 at 7:49 AM Dan Petrisko @.***> wrote:
Reset (of BP, not the whole PL) is done by the ps.cpp: https://github.com/black-parrot-hdk/zynq-parrot/blob/master/cosim/black-parrot-example/v/top_zynq.sv#L510 .
I think this is an issue regardless of blocking / non-blocking. Since BP is now doing AXI transactions, a reset can interrupt it and leave the state in a partially completed way
— Reply to this email directly, view it on GitHub https://github.com/black-parrot-hdk/zynq-parrot/issues/20#issuecomment-1012261903, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEFG5AAGVAGT4KG2PQZRG63UV3X7XANCNFSM5L3EDHVA . You are receiving this because you commented.Message ID: @.***>
I think resetting the whole PL should work though? Because the ps.cpp will be able to fence any outstanding transactions before triggering the reset? And any outstanding BP requests will get killed and restarted?
IIRC we used this feature in the regression to run full SPEC without reprogramming between benchmarks
Closing as unsupported; enterprising users could implement a BP-only reset by fencing and sequencing
So continue with my debug adventure -- I am still using add35a1.
Now I can run opensbi v1.0 + Linux kernel 5.15 on FPGA, but then I find I cannot launch ps.cpp more than once if I do not re-loading the bitstream. Not quite sure if this is something we expect.
I guess it is because when we re-run ps.cpp, only the reset for BP gets triggered. Other resets like for AXIs are only triggered during the bitstream loading.
From the below screenshot, we can see the first run on the top went well, but the second run below got stuck.