General - Revision history

107.3.140.142 at 21:01, 7 July 2016

2016-07-07T21:01:52Z

107.3.140.142 at 20:27, 7 July 2016

2016-07-07T20:27:05Z

107.3.140.142 at 20:25, 7 July 2016

2016-07-07T20:25:54Z

107.3.140.142 at 20:24, 7 July 2016

2016-07-07T20:24:42Z

Hoadinh at 19:57, 7 July 2016

2016-07-07T19:57:03Z

107.3.140.142 at 16:58, 7 July 2016

2016-07-07T16:58:43Z

New page

'''Q: How do I know what language a Netlist in the netlist database comes from?'''

Use attribute " language" (note the leading space):

Netlist *nl;
nl->GetAttValue(" language")

returns one of "vhdl", "verilog", "edif", "synlib".

'''Q: What are the data structures in Verific?'''

There are 2 data structures in Verific: parsetree and netlist database.

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.

The parsetree is the result of veri_file::Analyze()/vhdl_file::Ananlyze().

The design parsetree can be "statically elaborated." These are some of the
operations during static elaboration process:

- Unrolling "generate" loops.
- Evaluating constant expressions.
- Uniquifying instances of parameterized modules/entities.

The result of static elaboration is a modified parsetree.

The parsetree supports all constructs of the language.

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.

The netlist database is the result of veri_file::Elaborate()/vhdl_file::Elaborate() API (after veri_file::Analyze()/vhdl_file::Analyze()).

RTL elaboration supports the synthesizable subset of the language.

'''Q: Does Verific support cross module references (XMR)?'''

Verific fully supports XMR with "hierarchy tree" feature. Please refer to http://www.verific.com/docs/index.php?title=Hierarchy_Tree

Without this product feature, support for XMR is full in analysis and static elaboration, and is very limited in RTL elaboration.

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".

If the design is within the restricted area and is supported, these runtime flags need to be enabled (set to 1) before design analysis:

veri_preserve_user_nets
db_preserve_user_nets
db_allow_external_nets

← Older revision		Revision as of 20:27, 7 July 2016
Line 1:		Line 1:
−	~~'''Bold text~~'''Q: How do I know what language a Netlist in the netlist database comes from?'''	+	'''Q: How do I know what language a Netlist in the netlist database comes from?'''

	Use attribute " language" (note the leading space):		Use attribute " language" (note the leading space):

@@ Line 1: / Line 1: @@
-==Q: How do I know what language a Netlist in the netlist database comes from?==
+'''Bold text'''Q: How do I know what language a Netlist in the netlist database comes from?'''
 Use attribute " language" (note the leading space):
@@ Line 9: / Line 9: @@
-==Q: What are the data structures in Verific?==
+'''Q: What are the data structures in Verific?'''
 There are 2 data structures in Verific: parsetree and netlist database.
@@ Line 35: / Line 35: @@
-==Q: Does Verific support cross module references (XMR)?==
+'''Q: Does Verific support cross module references (XMR)?'''
 Verific fully supports XMR with "hierarchy tree" feature. Please refer to http://www.verific.com/docs/index.php?title=Hierarchy_Tree

@@ Line 43: / Line 43: @@
 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".
-If the design is within the restricted area and is supported, these runtime flags need to be enabled (set to 1) before design analysis:
+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:
      veri_preserve_user_nets
      db_preserve_user_nets
      db_allow_external_nets