amaranth.cli.main_runner : specify callbacks to setup verification and/or simulation

[sporniket]

I am new to amaranth and follows the tutorials and video of @RobertBaruch. Now I am starting to use main_runner to have formal verification and simulation, and I realize that there is no mechanism to setup either action (assert/cover/... for verification ; process, clocks,... for simulation) when appropriate.

I would add 2 named parameters to main_runner that are called back according to the situation :

def main_runner(..., prepareVerification=None, prepareSimulation=None):
    if args.action == "generate":
        if not prepareVerification is None:
            prepareVerification(design)
        # perform generation as usual

    if args.action == "simulate":
        # prepare sim as usual
        if not prepareSimulation is None:
            prepareSimulation(sim, design)
        # with sim.write_vcd( etc...)

Then, a typical main for a module would be like :

if __name__ == "__main__":
    # Prepare
    parser = main_parser()
    args = parser.parse_args()

    # declare globals
    #...

    def myVerification(m):
        # add asserts, covers, etc...

    def mySimulation(sim, m):
        # complete simulator setup

        def process():
            # do stuff

        sim.add_sync_process(process)

    # Execute
    main_runner(parser, args, MyModule(...), ports=..., prepareVerification=myVerification, prepareSimulation=mySimulation)

edit: typos

[sporniket]

For the record, one can see how it looks like with real code : https://github.com/sporniket/amaranth_sandbox/tree/main/02_cell_of_tagged_value :

• the modified runner in cli_sporny.py : https://github.com/sporniket/amaranth_sandbox/blob/main/02_cell_of_tagged_value/cli_sporny.py
• in use : https://github.com/sporniket/amaranth_sandbox/blob/main/02_cell_of_tagged_value/CellOfTaggedValue.py

[ghost]

The current CLI functionality in Amaranth is not a particularly well designed API. It only provides the bare minimum functionality for the simplest of example programs at the moment. If it continues to be part of Amaranth, it will need major design changes. Given these upcoming changes, I don't think patching the current approach is appropriate. Another thing to look at would be #586, which proposes one of the features you've also proposed here. I think both issues should likely be superseded by a separate, more general pre-RFC discussing the CLI features that might fit people's interests and the goals of Amaranth itself.

For your use I recommend reimplementing the functionality you're currently getting from the cli module in your own application logic. This will give you more control and be less beholden to the changes to the CLI interface changes that eventually do happen.

[sporniket]

No problem, I am fairly new at this, so I proposed what worked for me while leveraging existing code.

Now it's true that thinking deeper, the number of callback/hooks would becomes overwhelming (and the proper naming, too, is to be thought out), so a better mechanism is to be established. I am used to Junit (Java language), so I would be biased toward a decorator based mechanism to hook code.

[sporniket]

So, I believe that this issue is already covered by #586 (previously mentionned by @MidnightSkylight ) and #487.