Add more tests for MemBlock and _MemIndexed

[gaborszita]

Classes MemBlock and _MemIndexed are now fully covered by tests, except one exception that I don't think can happen (see #460)

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 91.9%. Comparing base (5077c24) to head (43453ef).
Report is 9 commits behind head on development.

Additional details and impacted files

@@              Coverage Diff              @@
##           development    #461     +/-   ##
=============================================
+ Coverage         91.7%   91.9%   +0.3%     
=============================================
  Files               24      24             
  Lines             6403    6413     +10     
=============================================
+ Hits              5866    5888     +22     
+ Misses             537     525     -12     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[fdxmw]

Thank you for improving these tests! I have some minor comments

[fdxmw]

Lines like these are a little easier to read with keyword arguments (pyrtl.MemBlock(bitwidth=-1, addrwidth=1)) as the reader may not remember whether bitwidth or addrwidth comes first.

If you agree and want to change this, please change it consistently throughout this commit

[fdxmw]

typo: bidwidth :)

[fdxmw]

The name mem_in is confusing in this commit as it's sometimes the address, and sometimes the data to write. Seems clearer to always call the address mem_addr?

[fdxmw]

Maybe call this greater_than instead of more_than ?

Regardless, the word choice here should be consistent with the next test (more vs larger)

[gaborszita]

I changed the name to test_memindex_bitwidth_greater_than_addrwidth, but I left test_memblock_write_data_larger_than_memory_bitwidth as it is because I think when we talk about numbers it is better to say greater and less and when we talk about data it is better to say larger and smaller. But I can change it if you disagree.

[fdxmw]

Creating a SimulationTrace shouldn't be needed here since Simulation should create a SimulationTrace for you if none is provided (happens again in the next two tests)

[fdxmw]

Doesn't seem like we gain much by testing both addresses? Consider just checking the first address as loops like these make it harder to debug the test. When a test failure occurs, we won't know the values of i or j

[fdxmw]

Similarly, it's a little better to reassemble the inspected binary value, and then do one big assertEqual, rather than doing one assertEqual for each bit in the loop. With one big assertEqual, the test failure error message will be better, since we can more easily see which bits are wrong. With the single-bit assertEqual, the error message will just tell us that 0 is not equal to 1 or vice versa.

You can reassemble the inspected values with something like:

>>> def reassemble_bits(bits: list[int]):
...     value = 0
...     for bit in bits:
...         value = (value << 1) | bit
...     return value
>>> reassemble_bits([0, 0])
0
>>> reassemble_bits([0, 1])
1
>>> reassemble_bits([1, 0])
2
>>> reassemble_bits([1, 1])
3

If you want to keep things the way they are, consider moving this logic to check if the Nth bit is set to a helper function, as it's a bit complicated and it's repeated in the next two tests.

Also you can check this a little more easily with bitmasks and bitwise AND, something like

>>> def check_nth_bit(value: int, n: int):
...     return bool(value & (1 << n))
>>> for n in range(8):
...     print(n, check_nth_bit(27, n))
...
0 True
1 True
2 False
3 True
4 True
5 False
6 False
7 False