search

betrusted-io / betrusted-soc

Betrusted main SoC design
Other
136 stars 21 forks source link

Page read burst length is shorter than expected #3

Closed bunnie closed 3 years ago

bunnie commented 4 years ago

See commit 935f3a06c20ed514e145fc099af9f881b5e24136

Page read burst length should be 16 according to the datasheet, but we're only getting stable operation with a length of 4 in practice.

Marking as enhancement because the system works with length 4, but we are missing some potential cache read performance by having it shorter than a cache line length.

bunnie commented 3 years ago

Updating with an observation -- as we start to run harder workloads, it seems page reads are really unreliable. We've had to tune page read timing to be basically identical to standard read timings in order for them to work.

Attempts were made to contact the vendor for more support on the issue, but no response was received.

bunnie commented 3 years ago

this got fixed with the migration to the L2 cache integrated in the SRAM driver. It seems quite solid now that we have full control over the access patterns, and that they are very regular because the L2 cache only ever initiates aligned, multi-beat fills.

I suspect the problem was ultimately that there were some CPU access patterns that would break the page detection algorithm in the original implementation, and the testbench was insufficient to detect them. Which is why we saw some dependency on the type of code and compiler impacting the effective burst length we could achieve.