emsec
Multiple target libraries
Is your feature request related to a problem? Please describe.
I am trying to visualize a PNR netlist written by a commercial PNR toolchain.
We have multiple .lib files that are used in this "chip-top" netlist: Standard cells, Analog models, RAMs, Pads, etc...
However, when loading the netlist, I can choose only single library. But then my netlist loading errors out since it can't map e.g. the SRAM cell to a cell from STD cell library.
Describe the solution you'd like Choose "multiple" target libraries, e.g. by importing all liberty files and allowing all of them to be used. I think this can be made like that when you "import" a library, it will automatically be part of "available" libraries list. Such list would implicitly contain the built-in libraries. Each item of the list would contain a checkbox saying if this library shall be used when reading the netlist.
Describe alternatives you've considered
Copy paste all the used libraries into single .lib file -> Sorry too hackish for our files.
- Alternative could be throwing only warning if the cell could not be mapped to a target library, but it would create a black-box. This would then allow displaying library with STD cells
.libonly, but all the analog and pad macros would be "black-boxed" out. This does not mind at all...
Additional context Nice work on the tool, thank you for the effort.
Any clue on what to do with this ?
I like HAL, and I would like to try to use it instead of commercial equivalent called GateVisionPRO, but the fact that I can't load my netlist is making it... well... unusable.
Is there alternatively option to use "no-technology" and treat every module in the netlist as black-box ?
Sorry for the delay handling your request. We discussed already the need of using multiple gate libraries internally while preserving backward compatibility. I will generate a prototype in a branch very soon.
It is important that the libraries are provided in an hierarchical order in case there are contradicting descriptions of the same gate type.
I do not really like the "black box" idea since we cannot parse the netlist without knowing which input and output pins a gate has. Subsequent algorithms require additionally the information whether a gate can be described with a boolean function or whether sequential logic is involved (internal states). It would be up to the user to generate its own gate library if he thinks he can guess all this information from the netlist.
Thanks for the reply.
In a typical "digital on top" ASIC development, some analog macros such as "voltage regulators" may not even have logic function. A .lib file for such macros is really only dummy in the sense the the pins have no function attribute.
Sure, you need such liberty files if you want to link your design for synthesis (and DEF for PNR), but only for viewing schematic, this should not be needed. What type of "subsequent algorithms" then use the .lib function ?
If the function is necessarily "needed", then I could imagine that black-box inputs could be inferred to have no impact,
and outputs would be constant driven to zero. But without knowing the .lib you wont know the direction. So, maybe
just inferring each pin as bidir ?
"Subsequent algorithms" are e.g. Logic Evaluator, Simulation Controller and Dataflow Analysis, they all need to know whether a gate is combinatoric only or whether it has (sequential) internal states. Thus this information is present in all HAL gate types and can not be omitted. However, if you know the input- and output-pins and are going to use HAL for visualization only we don't care about the classification and might be able to add a dummy black box type to the HAL gate library. But the gate type is immutable once the gate has been instantiated and cannot be replaced later on. If that is OK for you I'd like to get a minimal .lib example declaring the input- and output-pins of such a black box and I'd try to get it parsed, thus the netlist can get loaded for visualization.
I understand. I will try to explain my use-case.
I was trying to evaluate HAL as a possible alternative for gate-level debugger / netlist viewer. If you are faimiliar with Quartus from Altera, the engine for displaying schematics there, is actually available as stand-alone tool "GateVision PRO". It is very helpful when debugging SDF annotated netlist simulations and possibly visualizing paths from STA reports. So my use-case is "view only".
But some black-box candidates may potentially benefit from having their .lib file loaded
(e.g. RAM memories). My .lib files do contain some indication that the cells are a memory,
but, I was not able to find more details in the Liberty reference manual. Others will not benefit
from this at all (like the LDO mentioned above).
Another option would be getting information about these cells via loading their verilog model. From there you can infer the port directions and functional behavior for simulation. But, I guess this is not a full-fledged event based Verilog simulation, correct ? Also, my assumption is, that the verilog parser handles only structural verilog, or does it handle full language ?
So, either way is fine for me as long as I can "link" and display the netlist.
But if you choose the option to enforce all .libs needed (and therefore allow loading multiple
.lib files), it would be good if these files could be somehow loaded by a script within the tool.
The netlist I am talking about, has 1 .lib for STD cells and about 20 others for various macros.
The paths to these are held in a YAML configurations for the given design. So, it is very easy
to convert it to something like:
read_lib <path_to_first_lib>
read_lib <path_to_the_second_lib>
and launching such script within HAL, rather than clicking in the gui.
If you give me some pointers on where to look I might be able to contribute some changes, but I don't promise anything since I am quite busy with work.
Funny that you mention Quartus from Altera since I started only days ago to build a gate library for a Cyclone V netlist. I am still a newbie in that field and have not used the "GateVision PRO" tool yet but there is definitively the motion to be more active in that field. So far we were extracting the functionality of a gate types from Quartus library file twentynm_atoms.v. Must admit that there are only a handful of different gate types in that specific netlist so entering the functionality in HAL gate library manager can be done by hand.
Once the netlist gets parsed correctly HAL launches a VERILATOR subprocess for simulation which is as "full fledged" as it can be in the open source world. Results gets re-imported into HAL and can be visualized either in the Waveform-Viewer or in the graphical netlist.
Since any development in that matter (e.g. parse multiple .libs) needs to be test driven (nice buzzword) it would be great if you could provide your netlist and .lib files. If you are afraid to disclose the project you are working on you might be able to produce a minimal example ?!?
Funny that you mention Quartus from Altera since I started only days ago to build a gate library for a Cyclone V netlist. I am still a newbie in that field and have not used the "GateVision PRO" tool yet but there is definitively the motion to be more active in that field. So far we were extracting the functionality of a gate types from Quartus library file twentynm_atoms.v. Must admit that there are only a handful of different gate types in that specific netlist so entering the functionality in HAL gate library manager can be done by hand.
Unfortunately, most ASIC libraries are proprietary, so I can't "do the logic import once and be part of HAL forever", since publishing them would violate NDA.
Once the netlist gets parsed correctly HAL launches a VERILATOR subprocess for simulation which is as "full fledged" as it can be in the open source world. Results gets re-imported into HAL and can be visualized either in the Waveform-Viewer or in the graphical netlist.
This is interesting, I did not know that. I am curios on how does HAL do it. Does it convert the function of the cells from .lib into some simplified verilog (based on their internal function attribute), and then compiles and links netlist + the code in verilator ?
Btw. if the target of HAL is to be something like "HW Debugger", the OS community around YOSYS is working on CXXRTL simulation protocol which would aim for extracting scopes, signals and waveform data from "live simulation":
https://github.com/cxxrtl/cxxrtl.github.io https://cxxrtl.org/
If this is supported by both HAL and the simulator, then the simulator can use HAL to display the content of the design being simulated. I am not sure what is the status support in other tools than Yosys, but I know the Surfer waveform viewer developers were talking about this.
Since any development in that matter (e.g. parse multiple .libs) needs to be test driven (nice buzzword) it would be great if you could provide your netlist and .lib files. If you are afraid to disclose the project you are working on you might be able to produce a minimal example ?!?
I can't provide the .libs they are under NDA. But I would be able to put together some minimal example. I would be further interested in contributing to this tool. Do you accept contributions ?
Let me answer the last question first. Since HAL is open source everyone is encouraged to contribute and we have already merged several external PR. However, if you look deeper into the code there is a strict separation from core, GUI and plugins (like simulation plugin). While there are very little restrictions to add a plugin proposed changes to the core will be scrutinized carefully. There are even some tools in place to check whether coding standards have been followed plus whether modified code passes automated tests. Unfortunately the HAL team at MPI-SP is understaffed right now, code review might take some time.
If you look deeper under the hood you'll find that HAL is not using the .lib-Liberty-format internally. Gate types gets parsed into a property/component structure in memory which gets persisted as .hgl file on disk. While some .hgl files are shipped with HAL the user is free to generate any number of private gate libraries. Whether these gate libraries get stored in a common place for all projects or within a single project directory only, there is no need to share and disclose your secrets for other. I can still not see why not "do the logic import once" so that they would be part of YOUR HAL installation.
When you start a simulation the gate type logic description files VERILATOR needs get auto-generated from the gate type description residing in memory into your simulation directory. There is a caveat : HAL cannot deal with every possible gate type functionality. E.g. LUT's with several outputs have to be split into several LUT with one output each, the same applies for multi-bank-FF's and -latches. We are working to get more types involved. Did I mention already that we are currently understaffed?
I am slightly familiar with YOSYS but I have to lookup a couple of tools you mentioned plus the CXXRTL simulation protocol I haven't heard off so far. I might come with a more qualified answer once I did all this.
The most effective contribution for the multi-lib feature I could think off would still be a netlist with multiple .lib files. It does not need to be a real world example and the functionality could be completely made up, thus not violating any NDA's. I could ask a student coworker to produce such a minimal example but we are currently ... OK, stop, now I start repeating myself.