Tidy up DSE/Quartus interface

Following on from this PR comment I’m starting this discussion to find the best way forward:

Desire: Remove all DSE specific options and replace with one core file parameter such as dse_options.

Options: The data provided by dse_options is written directly to a DSE file which is generated on-the-fly. E.g.

targets:
  build:
    default_tool: quartus
    filesets: [stuff]
    tools:
      quartus:
        device: abc
        family: xyz
        dse_options:
          - 'seeds="1,2,3"'
          - 'num_concurrent=4'
          - 'num_parallel_processors=0'

Would produce a .dse file with the contents:

# Auto generated by Edalize
seeds="1,2,3"
num_concurrent=4
num_parallel_processors=0

Another option might be native support a dse file type.

E.g.

filesets:
  synth:
    files:
      - /path/to/dse/file {file_type: dse}

The file would be supplied as-required by DSE. This option will probably require some resolution logic to determine what to do if zero or more than one .dse files are provided.

There are probably other options. Would be grateful for thoughts and opinions.

[olofk]

I think we can all agree that it would have been so much easier if Intel/Altera could provide a reasonable interface 😃

Files and options have both pros and cons

• A DSE file type: If I understand correctly, this is what quartus_dse actually consumes. For that reason I’d say it’s the most transparent option. It does make slightly more inconvenient to change options between runs though. Is that something people need? I’m not a user myself. As for handling len(dse_files) != 1, we could concatenate in the backend or error out. The icestorm backend does the latter for pcf files but I’ve considered changing to do the former. Concatenating might provide an extra service if several targets want to reuse most of the dse files but change some detail of it.

• dse_options: I might actually have dropped support for dicts as I realized none of the backends actually used it. Could still be there though. Not sure tbh. In any case I’d be more keen on a list since that has better defined behaviour, like items added on the command line (e.g. fusesoc run core --dse_options=“option3 option4=something”) would be appended to the options coming from the tools option of the core files.

So from my perspective I’m fine with either solution and would prefer to leave it up to you as useres to decide on whether (one or multiple) dse files or a list of dse_options would be the preferred solution. If you can’t agree on something I will rule with my gentle iron fist 😉

[olofk]

Closing this now as I believe it’s all done. Reopen if needed