https://www.verific.com/faq/api.php?action=feedcontributions&user=107.3.140.142&feedformat=atomVerific Design Automation FAQ - User contributions [en]2024-03-29T02:37:50ZUser contributionsMediaWiki 1.26.3https://www.verific.com/faq/index.php?title=VHDL,_Verilog,_Liberty,_EDIF&diff=95VHDL, Verilog, Liberty, EDIF2016-07-07T21:23:06Z<p>107.3.140.142: </p>
<hr />
<div><div id="AllFilesVY"></div><br />
'''Q: I'm using -v, -y, .... After Verific is done with the analysis, how do I get a list of all the files being analyzed?'''<br />
<br />
Use this code:<br />
<br />
Array analyzed_files ; // Array to store file-names<br />
unsigned file_id = 1 ; // File-id starts from 1<br />
char *file_name = 0 ;<br />
while ((file_name = LineFile::GetFileNameFromId(file_id++))) {<br />
analyzed_files.InsertLast(file_name) ;<br />
}<br />
// Now analyzed_files array should contain all the files analyzed<br />
<br />
How this works:<br />
<br />
# Verific keeps file_name vs. file_id mapping.<br />
# File_id starts from 1 and increases by 1.<br />
# LineFile::GetFileNameFromId() returns 0 for non-existing id.<br />
# The code keeps calling the API with increnemted file_id until getting a 0.<br />
<br />
You may want to use LineFile::GetAbsFileNameFromId() API instead of LineFile::GetFileNameFromId() if you need absolute filenames (with full path).<br />
<br />
<br />
<br />
<div id="NetlistWhichModule"></div><br />
'''Q: While looking at a Netlist, is there a clean way to look back at what VeriModule* or VhdlPrimaryUnit* this netlist was derived from? '''<br />
<br />
For example, a module:<br />
<br />
module mod();<br />
parameter WIDTH=2;<br />
...<br />
endmodule<br />
<br />
would elaborate to a netlist name \mod(WIDTH=2) or if instantiated with a different width \mod(WIDTH=4)<br />
<br />
There are "system" attributes attached to the Netlist that you may find useful. Note the leading space:<br />
<br />
:key: " language", value: one of "verilog" "vhdl".<br />
:key: " cell_name", value: original module/unit name. <br />
<br />
See also Netlist::CellBaseName().<br />
<br />
Once you get the original name of the module/unit, you can search the parse tree for it.<br />
<br />
<br />
<br />
<div id="PortsRenamedP1P2"></div><br />
'''Q: Why are the ports in original Verilog file renamed to p1, p2, ....?'''<br />
<br />
Input file:<br />
module foo ( datain[0], datain[0] /* same net into multiple port expression */,<br />
datain[2:1] /* part-select port expression */,<br />
/* empty port expression */,<br />
{datain[2],datain[1], datain[1]} /* concatenation in port expression */<br />
) ;<br />
input [2:0] datain ;<br />
...<br />
endmodule<br />
<br />
Output netlist:<br />
module foo (p1, p2, p3, , p7); // test.v(1[8:11])<br />
input p1; // test.v(6[17:23])<br />
input p2; // test.v(6[17:23])<br />
input [1:0]p3;<br />
input [2:0]p7;<br />
... <br />
endmodule<br />
<br />
<br />
The items in the () after the module name are not "port names," rather, they are "port expressions." Verilog defines that the port expressions on this module CANNOT be accessed by name (only by order). This means you cannot rely on the port names to be one thing or another. <br />
<br />
Verific chose to not adjust to any particular naming scheme for complex port expressions, which also allows us to error out if named port instantiation occurs where the language disallows it.<br />
<br />
The original port expression of the renamed port is saved as attributes " orig_port_name" attached to the port.<br />
<br />
key: " orig_port_name", value: port expression<br />
<br />
For the testcase above:<br />
<br />
input p1 /* verific orig_port_name=datain[0] */ ;<br />
input p2 /* verific orig_port_name=datain[0] */ ;<br />
input [1:0]p3 /* verific orig_port_name=datain[2] datain[1] */ ;<br />
input [2:0]p7 /* verific orig_port_name=datain[2] datain[1] datain[1] */ ;<br />
<br />
<br />
<br />
<div id="VrlgOrSV"></div><br />
'''Q: I have a design consisting of a mixture of Verilog 2001 and SystemVerilog input files. Should I parse all the files as SystemVerilog?'''<br />
<br />
<br />
The set of SystemVerilog constructs is a superset of the set of Verilog 2001 constructs. As a corollary, the set of SystemVerilog keywords is a superset of the set of Verilog 2001 keywords.<br />
<br />
Parsing a Verilog 2001 file as SystemVerilog will work, as long as the file does not use any SystemVerilog keyword as identifier. If you parse the file as SystemVerilog an run into a syntax error, try parsing it as Verilog 2001.<br />
<br />
Another significant difference between Verilog 2001 and SystemVerilog is "compilation units." The default mode of Verilog 2001 is "multi-file" while the default mode of SystemVerilog is "single-file." For more details, please read:<br />
<br />
http://www.verific.com/docs/index.php?title=Single/Multi-File_Compilation_Units<br />
<br />
<br />
<br />
<div id="VHDL9308"></div><br />
'''Q: A customer wants to analyze/elaborate different VHDL flavors (1993 and 2008). They want to process the 93 files first and then the 08. As each flavor has its own IEEE library set, do you have any suggestion on how to handle this scenario?'''<br />
<br />
A:<br />
Please load the 2008 version of the IEEE library distributed by Verific and then analyze the 1993 and 2008 design files in their proper dialect. Verific will internally adjust the packages and both the designs should compile without any errors.<br />
For example:<br />
<br />
setvhdllibrarypath -default verific_source/vhdl_packages/vdbs_2008<br />
analyze test93.vhdl<br />
analyze -vhdl_2008 test2008.vhdl<br />
<br />
For more details, see http://www.verific.com/w/index.php/VHDL-1993_versus_VHDL-2008_IEEE_packages</div>107.3.140.142https://www.verific.com/faq/index.php?title=VHDL,_Verilog,_Liberty,_EDIF&diff=94VHDL, Verilog, Liberty, EDIF2016-07-07T21:20:43Z<p>107.3.140.142: </p>
<hr />
<div><div id="AllFilesVY"></div><br />
'''Q: I'm using -v, -y, .... After Verific is done with the analysis, how do I get a list of all the files being analyzed?'''<br />
<br />
Use this code:<br />
<br />
Array analyzed_files ; // Array to store file-names<br />
unsigned file_id = 1 ; // File-id starts from 1<br />
char *file_name = 0 ;<br />
while ((file_name = LineFile::GetFileNameFromId(file_id++))) {<br />
analyzed_files.InsertLast(file_name) ;<br />
}<br />
// Now analyzed_files array should contain all the files analyzed<br />
<br />
How this works:<br />
<br />
# Verific keeps file_name vs. file_id mapping.<br />
# File_id starts from 1 and increases by 1.<br />
# LineFile::GetFileNameFromId() returns 0 for non-existing id.<br />
# The code keeps calling the API with increnemted file_id until getting a 0.<br />
<br />
You may want to use LineFile::GetAbsFileNameFromId() API instead of LineFile::GetFileNameFromId() if you need absolute filenames (with full path).<br />
<br />
<br />
<div id="NetlistWhichModule"></div><br />
'''Q: While looking at a Netlist, is there a clean way to look back at what VeriModule* or VhdlPrimaryUnit* this netlist was derived from? '''<br />
<br />
For example, a module:<br />
<br />
module mod();<br />
parameter WIDTH=2;<br />
...<br />
endmodule<br />
<br />
would elaborate to a netlist name \mod(WIDTH=2) or if instantiated with a different width \mod(WIDTH=4)<br />
<br />
There are "system" attributes attached to the Netlist that you may find useful. Note the leading space:<br />
<br />
:key: " language", value: one of "verilog" "vhdl".<br />
:key: " cell_name", value: original module/unit name. <br />
<br />
See also Netlist::CellBaseName().<br />
<br />
Once you get the original name of the module/unit, you can search the parse tree for it.<br />
<br />
<div id="PortsRenamedP1P2"></div><br />
'''Q: Why are the ports in original Verilog file renamed to p1, p2, ....?'''<br />
<br />
Input file:<br />
module foo ( datain[0], datain[0] /* same net into multiple port expression */,<br />
datain[2:1] /* part-select port expression */,<br />
/* empty port expression */,<br />
{datain[2],datain[1], datain[1]} /* concatenation in port expression */<br />
) ;<br />
input [2:0] datain ;<br />
...<br />
endmodule<br />
<br />
Output netlist:<br />
module foo (p1, p2, p3, , p7); // test.v(1[8:11])<br />
input p1; // test.v(6[17:23])<br />
input p2; // test.v(6[17:23])<br />
input [1:0]p3;<br />
input [2:0]p7;<br />
... <br />
endmodule<br />
<br />
<br />
The items in the () after the module name are not "port names," rather, they are "port expressions." Verilog defines that the port expressions on this module CANNOT be accessed by name (only by order). This means you cannot rely on the port names to be one thing or another. <br />
<br />
Verific chose to not adjust to any particular naming scheme for complex port expressions, which also allows us to error out if named port instantiation occurs where the language disallows it.<br />
<br />
The original port expression of the renamed port is saved as attributes " orig_port_name" attached to the port.<br />
<br />
key: " orig_port_name", value: port expression<br />
<br />
For the testcase above:<br />
<br />
input p1 /* verific orig_port_name=datain[0] */ ;<br />
input p2 /* verific orig_port_name=datain[0] */ ;<br />
input [1:0]p3 /* verific orig_port_name=datain[2] datain[1] */ ;<br />
input [2:0]p7 /* verific orig_port_name=datain[2] datain[1] datain[1] */ ;<br />
<br />
<br />
<div id="VrlgOrSV"></div><br />
'''Q: I have a design consisting of a mixture of Verilog 2001 and SystemVerilog input files. Should I parse all the files as SystemVerilog?'''<br />
<br />
<br />
The set of SystemVerilog constructs is a superset of the set of Verilog 2001 constructs. As a corollary, the set of SystemVerilog keywords is a superset of the set of Verilog 2001 keywords.<br />
<br />
Parsing a Verilog 2001 file as SystemVerilog will work, as long as the file does not use any SystemVerilog keyword as identifier. If you parse the file as SystemVerilog an run into a syntax error, try parsing it as Verilog 2001.<br />
<br />
Another significant difference between Verilog 2001 and SystemVerilog is "compilation units." The default mode of Verilog 2001 is "multi-file" while the default mode of SystemVerilog is "single-file." For more details, please read:<br />
<br />
http://www.verific.com/docs/index.php?title=Single/Multi-File_Compilation_Units<br />
<br />
<br />
<div id="VHDL9308"></div><br />
'''Q: A customer wants to analyze/elaborate different VHDL flavors (1993 and 2008). They want to process the 93 files first and then the 08. As each flavor has its own IEEE library set, do you have any suggestion on how to handle this scenario?'''<br />
<br />
A:<br />
Please load the 2008 version of the IEEE library distributed by Verific and then analyze the 1993 and 2008 design files in their proper dialect. Verific will internally adjust the packages and both the designs should compile without any errors.<br />
For example:<br />
<br />
setvhdllibrarypath -default verific_source/vhdl_packages/vdbs_2008<br />
analyze test93.vhdl<br />
analyze -vhdl_2008 test2008.vhdl<br />
<br />
For more details, see http://www.verific.com/w/index.php/VHDL-1993_versus_VHDL-2008_IEEE_packages</div>107.3.140.142https://www.verific.com/faq/index.php?title=Main_Page&diff=93Main Page2016-07-07T21:20:09Z<p>107.3.140.142: </p>
<hr />
<div>'''General'''<br />
* [[General#NetlistOriginalLanguage | How do I know what language a Netlist in the netlist database comes from?]]<br />
* [[General#VerificDataStructures | What are the data structures in Verific?]]<br />
* [[General#XMR | Does Verific support cross module references (XMR)?]]<br />
<br />
<br />
'''VHDL, Verilog, Liberty, EDIF'''<br />
* [[ VHDL,_Verilog,_Liberty,_EDIF#AllFilesVY | I'm using -v, -y, .... After Verific is done with the analysis, how do I get a list of all the files being analyzed?]]<br />
* [[ VHDL,_Verilog,_Liberty,_EDIF#NetlistWhichModule | While looking at a Netlist, is there a clean way to look back at what VeriModule* or VhdlPrimaryUnit* this netlist was derived from?]]<br />
* [[ VHDL,_Verilog,_Liberty,_EDIF#PortsRenamedP1P2 | Why are the ports in original Verilog file renamed to p1, p2, ....?]]<br />
* [[ VHDL,_Verilog,_Liberty,_EDIF#VrlgOrSV | I have a design consisting of a mixture of Verilog 2001 and SystemVerilog input files. Should I parse all the files as SystemVerilog?]]<br />
* [[ VHDL,_Verilog,_Liberty,_EDIF#VHDL9308 | A customer wants to analyze/elaborate different VHDL flavors (1993 and 2008). They want to process the 93 files first and then the 08. As each flavor has its own IEEE library set, do you have any suggestion on how to handle this scenario?]]<br />
<br />
<br />
<br />
<br />
<br />
<br />
'''Output'''<br />
<br />
'''TCL, Perl, Python, Java'''</div>107.3.140.142https://www.verific.com/faq/index.php?title=Main_Page&diff=92Main Page2016-07-07T21:05:26Z<p>107.3.140.142: </p>
<hr />
<div>'''General'''<br />
* [[General#NetlistOriginalLanguage | How do I know what language a Netlist in the netlist database comes from?]]<br />
* [[General#VerificDataStructures | What are the data structures in Verific?]]<br />
* [[General#XMR | Does Verific support cross module references (XMR)?]]<br />
<br />
* [[VHDL, Verilog, Liberty, EDIF]]<br />
* [[Output]]<br />
* [[TCL, Perl, Python, Java]]</div>107.3.140.142https://www.verific.com/faq/index.php?title=Main_Page&diff=91Main Page2016-07-07T21:04:11Z<p>107.3.140.142: </p>
<hr />
<div>'''General'''<br />
* [[General | How do I know what language a Netlist in the netlist database comes from?]]<br />
* [[General | What are the data structures in Verific?]]<br />
* [[General#XMR | Does Verific support cross module references (XMR)?]]<br />
<br />
* [[VHDL, Verilog, Liberty, EDIF]]<br />
* [[Output]]<br />
* [[TCL, Perl, Python, Java]]</div>107.3.140.142https://www.verific.com/faq/index.php?title=Main_Page&diff=90Main Page2016-07-07T21:03:16Z<p>107.3.140.142: </p>
<hr />
<div>'''General'''<br />
* [[General | How do I know what language a Netlist in the netlist database comes from?]]<br />
* [[General | What are the data structures in Verific?]]<br />
* [[General:XMR | Does Verific support cross module references (XMR)?]]<br />
<br />
* [[VHDL, Verilog, Liberty, EDIF]]<br />
* [[Output]]<br />
* [[TCL, Perl, Python, Java]]</div>107.3.140.142https://www.verific.com/faq/index.php?title=General&diff=89General2016-07-07T21:01:52Z<p>107.3.140.142: </p>
<hr />
<div><div id="NetlistOriginalLanguage"></div><br />
'''Q: How do I know what language a Netlist in the netlist database comes from?'''<br />
<br />
Use attribute " language" (note the leading space):<br />
<br />
Netlist *nl;<br />
nl->GetAttValue(" language") <br />
<br />
returns one of "vhdl", "verilog", "edif", "synlib".<br />
<br />
<br />
<div id="VerificDataStructures"></div><br />
'''Q: What are the data structures in Verific?'''<br />
<br />
There are 2 data structures in Verific: parsetree and netlist database.<br />
<br />
1. The parsetree is just another representation of the design. It contains the exact information as in the RTL files, only in a machine-readable format. Because each language (Verilog or VHDL) has its own constructs, each language has its own parsetree.<br />
<br />
The parsetree is the result of veri_file::Analyze()/vhdl_file::Ananlyze().<br />
<br />
The design parsetree can be "statically elaborated." These are some of the<br />
operations during static elaboration process:<br />
<br />
- Unrolling "generate" loops.<br />
- Evaluating constant expressions.<br />
- Uniquifying instances of parameterized modules/entities.<br />
<br />
The result of static elaboration is a modified parsetree.<br />
<br />
The parsetree supports all constructs of the language.<br />
<br />
2. The synthesizable subset of the parsetree can go through "RTL elaboration" (or "synthesis"). The result is the "netlist database," consisting of "hardware" components: libraries, cells, netlists, nets, ports, instances, operators (adders, muxes, ...), and primitives (ands, ors, xors, ...). The netlist database is language-independent. The contents of the netlist database can be written out in various structural languages: Verilog, VHDL, EDIF, BLIF. In general, the output netlist from the netlist database does not look anything like the RTL input files.<br />
<br />
The netlist database is the result of veri_file::Elaborate()/vhdl_file::Elaborate() API (after veri_file::Analyze()/vhdl_file::Analyze()).<br />
<br />
RTL elaboration supports the synthesizable subset of the language.<br />
<br />
<br />
<div id="XMR"></div><br />
'''Q: Does Verific support cross module references (XMR)?'''<br />
<br />
Verific fully supports XMR with "hierarchy tree" feature. Please refer to http://www.verific.com/docs/index.php?title=Hierarchy_Tree<br />
<br />
Without this product feature, support for XMR is full in analysis and static elaboration, and is very limited in RTL elaboration.<br />
<br />
The main reason for limited support in RTL elaboration for XMR is that for Verilog, the order of elaboration of modules is nondeterministic. If module "foo" has not been elaborated, the elaborator will not be able to resolve "foo.bar".<br />
<br />
If the order of elaboration guarantees resolution of signals (e.g. module "foo" is elaborated before the module using "foo.bar" is), these runtime flags need to be enabled (set to 1) before design analysis:<br />
<br />
veri_preserve_user_nets<br />
db_preserve_user_nets<br />
db_allow_external_nets</div>107.3.140.142https://www.verific.com/faq/index.php?title=Main_Page&diff=88Main Page2016-07-07T20:58:24Z<p>107.3.140.142: </p>
<hr />
<div>'''General'''<br />
* [[General | How do I know what language a Netlist in the netlist database comes from?]]<br />
* [[General | What are the data structures in Verific?]]<br />
* [[General | Does Verific support cross module references (XMR)?]]<br />
<br />
* [[VHDL, Verilog, Liberty, EDIF]]<br />
* [[Output]]<br />
* [[TCL, Perl, Python, Java]]</div>107.3.140.142https://www.verific.com/faq/index.php?title=Main_Page&diff=87Main Page2016-07-07T20:40:58Z<p>107.3.140.142: </p>
<hr />
<div>General<br />
* [[How do I know what language a Netlist in the netlist database comes from?]]<br />
* [[What are the data structures in Verific?]]<br />
* [[Does Verific support cross module references (XMR)?]]<br />
<br />
* [[VHDL, Verilog, Liberty, EDIF]]<br />
* [[Output]]<br />
* [[TCL, Perl, Python, Java]]</div>107.3.140.142https://www.verific.com/faq/index.php?title=General&diff=86General2016-07-07T20:27:05Z<p>107.3.140.142: </p>
<hr />
<div>'''Q: How do I know what language a Netlist in the netlist database comes from?'''<br />
<br />
Use attribute " language" (note the leading space):<br />
<br />
Netlist *nl;<br />
nl->GetAttValue(" language") <br />
<br />
returns one of "vhdl", "verilog", "edif", "synlib".<br />
<br />
<br />
'''Q: What are the data structures in Verific?'''<br />
<br />
There are 2 data structures in Verific: parsetree and netlist database.<br />
<br />
1. The parsetree is just another representation of the design. It contains the exact information as in the RTL files, only in a machine-readable format. Because each language (Verilog or VHDL) has its own constructs, each language has its own parsetree.<br />
<br />
The parsetree is the result of veri_file::Analyze()/vhdl_file::Ananlyze().<br />
<br />
The design parsetree can be "statically elaborated." These are some of the<br />
operations during static elaboration process:<br />
<br />
- Unrolling "generate" loops.<br />
- Evaluating constant expressions.<br />
- Uniquifying instances of parameterized modules/entities.<br />
<br />
The result of static elaboration is a modified parsetree.<br />
<br />
The parsetree supports all constructs of the language.<br />
<br />
2. The synthesizable subset of the parsetree can go through "RTL elaboration" (or "synthesis"). The result is the "netlist database," consisting of "hardware" components: libraries, cells, netlists, nets, ports, instances, operators (adders, muxes, ...), and primitives (ands, ors, xors, ...). The netlist database is language-independent. The contents of the netlist database can be written out in various structural languages: Verilog, VHDL, EDIF, BLIF. In general, the output netlist from the netlist database does not look anything like the RTL input files.<br />
<br />
The netlist database is the result of veri_file::Elaborate()/vhdl_file::Elaborate() API (after veri_file::Analyze()/vhdl_file::Analyze()).<br />
<br />
RTL elaboration supports the synthesizable subset of the language.<br />
<br />
<br />
'''Q: Does Verific support cross module references (XMR)?'''<br />
<br />
Verific fully supports XMR with "hierarchy tree" feature. Please refer to http://www.verific.com/docs/index.php?title=Hierarchy_Tree<br />
<br />
Without this product feature, support for XMR is full in analysis and static elaboration, and is very limited in RTL elaboration.<br />
<br />
The main reason for limited support in RTL elaboration for XMR is that for Verilog, the order of elaboration of modules is nondeterministic. If module "foo" has not been elaborated, the elaborator will not be able to resolve "foo.bar".<br />
<br />
If the order of elaboration guarantees resolution of signals (e.g. module "foo" is elaborated before the module using "foo.bar" is), these runtime flags need to be enabled (set to 1) before design analysis:<br />
<br />
veri_preserve_user_nets<br />
db_preserve_user_nets<br />
db_allow_external_nets</div>107.3.140.142https://www.verific.com/faq/index.php?title=General&diff=85General2016-07-07T20:25:54Z<p>107.3.140.142: </p>
<hr />
<div>'''Bold text'''Q: How do I know what language a Netlist in the netlist database comes from?'''<br />
<br />
Use attribute " language" (note the leading space):<br />
<br />
Netlist *nl;<br />
nl->GetAttValue(" language") <br />
<br />
returns one of "vhdl", "verilog", "edif", "synlib".<br />
<br />
<br />
'''Q: What are the data structures in Verific?'''<br />
<br />
There are 2 data structures in Verific: parsetree and netlist database.<br />
<br />
1. The parsetree is just another representation of the design. It contains the exact information as in the RTL files, only in a machine-readable format. Because each language (Verilog or VHDL) has its own constructs, each language has its own parsetree.<br />
<br />
The parsetree is the result of veri_file::Analyze()/vhdl_file::Ananlyze().<br />
<br />
The design parsetree can be "statically elaborated." These are some of the<br />
operations during static elaboration process:<br />
<br />
- Unrolling "generate" loops.<br />
- Evaluating constant expressions.<br />
- Uniquifying instances of parameterized modules/entities.<br />
<br />
The result of static elaboration is a modified parsetree.<br />
<br />
The parsetree supports all constructs of the language.<br />
<br />
2. The synthesizable subset of the parsetree can go through "RTL elaboration" (or "synthesis"). The result is the "netlist database," consisting of "hardware" components: libraries, cells, netlists, nets, ports, instances, operators (adders, muxes, ...), and primitives (ands, ors, xors, ...). The netlist database is language-independent. The contents of the netlist database can be written out in various structural languages: Verilog, VHDL, EDIF, BLIF. In general, the output netlist from the netlist database does not look anything like the RTL input files.<br />
<br />
The netlist database is the result of veri_file::Elaborate()/vhdl_file::Elaborate() API (after veri_file::Analyze()/vhdl_file::Analyze()).<br />
<br />
RTL elaboration supports the synthesizable subset of the language.<br />
<br />
<br />
'''Q: Does Verific support cross module references (XMR)?'''<br />
<br />
Verific fully supports XMR with "hierarchy tree" feature. Please refer to http://www.verific.com/docs/index.php?title=Hierarchy_Tree<br />
<br />
Without this product feature, support for XMR is full in analysis and static elaboration, and is very limited in RTL elaboration.<br />
<br />
The main reason for limited support in RTL elaboration for XMR is that for Verilog, the order of elaboration of modules is nondeterministic. If module "foo" has not been elaborated, the elaborator will not be able to resolve "foo.bar".<br />
<br />
If the order of elaboration guarantees resolution of signals (e.g. module "foo" is elaborated before the module using "foo.bar" is), these runtime flags need to be enabled (set to 1) before design analysis:<br />
<br />
veri_preserve_user_nets<br />
db_preserve_user_nets<br />
db_allow_external_nets</div>107.3.140.142https://www.verific.com/faq/index.php?title=General&diff=84General2016-07-07T20:24:42Z<p>107.3.140.142: </p>
<hr />
<div>==Q: How do I know what language a Netlist in the netlist database comes from?==<br />
<br />
Use attribute " language" (note the leading space):<br />
<br />
Netlist *nl;<br />
nl->GetAttValue(" language") <br />
<br />
returns one of "vhdl", "verilog", "edif", "synlib".<br />
<br />
<br />
==Q: What are the data structures in Verific?==<br />
<br />
There are 2 data structures in Verific: parsetree and netlist database.<br />
<br />
1. The parsetree is just another representation of the design. It contains the exact information as in the RTL files, only in a machine-readable format. Because each language (Verilog or VHDL) has its own constructs, each language has its own parsetree.<br />
<br />
The parsetree is the result of veri_file::Analyze()/vhdl_file::Ananlyze().<br />
<br />
The design parsetree can be "statically elaborated." These are some of the<br />
operations during static elaboration process:<br />
<br />
- Unrolling "generate" loops.<br />
- Evaluating constant expressions.<br />
- Uniquifying instances of parameterized modules/entities.<br />
<br />
The result of static elaboration is a modified parsetree.<br />
<br />
The parsetree supports all constructs of the language.<br />
<br />
2. The synthesizable subset of the parsetree can go through "RTL elaboration" (or "synthesis"). The result is the "netlist database," consisting of "hardware" components: libraries, cells, netlists, nets, ports, instances, operators (adders, muxes, ...), and primitives (ands, ors, xors, ...). The netlist database is language-independent. The contents of the netlist database can be written out in various structural languages: Verilog, VHDL, EDIF, BLIF. In general, the output netlist from the netlist database does not look anything like the RTL input files.<br />
<br />
The netlist database is the result of veri_file::Elaborate()/vhdl_file::Elaborate() API (after veri_file::Analyze()/vhdl_file::Analyze()).<br />
<br />
RTL elaboration supports the synthesizable subset of the language.<br />
<br />
<br />
==Q: Does Verific support cross module references (XMR)?==<br />
<br />
Verific fully supports XMR with "hierarchy tree" feature. Please refer to http://www.verific.com/docs/index.php?title=Hierarchy_Tree<br />
<br />
Without this product feature, support for XMR is full in analysis and static elaboration, and is very limited in RTL elaboration.<br />
<br />
The main reason for limited support in RTL elaboration for XMR is that for Verilog, the order of elaboration of modules is nondeterministic. If module "foo" has not been elaborated, the elaborator will not be able to resolve "foo.bar".<br />
<br />
If the order of elaboration guarantees resolution of signals (e.g. module "foo" is elaborated before the module using "foo.bar" is), these runtime flags need to be enabled (set to 1) before design analysis:<br />
<br />
veri_preserve_user_nets<br />
db_preserve_user_nets<br />
db_allow_external_nets</div>107.3.140.142https://www.verific.com/faq/index.php?title=Main_Page&diff=80Main Page2016-07-07T17:44:25Z<p>107.3.140.142: </p>
<hr />
<div>* [[General]]<br />
* [[VHDL, Verilog, Liberty, EDIF]]<br />
* [[Output]]<br />
* [[TCL, Perl, Python, Java]]</div>107.3.140.142https://www.verific.com/faq/index.php?title=VHDL,_Verilog,_Liberty,_EDIF&diff=79VHDL, Verilog, Liberty, EDIF2016-07-07T17:43:32Z<p>107.3.140.142: Created page with "'''Q: I'm using -v, -y, .... After Verific is done with the analysis, how do I get a list of all the files being analyzed?''' Use this code: Array analyzed_files ; // Array..."</p>
<hr />
<div>'''Q: I'm using -v, -y, .... After Verific is done with the analysis, how do I get a list of all the files being analyzed?'''<br />
<br />
Use this code:<br />
<br />
Array analyzed_files ; // Array to store file-names<br />
unsigned file_id = 1 ; // File-id starts from 1<br />
char *file_name = 0 ;<br />
while ((file_name = LineFile::GetFileNameFromId(file_id++))) {<br />
analyzed_files.InsertLast(file_name) ;<br />
}<br />
// Now analyzed_files array should contain all the files analyzed<br />
<br />
How this works:<br />
<br />
# Verific keeps file_name vs. file_id mapping.<br />
# File_id starts from 1 and increases by 1.<br />
# LineFile::GetFileNameFromId() returns 0 for non-existing id.<br />
# The code keeps calling the API with increnemted file_id until getting a 0.<br />
<br />
You may want to use LineFile::GetAbsFileNameFromId() API instead of LineFile::GetFileNameFromId() if you need absolute filenames (with full path).<br />
<br />
<br />
'''Q: While looking at a Netlist, is there a clean way to look back at what VeriModule* or VhdlPrimaryUnit* this netlist was derived from? '''<br />
<br />
For example, a module:<br />
<br />
module mod();<br />
parameter WIDTH=2;<br />
...<br />
endmodule<br />
<br />
would elaborate to a netlist name \mod(WIDTH=2) or if instantiated with a different width \mod(WIDTH=4)<br />
<br />
There are "system" attributes attached to the Netlist that you may find useful. Note the leading space:<br />
<br />
:key: " language", value: one of "verilog" "vhdl".<br />
:key: " cell_name", value: original module/unit name. <br />
<br />
See also Netlist::CellBaseName().<br />
<br />
Once you get the original name of the module/unit, you can search the parse tree for it.<br />
<br />
<br />
'''Q: Why are the ports in original Verilog file renamed to p1, p2, ....?'''<br />
<br />
Input file:<br />
module foo ( datain[0], datain[0] /* same net into multiple port expression */,<br />
datain[2:1] /* part-select port expression */,<br />
/* empty port expression */,<br />
{datain[2],datain[1], datain[1]} /* concatenation in port expression */<br />
) ;<br />
input [2:0] datain ;<br />
...<br />
endmodule<br />
<br />
Output netlist:<br />
module foo (p1, p2, p3, , p7); // test.v(1[8:11])<br />
input p1; // test.v(6[17:23])<br />
input p2; // test.v(6[17:23])<br />
input [1:0]p3;<br />
input [2:0]p7;<br />
... <br />
endmodule<br />
<br />
<br />
The items in the () after the module name are not "port names," rather, they are "port expressions." Verilog defines that the port expressions on this module CANNOT be accessed by name (only by order). This means you cannot rely on the port names to be one thing or another. <br />
<br />
Verific chose to not adjust to any particular naming scheme for complex port expressions, which also allows us to error out if named port instantiation occurs where the language disallows it.<br />
<br />
The original port expression of the renamed port is saved as attributes " orig_port_name" attached to the port.<br />
<br />
key: " orig_port_name", value: port expression<br />
<br />
For the testcase above:<br />
<br />
input p1 /* verific orig_port_name=datain[0] */ ;<br />
input p2 /* verific orig_port_name=datain[0] */ ;<br />
input [1:0]p3 /* verific orig_port_name=datain[2] datain[1] */ ;<br />
input [2:0]p7 /* verific orig_port_name=datain[2] datain[1] datain[1] */ ;<br />
<br />
<br />
<br />
'''Q: I have a design consisting of a mixture of Verilog 2001 and SystemVerilog input files. Should I parse all the files as SystemVerilog?'''<br />
<br />
<br />
The set of SystemVerilog constructs is a superset of the set of Verilog 2001 constructs. As a corollary, the set of SystemVerilog keywords is a superset of the set of Verilog 2001 keywords.<br />
<br />
Parsing a Verilog 2001 file as SystemVerilog will work, as long as the file does not use any SystemVerilog keyword as identifier. If you parse the file as SystemVerilog an run into a syntax error, try parsing it as Verilog 2001.<br />
<br />
Another significant difference between Verilog 2001 and SystemVerilog is "compilation units." The default mode of Verilog 2001 is "multi-file" while the default mode of SystemVerilog is "single-file." For more details, please read:<br />
<br />
http://www.verific.com/docs/index.php?title=Single/Multi-File_Compilation_Units<br />
<br />
'''Q: A customer wants to analyze/elaborate different VHDL flavors (1993 and 2008). They want to process the 93 files first and then the 08. As each flavor has its own IEEE library set, do you have any suggestion on how to handle this scenario?'''<br />
<br />
A:<br />
Please load the 2008 version of the IEEE library distributed by Verific and then analyze the 1993 and 2008 design files in their proper dialect. Verific will internally adjust the packages and both the designs should compile without any errors.<br />
For example:<br />
<br />
setvhdllibrarypath -default verific_source/vhdl_packages/vdbs_2008<br />
analyze test93.vhdl<br />
analyze -vhdl_2008 test2008.vhdl<br />
<br />
For more details, see http://www.verific.com/w/index.php/VHDL-1993_versus_VHDL-2008_IEEE_packages</div>107.3.140.142https://www.verific.com/faq/index.php?title=Main_Page&diff=78Main Page2016-07-07T17:02:51Z<p>107.3.140.142: </p>
<hr />
<div>Note: This page is under construction.<br />
<br />
* [[General]]<br />
* [[VHDL, Verilog, Liberty, EDIF]]<br />
* [[Output]]<br />
* [[TCL, Perl, Python, Java]]</div>107.3.140.142https://www.verific.com/faq/index.php?title=General&diff=77General2016-07-07T16:58:43Z<p>107.3.140.142: </p>
<hr />
<div>'''Q: How do I know what language a Netlist in the netlist database comes from?'''<br />
<br />
Use attribute " language" (note the leading space):<br />
<br />
Netlist *nl;<br />
nl->GetAttValue(" language") <br />
<br />
returns one of "vhdl", "verilog", "edif", "synlib".<br />
<br />
<br />
'''Q: What are the data structures in Verific?'''<br />
<br />
There are 2 data structures in Verific: parsetree and netlist database.<br />
<br />
1. The parsetree is just another representation of the design. It contains the exact information as in the RTL files, only in a machine-readable format. Because each language (Verilog or VHDL) has its own constructs, each language has its own parsetree.<br />
<br />
The parsetree is the result of veri_file::Analyze()/vhdl_file::Ananlyze().<br />
<br />
The design parsetree can be "statically elaborated." These are some of the<br />
operations during static elaboration process:<br />
<br />
- Unrolling "generate" loops.<br />
- Evaluating constant expressions.<br />
- Uniquifying instances of parameterized modules/entities.<br />
<br />
The result of static elaboration is a modified parsetree.<br />
<br />
The parsetree supports all constructs of the language.<br />
<br />
2. The synthesizable subset of the parsetree can go through "RTL elaboration" (or "synthesis"). The result is the "netlist database," consisting of "hardware" components: libraries, cells, netlists, nets, ports, instances, operators (adders, muxes, ...), and primitives (ands, ors, xors, ...). The netlist database is language-independent. The contents of the netlist database can be written out in various structural languages: Verilog, VHDL, EDIF, BLIF. In general, the output netlist from the netlist database does not look anything like the RTL input files.<br />
<br />
The netlist database is the result of veri_file::Elaborate()/vhdl_file::Elaborate() API (after veri_file::Analyze()/vhdl_file::Analyze()).<br />
<br />
RTL elaboration supports the synthesizable subset of the language.<br />
<br />
<br />
'''Q: Does Verific support cross module references (XMR)?'''<br />
<br />
Verific fully supports XMR with "hierarchy tree" feature. Please refer to http://www.verific.com/docs/index.php?title=Hierarchy_Tree<br />
<br />
Without this product feature, support for XMR is full in analysis and static elaboration, and is very limited in RTL elaboration.<br />
<br />
The main reason for limited support in RTL elaboration for XMR is that for Verilog, the order of elaboration of modules is nondeterministic. If module "foo" has not been elaborated, the elaborator will not be able to resolve "foo.bar".<br />
<br />
If the design is within the restricted area and is supported, these runtime flags need to be enabled (set to 1) before design analysis:<br />
<br />
veri_preserve_user_nets<br />
db_preserve_user_nets<br />
db_allow_external_nets</div>107.3.140.142https://www.verific.com/faq/index.php?title=Main_Page&diff=2Main Page2016-06-30T22:50:12Z<p>107.3.140.142: </p>
<hr />
<div>'''This page replaces the Forum page.'''<br />
<br />
'''It will be populated by July 15, 2016 with helpful hints on the use of Verific's parsers, elaborators, and datstructures.'''</div>107.3.140.142