search

OSVVM / AXI4

AXI4 Full, Lite, and AxiStream verification components. AXI4 Interface Master, Responder, and Memory verification components. AxiStream transmitter and receiver verification components
Other
129 stars 18 forks source link

Burst Boundary checking #5

Open stfarley opened 3 years ago

stfarley commented 3 years ago

Using the AXI4 Memory component I set up a test that starts a burst that crosses the 4k boundary. This did not cause any error. Is that a check that should be active?

JimLewis commented 3 years ago

The check has not been implemented yet.

It would be easy to generate an error when a 4 K boundary is crossed on a burst. I am assuming that it would be best if the memory still saves the data as that will facilitate debug.

Alternately, at one point, I started a AXI4 Monitor that is responsible for checking the AXI interface for issues. I am wondering if that would be better than adding the check to the Axi4Memory.

Can you tell me about your use model?

stfarley commented 3 years ago

Hi Jim,

I am developing an AXI4 master that is looking after burst management in hardware. It is not terribly complex so I can manage with what is there. I just tried one of the boundary bursts that was illegal to see if it would catch it.

I think your idea of doing it in a separate AXI Monitor makes sense. Then you can plop it in anywhere and check the bus.

Thanks Steve

On Jul 13, 2021, at 1:45 PM, Jim Lewis @.***> wrote:

The check has not been implemented yet.

It would be easy to generate an error when a 4 K boundary is crossed on a burst. I am assuming that it would be best if the memory still saves the data as that will facilitate debug.

Alternately, at one point, I started a AXI4 Monitor that is responsible for checking the AXI interface for issues. I am wondering if that would be better than adding the check to the Axi4Memory.

Can you tell me about your use model?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/OSVVM/AXI4/issues/5#issuecomment-879279823, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHSD5TJEBZDPXH5DHYE6NYDTXR3UXANCNFSM5AJN6L3A.

Paebbels commented 3 years ago

I think this check should be configurable. The boundary limitation is artificially done by ARM and has no technical reason for the bus itself. It makes sense for the CPUs load/store unit or connected memories and caches, but it should have been defined independently from the pure bus specification. (Like limiting data width power of 2 sizes. E.g. 24 bit AXI-stream for an RGB image stream is not valid AXI ...)

Anyhow, if 2 user defined components are developed independently from any CPU or similar, users might want to explicitly cross the 4k boundary.

I'm ok if the check is on by default to follow the AXI specification, but it should be possible to relax it.

JimLewis commented 2 years ago

It has been a while since this was posted, so I wanted to mention, this is on my todo list to address and will be in a future revision.

SkydiverTricky commented 2 years ago

It definitely needs an ON/OFF control set by the user. The Xilinx DDR mig allows bursts over the boundary, and even bursts large than 4k (their example design does an 8k burst!)

SkydiverTricky commented 2 years ago

Another note - I am pretty sure ARM used to provide the SVA for the AXI protocol assertions on their website, but I can no longer find it. The use guide for them is here: https://developer.arm.com/documentation/dui0534/b/?lang=en

Might it be worth adding PSL versions?

JimLewis commented 2 years ago

Either PSL or VHDL. I have had the intent of writing pure VHDL versions of them that report through the AlertLogPkg.