| Add Proposal | Add Analysis | Edit Class, Environment, or Release |
| Number | 372
|
| Category | errata
|
| Synopsis | 13: Errata on Verilog configurations
|
| State | open
|
| Class | errata-discuss
|
| Arrival-Date | Jun 26 2003
|
| Originator | Hemant Gupta <hgupta@cadence.com>
|
| Release | 2001b: 13.1-13.4
|
| Environment |
|
| Description |
Hi, I would like to submit the following errata on Verilog Configs. regards, Hemant. Section 13.1 ------------ 1. The LRM does not mention about configuring instance arrays and generated instantiations. Also, as per the BNF (Syntax 13-6), it is illegal to configure an element of an instance array/generate block because "inst_name" can contain "instance_identifier", only. 2. It can be clarified, if a instance configured by a configuration can be bound to a Verilog module/macromodule/config or can it be bound to a Verilog primitive cell, too. Similarly, can an instance, whose cell name is that of a primitive, be configured, so as to be bound to a Verilog module/macromodule/config. eg As per BNF (Syntax 13-1), the following is illegal because "buf" is not a "cell_identifier". instance top.i1 use buf; Section 13.2 ------------ 1. The BNF(Syntax 13-2) refers to -incdir which is not defined in the LRM. It seems to refer to the directories to be searched for a filename specified in the "file_path_spec". If yes, then if the "file_path_spec" is a relative/absolute path, then is it a warning/ error to specify -incdir. 2. It can be clarified if a Verilog comment /*...*/ can be embedded in a "file_path_spec". If yes, then it cannot be distinguished if, eg. ./*.vg*/, has embedded comments or a path with wildcards. An option can be to mandate the quoting of "file_path_spec" so that it, also, consistent with Syntax 19-6 for `include. Section 13.3 ------------ 1. The BNF (Syntax 13-4) does not mandate a semi-colon after the config_rule_statement. Given the syntax of other configuration statements, namely, config and design_statement, it would be consistent to have a semi-colon as the terminating character for the config_rule_statement, too. 2. It can be clarified that there can be only one design_statement per configuration and there can be multiple top-level modules. 3. It can be clarified that the term selection clause refers to the "inst_clause" and "cell_clause". Similarly, the term expansion clause can be clarified to refer to the "liblist_clause" and "use_clause". 4. If it has been determined, at the end of binding phase, that a selection clause is not used, because the corresponding inst_name/ cell_identifier is non-existent, then should it be a warning or an error or should it be silently skipped. The same can be extended to the case where more than one inst_clause/cell_clause configure the same instance/cell. 5. The preference between inst_clause and cell_clause can be clarified. Ideally, the inst_clause should be preferred over a cell_clause. 6. Also, consider a case where cell "foo" is bound to instance "a1" using the inst_clause, "instance a1 cell foo". Now, if there is, also, a cell_clause corresponding to cell "foo" (cell foo use aLib. bar), then should the cell clause be followed after the inst_clause has been followed, so as bind cell "bar" to instance "a1". If not, then this can be clarified with respect to Section 13.3.1.4, "... the selection rule applies to any instance which is bound..." 7. It seems that the sentence in Section 13.3.1.5, "liblists are inherited hierarchically downward as instances are bound." needs to be clarified. Does it mean that if the parent has been configured through a liblist (either liblist following the selection clauses or default clause) the liblist will be inherited? Also, does the inherited liblist get "appended" to liblist following the selection clauses as well as the default clause? 8. Again, as per Section 13.3.1.5, "If no library list clause is selected, or the library list is empty,...(i.e.,the parent cell's library." Does the phrase "no library list clause" include the inherited liblist which is "appended" to the liblist clause following the selection clause. Consider the following configuration statements with respect to points 7 and 8 above- default liblist aLib; cell foo liblist gateLib; Now, if the inherited liblist contains "rtlLib" and the cell being configured, "foo", does not exist in either "gateLib" or "rtlLib", should the library search order be gateLib->rtlLib->aLib->rtlLib. And, if the parent cell' library is "bLib" should the library search order be gateLib->rtlLib->aLib->rtlLib->bLib or should bLib not be searched because a library list clause has been "selected", though not bound. 9. If an instance name being configured matches an inst_clause and if the corresponding cell, specified by the use_clause, is not found then whether it should be a warning/error or should the inst_clause be simply skipped silently. The same should apply to the cell_clause too. 10. In case of hierarchical configurations, it can be clarified that if a configuration is bound to a subsection of the design by another configuration, then whether it should be a warning/error or not, if the sub-configuration has more than one design top modules in the design clause. Section 13.4 ------------ 1. In Section 13.4.4, "In the single-pass use-models, the ...in the rest of the source files" may not be true for hierarchical configs. A user would need to specify a configuration name to distinguish it from, possibly, sub-configurations in the same file. |
| Fix |
|
| Audit-Trail |
|
| Unformatted |
|
Hosted by Boyd Technology