You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
SpyDrNet is designed to parse in any netlist type, allow for manipulation, and compose any netlist type. However, not all netlist types are treated equally in SpyDrNet. I will use the b13 netlist to illustrate:
In the EDIF version of the b13 netlist, all of the instance properties look like the following:
Both the EDIF and Verilog Composers look for specific things such as EDIF.properties (for EDIF composer) and Verilog.Parameters (for Verilog composer). This hinders the flexibility of SpyDrNet. One example of it causing problems is when doing TMR...we used to have just one voter whose properties were EDIF specific. Because the Verilog composer doesn't "look for" properties formatted in the "EDIF way", voters in a Verilog netlist are missing important properties. I created a fix for this by making separate voters for EDIF and Verilog (and EBLIF) and allowing one to specify which one to use. This patch works, but probably isn't great. Another instance of this problem is that the library that contains all the primitives instanced in the design is named "hdi_primitives" in EDIF and "SDN.verilog_primitives" in Verilog. These are just two examples of where these netlist-type-specific-ness causes problems.
It would be great if all properties (and other info) were formatted the same way throughout SpyDrNet. Instead of "EDIF.properties" and Verilog.Parameters" we could have just "Properties". Instead of "hdi_primitives" and "SDN.verilog_primitives" we could have "primitives".
This would be a great undertaking to make happen. EDIF and Verilog netlists are very different, so the effort to make this happen may not be worth it. However, if we could make this happen, I feel it would greatly improve spydrnet. At the very least, we could have a "netlist translator" that could translate things that are formatted for EDIF to the Verilog format and vice versa.
The text was updated successfully, but these errors were encountered:
SpyDrNet is designed to parse in any netlist type, allow for manipulation, and compose any netlist type. However, not all netlist types are treated equally in SpyDrNet. I will use the b13 netlist to illustrate:
In the EDIF version of the b13 netlist, all of the instance properties look like the following:
And then for the Verilog version, the instance properties look like:
Both the EDIF and Verilog Composers look for specific things such as EDIF.properties (for EDIF composer) and Verilog.Parameters (for Verilog composer). This hinders the flexibility of SpyDrNet. One example of it causing problems is when doing TMR...we used to have just one voter whose properties were EDIF specific. Because the Verilog composer doesn't "look for" properties formatted in the "EDIF way", voters in a Verilog netlist are missing important properties. I created a fix for this by making separate voters for EDIF and Verilog (and EBLIF) and allowing one to specify which one to use. This patch works, but probably isn't great. Another instance of this problem is that the library that contains all the primitives instanced in the design is named "hdi_primitives" in EDIF and "SDN.verilog_primitives" in Verilog. These are just two examples of where these netlist-type-specific-ness causes problems.
It would be great if all properties (and other info) were formatted the same way throughout SpyDrNet. Instead of "EDIF.properties" and Verilog.Parameters" we could have just "Properties". Instead of "hdi_primitives" and "SDN.verilog_primitives" we could have "primitives".
This would be a great undertaking to make happen. EDIF and Verilog netlists are very different, so the effort to make this happen may not be worth it. However, if we could make this happen, I feel it would greatly improve spydrnet. At the very least, we could have a "netlist translator" that could translate things that are formatted for EDIF to the Verilog format and vice versa.
The text was updated successfully, but these errors were encountered: