Support default "tool" and "flow" flags when using flow API

[mxsparks]

Fixes an issue where the default tool_TOOLNAME flags were never being set if not using the tool API. Also adds a default flow_FLOWNAME flag.

Passes ruff and tox (no new unit tests added).

[tymonx]

This could be simplify:

Suggested change

	except SyntaxError as e:
	logger.error(str(e))
	exit(1)
	except RuntimeError as e:
	logger.error(str(e))
	exit(1)
	except (SyntaxError, RuntimeError) as e:
	logger.error(str(e))
	exit(1)

[tymonx]

How about setting the tool flag based on the flow if the tool is not present 🤔 For example, vivado flow (because it is using the Vivado tool):

Suggested change

	if flow_options and "tool" in flow_options and "tool" not in flags:
	flags["tool"] = flow_options["tool"]
	if "tool" not in flags:
	flags["tool"] = flow_options["tool"] if flow_options and "tool" in flow_options else flow

[olofk]

This is actually by design. The tool_TOOLNAME flags don't make sense for the flow API as there can be flows using multiple tools. The intention is to deprecate the --tool switch completely once we have migrated away from the tool API. It's a bit inconvenient when using a mix of tool and flow backends, but can be mitigated by passing --flag=tool_TOOLNAME on the command-line and/or setting flags: {tool: TOOLNAME} in the targets.

Adding an implicit flow_FLOWNAME flag could still be considered, but I would argue that it is better to set an explicit flag in the relevant targets to convey the intention more clearly. e.g. instead of checking that the flow is sim, the actual thing we want to do is to use a simulation model or decrease some reset timer. Perhaps we also want to use the shortened reset timer in a formal flow, or do some simulations without the simulation model. That also helps with reuse, when the core files are perhaps used in a new flow that the original author didn't consider.

[tymonx]

The intention is to deprecate the --tool switch completely

@olofk But there is also the --tool switch after the core name that is part of the Flow API. If you look into proposed changes:

if flow_options and "tool" in flow_options and "tool" not in flags:
    flags["tool"] = flow_options["tool"]

It is using the --tool argument from the Flow API not from the Tool API. There is something like sim flow that can have different tools like xcelium, xsim or ghdl. Having something that will automatically set the tool flag is handy for the Flow API as well because for example you could include/exclude Xilinx unisim libraries:

files:
  unisim:
    depend:
      - xilinx:unisim:vcomponents

targets:
  default:
    filesets:
      - '!tool_vivado ? (!tool_xsim ? (unisim))'
    flow: sim
    flow_options:
      tool: xcelium

In case of Xilinx unisim libraries, you want to include them in all HDL simulators except the Xilinx XSim simulator or Vivado implementation tool.

Then user can select simulator in the sim Flow API with correct filesets:

fusesoc run --target sim <vlnv> --tool=<xsim|xcelium|ghdl|...>

I have similar changes like @mxsparks is proposing in my forked version of FuseSoC. Otherwise handling simulation libraries when using the sim Flow API will be nightmare. Xilinx/AMD Vivado/Xsim doesn't like providing unisim or xpm libraries explicitly but this is required when using other simulators.

[mxsparks]

Otherwise handling simulation libraries when using the sim Flow API will be nightmare.

Agreed. We currently have a mix of tool and flow API usage, and the current behavior requires me to revisit every flow-API target in several hundred dependent cores and add a redundant flags: {tool: TOOLNAME} key when the flow_options: {tool: TOOLNAME} key is already present.