Home

Welcome to the netlistDB wiki!

Toady every library for HDL generating/parsing/simulation implements custom API for working with HDL and for in memory circuit representation.

Development of such a tools is extremely time consuming task. Differences in internal representation in current libraries also makes sharing of the code between the libraries impossible. This means that the developers of "hardware mapping algorithms"/"simulators"/"code analysis software" has to always write they API for parsing and generating of the HDL language and it has to be always implemented again because it can not be separated from original project.

Many problems in HDL synthesis are NP-hard tasks and efficient heuristic are also hard to implement. In order to be able to share circuit transformations and optimizations etc. we need to have unified API and internal representations or at least have conversion function for different hardware representations. This also greatly simplify current libraries because Verilog/VHDL parsing and generating is large code.

Existing internal representations in different projects

• abc https://github.com/berkeley-abc/abc
• FIRRTL https://github.com/freechipsproject/firrtl
• hwt https://github.com/Nic30/hwt
• ICARUS Verilog https://github.com/steveicarus/iverilog
• MyHdl https://github.com/myhdl/myhdl
• NetlistDB https://github.com/HardwareIR/netlistDB
• SpinalHDL https://github.com/SpinalHDL/SpinalHDL
• Verilator https://www.veripool.org/projects/verilator/wiki/Intro
• Yosys https://github.com/YosysHQ/yosys

Feasibility of the universal API for the circuit representation and HDL generation

There are many libraries which does contain IR for the hardware. Why another library should help?

• The problem is that the current libraries are too tied with target HDL or original project for what they was developed for. Another problem is performance and the implementation language or quality. So we are not doing this library because we need it. (For development of the hardware generators, HDL parsers/generators, HLS engines, etc...)

• The complexity of the current libraries which are using some form of HW IR comes from complicated work with this IR. We try to separate the algorithm logic from the complexities of the HW IR by graph database like API.

• All object in this library can be easily converted from and to other formats as the connections between the object in the netlistDB are bidirectionally connected. So even if this library somehow dies you will not be lost as you can just convert your design to different format.

• This library unlike other allows to write optimization algorithms with minimal care about this library, which makes easy to write your circuit transformation and greatly simplifies learning curve.

  • For example you need just use iNode::forward() and Statement::sens to discover the combinational loops in design.