3 ms·

Fair enough to create a device/vendor independent format for describing FPGA resources, but why not use EDIF [1] for the logical and physical netlists? [1] htt

by femto 5y ago

Fair enough to create a device/vendor independent format for describing FPGA resources, but why not use EDIF [1] for the logical and physical netlists? [1] https://en.wikipedia.org/wiki/EDIF https://en.wikipedia.org/wiki/EDIF

AshamedCaptain 5y ago
Or BLIF or EBLIF (already used by the verilog-to-routing flow), or structural verilog, or a dozen more. But no, let's invent yet another netlist format. The fact that these existing formats are all named "xxx logic interchange format" should give you an idea what will happen to this new "interchange format". It will be used mostly to interchange with itself. From what I gather ( https://github.com/SymbiFlow/python-fpga-interchange/blob/master/tests/example_netlist.py https://github.com/SymbiFlow/python-fpga-interchange/blob/ma... ) , the new format is basically close to the existing Yosys/nextpnr JSON format except dumped as a Cap'n Proto binary file. I am not impressed -- this is even more inconvenient than a huge JSON file. I guess the meat here is on the universal device resources format anyway...
clavin1024 5y ago
A few reasons why EDIF might not be a good candidate for this: 1) The standards body that controls EDIF no longer exists, this could limit the ability to evolve and improve it. 2) Large placed and routed FPGA designs contain a lot of data and rendering it to EDIF would just slow down the process of transferring, parsing, etc. Binary is the way to go (unless debugging, the FPGA Interchange Format offers a human-readable version for that). As a comparison, some of the proprietary vendor design formats can take tens of minutes to load a full design. 3) Expressing the details necessary to reconstruct a placed and routed FPGA circuit would not naturally flow from EDIF. EDIF is good for describing a logical netlist. However, a placed and routed FPGA implementation is the mapping of a logical netlist onto the physical netlist of the FPGA. Building a format suited to FPGA architecture makes expression of these constructs easier and more efficient. 4) Writing and maintaining an EDIF parser/de-parser creates more work than using a schema-based code generator. Although work is still involved when interfacing the tool to the format, it removes a pile of issues associated with text-based formats. [edit: fixed typo]
- mithro 5y ago
  All these are good points but missed a key thing. The interchange format includes a computer readable description of the FPGA which tells the tooling what is available inside the FPGA and how they can be connected.

by femto 5y ago

AshamedCaptain 5y ago

Or BLIF or EBLIF (already used by the verilog-to-routing flow), or structural verilog, or a dozen more. But no, let's invent yet another netlist format. The fact that these existing formats are all named "xxx logic interchange format" should give you an idea what will happen to this new "interchange format". It will be used mostly to interchange with itself. From what I gather ( https://github.com/SymbiFlow/python-fpga-interchange/blob/master/tests/example_netlist.py https://github.com/SymbiFlow/python-fpga-interchange/blob/ma... ) , the new format is basically close to the existing Yosys/nextpnr JSON format except dumped as a Cap'n Proto binary file. I am not impressed -- this is even more inconvenient than a huge JSON file. I guess the meat here is on the universal device resources format anyway...

clavin1024 5y ago

A few reasons why EDIF might not be a good candidate for this: 1) The standards body that controls EDIF no longer exists, this could limit the ability to evolve and improve it. 2) Large placed and routed FPGA designs contain a lot of data and rendering it to EDIF would just slow down the process of transferring, parsing, etc. Binary is the way to go (unless debugging, the FPGA Interchange Format offers a human-readable version for that). As a comparison, some of the proprietary vendor design formats can take tens of minutes to load a full design. 3) Expressing the details necessary to reconstruct a placed and routed FPGA circuit would not naturally flow from EDIF. EDIF is good for describing a logical netlist. However, a placed and routed FPGA implementation is the mapping of a logical netlist onto the physical netlist of the FPGA. Building a format suited to FPGA architecture makes expression of these constructs easier and more efficient. 4) Writing and maintaining an EDIF parser/de-parser creates more work than using a schema-based code generator. Although work is still involved when interfacing the tool to the format, it removes a pile of issues associated with text-based formats. [edit: fixed typo]

mithro 5y ago
All these are good points but missed a key thing. The interchange format includes a computer readable description of the FPGA which tells the tooling what is available inside the FPGA and how they can be connected.