[bsg_cache] fix track_mem_data_r X when word_tracking_p = 0

bespoke-silicon-group / basejump_stl

BaseJump STL: A Standard Template Library for SystemVerilog

http://bjump.org/

Other

504 stars 97 forks source link

[bsg_cache] fix track_mem_data_r X when word_tracking_p = 0 #604

Closed tommydcjung closed 1 year ago

tommydcjung commented 1 year ago

basically, when word_tracking_p = 0, track_data_we_i will always be zero in bsg_cache_dma. This means that track_mem_data_r will always be 'X. Then data_mem_v_o will also become X, and so will tl_ready at the top.
added word_tracking_p switch to regression_v2
Added asserting to check if ready_o or v_o ever goes X in testbench, because the testbench didn't fail even when there was x.

dpetrisko commented 1 year ago

Can we hardcode track_mem_data_r to zero instead of not using its output? Having Xs hanging around seems dangerous in sim even though synthesis will (probably) optimize it out correctly
When word_tracking_p == 1, is track_data_we_i guaranteed to be raised before track_mem_data_r is used?

tommydcjung commented 1 year ago

Can we hardcode track_mem_data_r to zero instead of not using its output? Having Xs hanging around seems dangerous in sim even though synthesis will (probably) optimize it out correctly

I thought about doing that but then we are just hoping that the synthesis tool will do the right thing. as long as track_mem_data_r is not being used, it's safe? I'm fine with either way.

tommydcjung commented 1 year ago

When word_tracking_p == 1, is track_data_we_i guaranteed to be raised before track_mem_data_r is used?

It has to be, otherwise it will show up as a bug

tommydcjung commented 1 year ago

a part of reason why this bug got through is that even if we could replicate the bug in the regression, the testbench could not detect it. So that part has been fixed by adding assertion to check for X