SWERV CPU doesn't work properly if memory interface HREADY signal is high by default

chipsalliance / Cores-VeeR-EH1

VeeR EH1 core

Apache License 2.0

808 stars 219 forks source link

SWERV CPU doesn't work properly if memory interface HREADY signal is high by default #46

Closed vit82 closed 4 years ago

vit82 commented 4 years ago

SWERV CPU doesn't work properly if memory interface HREADY signal (highlighted on the waveform) is high by default:

If HREADY is low as shown below, the CPU work fine.

vit82 commented 4 years ago

In this case HREADY comes from the memory where proram executable code locates (ROM). In my opinion according to AMBA standard HREADY is permitted to be high by default. Please, comment.

aprnath commented 4 years ago

Hi, Please clarify a few things in your report for us:

What are the two waveforms provided? Is the 2nd one the "working" case, and the 1st one the failing case?
Are both cases using the same slave IP?
We would like to understand how the master and slave are connected. Is there a bridge or interconnect logic between them? A diagram or tb_top verilg would be useful.
In the failing case we don't see hrdata @rvtop being drive the cycle after transaction starts and hready is still high. If hready is high, the DUT expects data that cycle.

Thanks

agrobman commented 4 years ago

If the 1st diagram is your failing case, seems that your slave drives zero data for the CPU request of 0x80000000 -( the hready is asserted for next clock after HTRANS=2) if your slave needs more time it should drop hready right after transaction start .

vit82 commented 4 years ago

Thank you. Indeed between SWERV CPU and ROM, there's AHB switch fabric which doesn't work fine with AHB-lite provided by SWERV CPU. That was the main root cause of the problems.