PyMTL4.0 Release #264
Open
PyMTL4.0 Release #264
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Adding __len__ interface
The pytest_cmdline_preparse hook is now deprecated. I think there should be a way to achieve the same effect using pytest_load_initial_conftests https://docs.pytest.org/en/7.1.x/reference/reference.html#pytest.hookspec.pytest_cmdline_preparse However, were were using this to hook to prevent *.pyc and __pycache__ files from being generated. I think it is fine for now to just go back to generating these files.
Improve index handling in Bits and Signal classes
We were using this in our generated Verilog test bench: always #(`CYCLE_TIME/2) clk = ~clk; But if CYCLE_TIME is an odd integer (say 9) this would result in integer division and round down (i.e., with a cycle time of 9 we would end up with a clock period of 8!). This doesn't matter unless we are doing back- annotated gate-level simulation _and_ we use an odd integer clock period which is why we never detected this bug before. The fix is to simply force floating point division. always #((`CYCLE_TIME*1.0)/2) clk = ~clk;
We were seeing a bug where if you ran a bunch of tests with --dump-vcd PyMTL3 would only dump the VCD for the first test, although every once and a while it would indeed dump VCD files for the every test. This seems to have something to do with the shared library. The cleanest fix seems to be to avoid hard coding the VCD file name in the generated PyMTL wrapper and instead to dynamically get the VCD file name from the metadata.
PyMTL3 was generating an incorrect VCD format that just happened to work with GTKWave. The old version would output nets as: b0b0 ! b0b0001 $ So every net had an extra b0 at the beginning. In addition, single-bit nets should be represented by either 0 or 1 and then the symbol with no space. This pull request fixes this issue so that PyMTL3 now outputs: 0! b0001 $
We had to do this kind of craziness to avoid Verilator segfault:
try:
t( 0x00, '?' )
t( 0x13, 0x01 )
t( 0x27, 0x14 )
t( 0x00, 0x28 )
t( 0x00, 0x01 )
t( 0x00, 0x01 )
finally:
model.finalize()
And we saw segfaults when we tried instantiating the same Verilog
module twice and then using PyMTL for the composition. Peitian
dug into this and provided a fix.
Peitian writes: "This is a change to the C wrapper such that we don't
always create a new VerilatedContext everytime we need to create a new
instance of the model; instead, this change uses a globally shared
VerilatedContext guarded by a reference counter. Based on what I saw I
think we were not managing contexts correctly... This specific segfault
only seems to happen when two instances of the same model are finalized
back to back."
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR includes changes that will be part of the PyMTL 4.0 release. Here is a list of changes included in this PR (WIP):
xdistmodule