What do you mean by "built in"? All platforms in nmigen.vendor are abstract. nmigen_boards is a separate repository and nmigen cannot depend on it.

What do you mean by "built in"?

I think he means elaborate is passed a platform arg.

We've talked about this a few times in IRC, but I believe we both agree that it's "an open question" on how to use the platform input argument to elaborate to apply to the largest amount of boards in nmigen_boards at once without resorting to checking the current platform actually passed in and adding specific setup code for each supported platform within elaborate.

@RobertBaruch Look at blinky.py in nmigen_boards for an example of elaborate that's pretty portable to all supported boards with minimum platform dependence. Of course, a blinky is simple :P.

Here's what I ended up doing in order to (in the more general sense) get arguments added to the parser:

from nmigen.cli import main_parser, main_runner

...
if __name__ == "__main__":
    parser = main_parser()
    parser.add_argument("--cover", action="store_true")
    parser.add_argument("--bmc", action="store_true")
    parser.add_argument("--insn")
    # if I wanted a platform arg here, I'd add that too
    args = parser.parse_args()

    ...

    main_runner(parser, args, m)
    # main(m)

Sure. But I don't understand how would --platform work.

I could work around the lack of a --platform option like this:

from nmigen.cli import main_parser, main_runner

...
if __name__ == "__main__":
    parser = main_parser()
    parser.add_argument("--platform")
    args = parser.parse_args()

    ...

    main_runner(parser, args, m, platform=args.platform)
    # Cannot use 'main' because it doesn't support a --platform cli flag.
    # main(m)

Then I could just do something like python3 <file.py> --platform thing generate -t il > file.il

That's the intended use of main_parser and main_runner, yes. Is there any improvement you're suggesting to this API?

Ah, ok, it didn't look like those functions were intended to be exported, since they weren't in __all__. But yes, I propose adding --platform or -p to the generator parser, which will populate the platform kwarg in main.

In general, public names (those not starting with _) are end-user API and carry at least some degree of stability.

But yes, I propose adding --platform or -p to the generator parser, which will populate the platform kwarg in main.

What would that populate it with?

What would that populate it with?

You could use --platform xyz on the command line, and that would be the equivalent of running main with platform="xyz".

Sure. But using a string as a platform is atypical, and in the long run I expect virtually no nMigen code will use it (even though it'll remain permitted). For example, anything that uses lib.cdc and targets FPGAs likely needs the platform to be a class implementing specific methods that lower abstract CDC primitives to device-specific ones.

Using platform="formal" is really a bit of an aberration. There is no reason that using property testing and using vendor primitives (which can well come with Verilog models that include property assertions for their own invariants) is mutually exclusive. In the long run, this logic will become something like if platform.emit_assertions: m.d.comb += Assert(...).

The only reason platform="formal" exists in this form is because it predates all design work on the nMigen build/platform system. So baking in a command line argument whose sole purpose is to do something deprecated isn't a good idea.

Makes sense. I didn't realize platform wasn't just a string.