Verilog Generation

[rdaly525]

• [x] Replace verilog backend with verilogAST
• [x] Replace metadata["verilog"] with concrete verilogAST definition
• [ ] Replace verilog definitions of coreir/corebit with verilogAST
• [ ] Linking unparameterized verilog files
• [ ] Linking parameterized verilog files

Updated Verilog goals

• [ ] Overly verbose names for modules, ports, instances.

  • [ ] Change default generated names to use verilog escape syntax (\any-non-whitespace-is-valid)
  • [ ] Pass to simplify module/instance names
  • [ ] Allow passing packed multi-dimensional arrays in verilog ports
  • [ ] Translate bi-directional Record-based ‘ports’ to System Verilog interfaces
  • [ ] Update verilog-AST to support ast for SV interfaces

• [ ] Unneeded wires like those connecting module ports to instance ports.

  • [ ] Deduplicate wires in the port list (verilog-AST)

• [ ] Cleaning up/simplifying coreir libraries

  • [ ] Change default way passes are applied to modules (coreir:update_json)
  • [ ] Change default way to decide which modules should get serialized (coreir:update_json)

• [ ] Tech-specific implementations and passes

  • [ ] Define a clock-gated register (with appropriate verilog implementation) and a pass that fuses mux + coreir.reg into the clock-gated register
  • [ ] Inline leaf verilog modules (coreir primitives) from Verilog-AST
  • [ ] CoreIR pass(es) to consolidate combinational paths.
  • [ ] CoreIR pass(es) to translate series of muxes into verilog case statements.
  • [x] Change verilog implementations of primitives to Verilog-AST instead of strings.
  • [ ] Use a parser to store verilog strings as Verilog-AST

• [ ] Debugging symbol table

  • [ ] Maintain a symbol table that records original source file/line
  • [ ] Define a consistent way to update symbol table based off of arbitrary circuit transformations
  • [ ] Integrate with fault

[leonardt]

Non-essential goal:

• [ ] automatic style formatting for verilog output or at least wrap long lines (ideally there's an existing tool we can use for this)

[rdaly525]

Pasting related email here:

So far I have seen the following issues regarding using magma/mantle/coreir to generate verilog -Long verilator times (both parsing, and simulating) -Extra unneeded wires -Synthesis issues like not being able to infer clock gating -Unexpected circuits (seeing registers instead of memories) -Issues with running passes on coreir modules from linked libraries -Unsafe passing of verilog strings -Difficulty for debuggers to correlate generated signals with original python code

I think this boils down to the following more concrete problems:

-Overly verbose names for modules, ports, instances. More Details: -For ports, this is due to the ‘flatten_types’ pass -For modules, this is due to generators with lots of parameters -For instances, this is due to inlining/flattening Solutions: -Change default generated names to use verilog escape syntax (\any-non-whitespace-is-valid) -Pass to simplify module/instance names -Allow passing packed multi-dimensional arrays in verilog ports -Translate bi-directional Record-based ‘ports’ to System Verilog interfaces -Update verilog-AST to support ast for SV interfaces

-Unneeded wires like those connecting module ports to instance ports. More details: -Currently a wire is declared for every port of every instance of a module. -This is duplicating wires since some of these are already declared in the module port list, Solutions: -Create a pass in Verilog-AST to remove these duplicated wires -OR update coreir’s verilog backend to deduplicate these wires.

-Cleaning up/simplifying coreir libraries More Details -Missing python API for consistently applying passes to all coreir namespaces -Sometimes unclear why passes did not get applied to certain modules -Sometimes unclear why certain modules does not get serialized Solutions: -Change default way passes are applied to modules -Change default way to decide which modules should get serialized -(Changes already exist in a branch ‘update-json’)

-Inconsistency between magma’s mantle and coreir’s mantle library More Details -mantle operators do not directly match coreir’s mantle operators -different generator parameters and names of ports -missing/duplicated operators -Possible bugs due to lack of tests -This causes an extra level of hierarchy to be produced when compiling to CoreIR -Some memories in magma/mantle are compiling to registers instead of coreir.mem -coreir.mem is not universal (missing ability to specify multiple read/write ports, byte_en etc…) Solution: -Come up with a consistent set of ‘mantle operators’ which are represented in both CoreIR and mantle. -Implement/test them all -Compile mantle operators as CoreIR generators instead of eagerly evaluating in magma.

-Missing tech-specific implementations and passes Details -Clock gates are not inferred by VCS due to verilog not being in specific always-block format -Possibly always blocks produce better QOR than structural verilog (Although likely disproven by recent results) -Verilog implementations for primitives are currently unsafe verilog strings Solutions: -Define a clock-gated register (with appropriate verilog implementation) and a pass that fuses mux + coreir.reg into the clock-gated register -inline leaf verilog modules (coreir primitives) from Verilog-AST -CoreIR pass(es) to consolidate combinational paths. -CoreIR pass(es) to translate series of muxes into verilog case statements. -Change verilog implementations of primitives to Verilog-AST instead of strings. -Use a parser to store verilog strings as Verilog-AST

-Missing a debugging symbol table Details: -Generated verilog signals/modules are difficult to correspond to original python code Solutions: -Maintain a symbol table that records original source file information -Define a consistent way to update symbol table based off of arbitrary circuit transformations -A major research project in of itself. Some work has been done by FIRRTL guys. The general case is very complex.

-Missing simple concrete tests with benchmarks Details: -Some of these issues are difficult to solve due to the lack of simple tests showcasing the problem Solutions: -Use test-driven development to first have a suite of failing tests, each showcasing a particular issue. -If one comes across a verilog issue, complaining “the verilog produced is bad!” is particularly unhelpful without a concrete test and an expected result.