Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFC] add pre-run simulation hook for cli.main #586

github-4o opened this issue Feb 1, 2021 · 2 comments

[RFC] add pre-run simulation hook for cli.main #586

github-4o opened this issue Feb 1, 2021 · 2 comments


Copy link

as far as i can tell, current simulation cli-based workflow for a module is the following:

main(m, ...)

which gives control to
which sets up the simulation environment
this (again as far as could see) implies that one needs to have a separate python module that is to be invoked for simulation of
codegen for a is invoked as generate ..., while
sim for is invoked as simulate ...

suggested solution: pre-run simulation hook defined in, invoked by simulate option in cli.main

  • pros: unified cli interface for both simulation and codegenration via the cli arguments
  • cons: module code bloating as a module will have both hdl-relaed code and testbench-related code in a single file. this may be a problem as testbench code tends to be times larger then uut
Copy link

For me, the fact that a single files contains all (code + test) was, among other things, a plus when exploring alternatives to VHDL/Verilog. However it is true that I am at a stage where codesize is very modest.

For the little bits of code I could write, coverage and simulation code seems to require setting up a top module. One could imagine to write a Test/Simulation/Whatever Suite that would look like (disclaimer, heavily inspired by JUnit) :

# imports
from ...

class mySuiteOfStuff:

    def shouldVerifyThis(context:VerificationContext): # at least a top module to setup assert/covers etc...
        # update the context

    def shouldVerifyThat(c:VerificationContext): # for more concise writing ; and one can have disjointed sets of verifications
        # update the context
        # of course, a new context is regenerated between each call

    def simulateThisCase(context:SimulationContext): # at least a simulator instance and a Module to setup
        # update the context

    def simulateThatCase(c: SimulationContext): # again, several simulation can be defined
        # update the context

    def setupGlobalVerification(...): # did I say that I am heavily inspired by JUnit ?
        # return something ? or update a provided context ?

    def setupOneVerification(...): # remainder the function name is free, the decorator is there to spot the function of interest
        # return something ? or update a provided context ?

    def tearDownOneVerification(...) : #....

    def tearDownAllVerifications(...) : #...
        # etc...

    # And the same for simulation, but it's so long
    # @{Before|After}{All|Each}Simulation

### Launcher ###
if __name__ == "__main__":
    main(..., suite=mySuiteOfStuff)

Copy link

We have a more formal RFC process these days and this proposal would have to go through it to be accepted. In general, CLI improvements are desirable; I have a prototype for a new CLI in #904.

@whitequark whitequark closed this as not planned Won't fix, can't repro, duplicate, stale Feb 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

No branches or pull requests

3 participants