Tidy up DSE/Quartus interface about edalize HOT 13 CLOSED

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 ;)

from edalize.

Would it make more sense for dse_options to be a dict rather than a list of strings? At the FuseSoC YAML level:

dse_options:
    - seeds: [1, 2, 3]
    - num_concurrent: 4
    - num_parallel_processors: 4

I don't think any Edalize backends use the dict argument type (just member and list) but it does exist.

I don't have an opinion on whether a DSE file type would be a cleaner solution. I would think not since as you mention other than one file doesn't make sense. It also doesn't apply for to other tools, though we do have tool-specific things like QIP, XCF, etc.

On a related note, Xilinx and Vivado now have a pnr option that's effectively a faint reflection of the vendor flow steps. DSE has overloaded this, and my first thought for #115 was to add netlist and power values. Of course, Quartus can run simulators and Vivado has a built in simulator, so if we wanted to support them the obvious next step would be to add a pnr value of simulation which seems a little off.

Is there a better way we should be describing how far to run the tool flow, hopefully in a tool-independent manner? I wonder if this might also help with something cleaner than top-level options for very specific tool flows like dse_options. Perhaps

flow: dse
    options:
        - seeds: [1, 2, 3]
        - num_concurrent: 4
        - num_parallel_processors: 4

Some of the programming options might fit this style as well, though this conflicts a bit with the existing run=program model for this type of tool

flow: program
    options:
        - cable: "something"
        - board_device_index: "board_index"

It might be nice to be able to set DSE-type options from the FuseSoC command line, though I have no idea how this would work with a more complex structure like above. For example

fusesoc run --target=dse my_core --seeds="1, 2, 3"

from edalize.

Some very interesting comments, thank you, especially the idea of defining flows for each tool. As a relative newcomer to FuseSoC/Edalize I don't feel well enough informed to pass strong comments on what sounds like a possibly substantial change. It sounds like the suggestion is to give FuseSoC/Edalize more knowledge of the various tools to drive some of their more niche capabilities. I'd be interested to know if this is an aspiration of the project or would it come with too much overhead? There are a lot of different sub-tools within Quartus for example. Is it the intention for FuseSoC to interface to some/all of them in future (e.g. timing analyser) or just focus on a narrow set of capabilities?

My interpretation from the comments on my earlier PR I assumed that the desire was to make FuseSoC/Edalize less aware of the sub-tools within Quartus (in this case DSE). This was one reason for suggesting a list of strings rather than a dict as Edalize doesn't need to do anything other than write contents from the core file to a new DSE file. If a dict was used there may be a need for Edalize to know something about that interface, for example if there are syntax quirks that mean it's not possible to do a straight conversion from key:value pair to string.

IIRC I think Vivado had the pnr option first and it was suggested to me that I copy that example for Quartus. When support for DSE was added I was initially surprised to see DSE specified using the pnr option but the more I thought about it the more it seemed to make sense. pnr originally took the options None and quartus, which seems to be specifying which PAR engine to use or none. DSE is another method to invoke PAR for Intel, so feels like a natural extension to this option. Had the original values to pnr been True and False instead, this would have made less sense.

from edalize.

The comments about the pnr option being used as a reflection of the flow steps is probably correct, but interestingly not something I'd considered. I'd always seen it more restrictively as the place and route tool to use, where DSE is just a parallel placer and router. As you say, though, it does just affect the design flow, and could be used for things that don't actually place or route at all.

I think the big problem with DSE as it stands is that the format of the configuration file is really opaque - it doesn't seem to be well documented at all, with documentation from Altera/Intel suggesting using the GUI to create one (apart from some very old documentation that allowed it to be configured with TCL from when it was another Quartus module). So any of the approaches here are subject to knowing what exactly to put in - a use case for exploring timing based on seeds would probably require a very different set of values in the file to one exploring power based on generics, for example.

I like the idea of being able to provide options on the command line, but the fact that you'd need to know exactly what needs changing for a given target makes this really difficult to implement and keep things generalised enough to make DSE useful to explore different areas. In fact, no solution seems to be particularly good for this! However, your idea of the flow section does look like it could be quite neat. Defaults could be set up in this structure for everything we know about so far, and just changed in here to suite a particular core, or a particular investigation.

from edalize.

And regarding an extended interpretation of the pnr argument, I have some more long-term ideas on how to support more esoteric flows a bit easier. The general rule for FuseSoC+Edalize is to make 90% of the cases butter smooth, 9% hard but possible and let users handle the last 1% by themselves by either skip using FuseSoC, Edalize or both (I just made up those numbers, but still)

from edalize.

Thanks for you input.

I think I'm in favour of a solution that uses dse_options rather than supporting the DSE file type.

I'll wait for a bit before posting some changes so others have an opportunity to declare their preferences.

from edalize.

I'm not a DSE user, so I'm happy for you to go with your preference there. I was mainly chiming in as I'm in the same boat with overloading pnr and niche tool options.

from edalize.

Note that my YAML above is totally wrong. The following actually parses for a dict example:

flow: dse
options:
    seeds: [1, 2, 3]
    num_concurrent: 4
    num_parallel_processors: 4

However, as @olofk pointed out above, it doesn't look like FuseSoC passes dict options through to Edalize. A quick look at git blame seems to indicate it was never supported at least for CAPI2 rather than it being removed. So, your list of strings suggestion for dse_options seems to be the only thing that will work without FuseSoC changes to (re)add support for dicts.

from edalize.

I was having another think about this. Initially, I thought the DSE file type idea would be great, as if you're going to be building a big project and want to use DSE with it, you're probably going to want a set of options for DSE to be used in multiple core files. By having a DSE file type, you'd be able to have a core that provides your project options, and just depend on that somewhere in your design and it'd sort everything out for you. This would avoid having to replicate the options you wanted in all the cores you might want to use DSE with.

Then I thought a bit more, and realised that it is probably only going to be something that's really needed for "structural" cores that bring together subcomponents into a system that you're likely to want DSE with properly. As such, the level of duplication is likely to be fairly low: anything smaller will probably not care too much. Or, if you do want to automate DSE, say for a CI system, having options you could specify on the command line would allow you to pass them from whatever is automating the builds, so no problem.

The more I thought about that, the more it seems sensible to have them as a series of options. Place the defaults in your top level core files, but let them be overridden on the command line for automation purposes — that probably provides the most flexibility. What do people think?

from edalize.

It sounds like we've decided on an option list.

Two things to note

1. List options are additive. This means that you can set some options in a dependency (e g. a common core that only has some dse options you want to reuse) and these will all ve appended with options from the top level core at the end of the list. Further options set on the command line will be appended here
2. As all options are appended, setting an option on e.g. the command line will not override the same option specified in the core file. This is all just a list of strings and opaque to FuseSoC/EDAM. However, there's nothing stopping the backend itself that consumes the dse_options to filter out and remove duplicates from this list before sending it to quartus_dse

from edalize.

Thanks all for the above comments. I will attempt to enact this tidy up soon. :)

from edalize.

Looks like we have this covered now

from edalize.

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

from edalize.