Edalize (Slight return)
Living planning and design document for Edalize Slight return. Main goal is to increase flexibility and allow for use cases that are hard to implement with the current design.
Today, Edalize is based on backends or tools, with some confusion regarding the terminology. Some backends can be set up to work in different modes (e.g. verilator used in C++, SystemC and lint modes). Other backends are built up from parts that can be switched out to equivalent functionality (e.g. icestorm which can use ArachnePnR or NextPNR, or several other FPGA-vendor-powered backends that can potentially use yosys for synthesis). This works mostly fine for the existing flows but there are several cases where this is not ideal.
This typically requires running most of an FPGA (or ASIC) flow, export the result to RTL and then run a simulator. This is not easy to achieve today without duplicating functionality. Timing simulations is similar (are these the same thing, really? Can someone clarify?)
The VUnit support sets the stage for VUnit and uses the VUnit tool interfacing code instead of the support in Edalize. The situation for Cocotb is simuilar.
Instead of tool-specific backends, ESR will be based around flows which are graphs built up from stages (nodes)
Each stage will pass files and an EDAM file between them. By having all stages input and output EDAM files we can easily combine them in different ways.
Edalize will still consist of three major stages, configure (setup?), build and run. configure creates all project files and creates the graph. Build executes all the build stages. The run stage is for final tasks that make sense to run several times even though though the source files are unchanged. E.g. running several simulations runs without rebuilding the simulation model, or reprogram an FPGA multiple times with the same FPGA image. As a counter-example, e.g. synthesis does not fit into this category as it should produce identical result given the same input.
At configure time, the flow graph is set up and the flow configuration and tool settings are applied to each stage to generate the necessary tool project/config files. A ninja (tbd) file is created to describe the dependencies between the stages.
The build phase should only execute ninja (or similar) to run the graph to completion
The run phase needs to be better defined. It has runtime parameters
A node in the graph gets a EDAM file as an input, which in turn describe what the node should do. After completion it creates a new EDAM file describing the files it has created that are relevant for another stage.
A questasim node gets Verilog/VHDL/tcl files as input. It creates a compiled simulation model (but no EDAM files since there is no stage following?)
A yosys node takes Verilog/VHDL/tcl as input. It is configured by Edalize to produce an edf file. Upon completion an EDAM file is also created.
A quartus node is set up to only do P&R. It reads an EDF for input (as described in the EDAM file) and produced a SOF file (but no EDAM??)
A vivado node is set up to create a post P&R netlist. It accepts Verilog/VHDL/XDC/TCL... as input and produces a verilog file + EDAM
A migen node takes python as input and produces verilog + constraints
Flows are based on intent, such as creating an FPGA image, running simulations or perform linting. Most flows can be accomplished with different combinations of tools, but some are more specific. It shall be possible to create custom flows for specialized needs.
Some standard flows.
Flow config: synthesis tool, P&R tool, backend tool (i.e. for FPGA image generation) Input: RTL source, constraints, tcl, etc Output: An FPGA image
Flow config: simulator Input: RTL source, tcl, etc Output: A simulation model
Flow config: synthesis tool, P&R tool, simulator Input: RTL source, tcl, etc Output: A simulation model
Flow config: synthesis tool Input: RTL source, tcl, etc Output: A netlist
Runs a linter. Flow config: linter tool Input: RTL source, linter config/waiver files Output: Nothing (a result file/status message)
If the flow is not defined in the EDAM file, choose the appropriate flow from the tool name. Does this work in all cases? Probably yes, but not sure for e.g. verilator that could be both a lint and a simulation flow
FuseSoC sets the flow name from the target name by default. This allows to e.g. create lint, synth or sim targets and have them do the expected thing. Might need a new flow_options key in the targets