From: Anders Nordstrom (andersn@nortelnetworks.com)
Date: Tue Sep 05 2000 - 06:02:52 PDT
Dear BTF Members,
This is the feedback we are going to discuss at the BTF Conference
call later this week. Please review it and reply via email or be at the
call.
Thanks,
Anders
<p><p>"Clifford E. Cummings" wrote:
> Kurt & Anders -
>
> Kurt, I could use your help to pull generate statements and constant
> functions out of the fire again!!
>
> We received 6 no-votes on the Verilog Standard, not enough to vote it down,
> but it does mean we have to re-circulate a ballot with responses. Five of
> the no votes were from Cadence engineers, including Charles Dawson, who was
> on the Standards Group. There is concern that Cadence is back-peddling on
> their support of the new Verilog Standard.
>
> Maq is concerned that after we re-circulate the ballot, that even engineers
> that voted yes, will see the block of Cadence no-votes and change their
> votes from yes to no.
>
> Attached are the comments from the Cadence engineers. Could you both
> possibly attend a conference call Friday afternoon with the Cadence
> engineers, to help explain why the features are so important to us? The
> call and call time are not yet set, and I might ask Anders to set up the
> call through Nortel Audio Conferencing on short notice, but I need to know
> your availability (both of you).
>
> Thanks in advance.
>
> Regards - Cliff
>
> ======================================
>
> To Whom It May Concern:
>
> The following comments are the same as those sent by the following voters:
>
> Charles Dawson
> Steven J. Dovich
> Francoise Martinolle
> Uma P. Parvathy
> Girish S. Rao
>
> Satisfying the requirements of the other voters with these comments will not
> constitute an implicit acceptance on my part.
>
> ----------------------------------------------------------------------------
> ---
> ----------------------------------------------------------------------------
> ---
>
> Section 2.8 Page 15
>
> The last line says:
>
> For attributes that can be attached to both module definitions and
> module instantiations, the attribute value associated with the module
> instantiation shall override the attribute value associated with the
> module definition.
>
> Why should the standard define the use model for attributes? There can be
> cases when the module definition attribute should override the one on the
> module instantiation. Here is an example:
>
> Suppose there is an attribute for placement information and the
> module definition was for an IO PAD (which are always at chip edges)
> If the module instantiation chose to override this attribute value with
> anything else, the tool which uses these attributes would consider that
> an error.
>
> I think that it should be up to the tool that uses these attributes for
> processing to determine the use model.
>
> ----------------------------------------------------------------------------
> ---
>
> Section 2.8 Page 15
>
> The next to last line line says that an attribute value can be either
> true or false. The BNF says that the attribute can be assigned any
> constant expression. Which of these is correct? See examples 6 and 7 in
> section 2.8.1 (page 17)
>
> ----------------------------------------------------------------------------
> ---
>
> Section 2.8 Page 15
>
> If inheritance is to be defined in the standard, what is defined for the
> following case for the input wire "in" and the iodecl "in"?
>
> module test(in);
> input (* integer foo = 0; *) in;
> wire (* integer foo = 3; *) in;
>
> Verilog tools should be allowed to define the method for distinguishing
> between the two declarations.
>
> ----------------------------------------------------------------------------
> ---
>
> Section 2.8.1 Page 16
>
> There are typos in the first example:
>
> parallee_case
>
> should be
>
> parallel_case
>
> ----------------------------------------------------------------------------
> ---
>
> Section 3.12
>
> To which name space does the configuration names belong?
> What is the name space for attributes?
>
> The first paragraph last line of this section says:
>
> Once a name is used to define a module, macromodule, or primitive,
> the name shall not be used again to define another module, macromodule,
> or primitive.
>
> This no longer holds true if you use configurations.
>
> The name space for configurations should be specified.
>
> ----------------------------------------------------------------------------
> ---
>
> Section 9.2.2 Page 128
>
> The paragraph after example 3 says:
> When multiple non-blocking assignments are scheduled to occur *in* the same
> variable in a particular time slot, the order in which the assignments are
> evaluated in not guaranteed--the final value is indeterminate.
>
> Section 5.4.1 guarantees the order in which the non-blocking assignments
> occur. Also note the typo.
>
> Perhaps you need to reword Section 9.2.2 to say:
>
> When multiple non-blocking assignments with timing controls are
> scheduled to occur to the same variable in a particular time slot, the
> order in which the assignments are evaluated in not guaranteed--the
> final value is indeterminate.
>
> ----------------------------------------------------------------------------
> ---
>
> Section 9.7.5 Page 144
>
> The main problem is that it is based on a common misconception about
> always blocks, fostered by the synthesis tools. Many people read
>
> always @(a or b)
> c = a & b;
>
> as "Always when a or b changes, do assignment". This is actually
> "Repetitively do statement", where statement is "wait for a or b to change,
> then do assignment". The event control is not attached to the "always", it
> is attached to the assignment. It is not clear to what this new combinational
> sensitivity list is attached. If it is attached to the "always" and can
> only appear immediately after "always", then it presumably includes everything
> read inside the always block. The problem with this is that it follows
> different rules from a normal event control, which can appear on any
> statement or as an intra-assignment delay. If it is attached to the statement
> like an event control, then it presumably includes sensitivity to everything
> read by the statement (or right-hand side expression for an intra-assignment
> delay). This is likely to be confusing to designers who don't really
> understand that event controls are attached to statements, not to always
> blocks. For example
>
> always @(a or b)
> begin
> c = a;
> d = b;
> end
>
> is equivalent to
>
> always
> begin @(a or b)
> c = a;
> d = b;
> end
>
> however
>
> always @* // equivalent to @(a or b), because attached to begin-end
> begin
> c = a;
> d = b;
> end
>
> would not be equivalent to
>
> always
> begin @* // equivalent to @(a), because attached to c = a;
> c = a;
> d = b;
> end
>
> The introduction of this construct may also lead designers further into
> thinking that an always block with a combinational sensitivity list is
> equivalent to a continuous assignment. Many designers believe that an always
> block containing a delay will trigger again if the event control occurs again
> while the block is waiting for the delay. E.g. they believe that
>
> always @(a or b)
> c = #(5) a & b;
>
> or perhaps
>
> always @(a or b)
> #(5) c = a & b;
>
> is equivalent to
>
> assign #(5) c = a & b;
>
> which is not correct. The continuous assignment will behave like
> combinational
> logic, re-evaluating whenever the inputs change. Output pulses narrower than
> #5 will be filtered due to event cancellation, but the final result after the
> inputs settle will be correct. In the first "always" case, changes to the
> inputs within #5 of the first change will not be seen, and the expression will
> not be re-evaluated. The final result may be wrong as a result. In the
> second "always" case, the final result should be correct, but the propagation
> delay for changes after the first will be strange. Adding a new mysterious
> shorthand and calling it a combinational sensitivity list may further lead
> designers into thinking that the results will be the same as combinational
> logic.
>
> For more complex always blocks, it is also unclear what should go into
> the implied sensitivity list. Presumably something used in a bit select
> index or memory address on the left-hand side should be included, though
> it does not appear on the right hand side. Are output arguments from tasks
> included? What about inout arguments? What about values used as counts
> in repeat loops? What about values used as repeat counts in event repeats
> for intra-assignment delays? What about values used to calculate variable
> delays for delay controls? What about temporary variables assigned and
> then used within the always block? For a more extreme case of that, what
> about the index variable of a for-loop within the block, which is read every
> time it is incremented and compared, but which never gets its value from
> outside the always block? Note that there is no way of detecting and
> excluding such variables in the general case. Note that there may also
> be a performance cost to being sensitive to extra signals. If the block
> has side effects, any ambiguity in what should go into the lists could
> create simulation differences between implementations.
>
> Section 9.7.5 should be removed from the standard.
>
> ----------------------------------------------------------------------------
> ---
>
> Section 10.2.3 Page 159
>
> I have several issues with the reentrant task enhancement:
>
> 1) There are no known applications for it's use. Further, the equivalent
> functionality can be expressed with existing constructs
> (ie. instantiating a module containing the task). Therefore, the
> enhancement is not needed.
> 2) Automatic variables are dynamic, which causes significant problems for
> PLI. Specifically, all VPI handles to objects are considered to be
> permanent, except for objects within reentrant tasks. The VPI support
> for this feature seems to be adequately defined, however I expect that
> the implementation will be difficult and awkward.
> 3) The dynamic nature of automatic variables also causes problems with
> various Verilog constructs. Some of these constructs have been
> forbidden from them as a result (e.g. non-blocking assignments). This
> is an indication of poor language design. The need to add all of these
> restrictions shows that the construct does not fit into the language.
>
> The set of changes which specify reentrant tasks should be removed from
> the standard.
>
> ----------------------------------------------------------------------------
> ---
>
> Section 10.3.5
>
> Constant functions are another example of how a VHDL concept does
> not map well into Verilog.
>
> They have basically the same set of language issues as generate
> statements. The Verilog language is simply too powerful and unrestricted
> to support such functionality.
>
> The best solution is to remove the concept altogether. Absent that,
> here are some specific low-level issues that need be resolved:
>
> 1) Functions which have a control path in which the function
> return value is not set can inherit the value of a previous
> call. These functions cannot be considered to be constant
> (and yet do meet all of the specified requirements in section
> 10.3.5). An example is provided below.
>
> function [0:31]f;
> input [0:31]in;
> begin
> case (in)
> 0: f = 0;
> 1: f = 1;
> 2:;
> endcase
> end
> endfunction
>
> 2) The specification that the only allowable system task is $display
> is absurd. What about $fdisplay? Or $displayb? Or $displayh?
> Or $displayo? Or $write for that matter? What is special
> about $display?
>
> The set of changes which specify constant functions should be removed
> from the standard.
>
> ----------------------------------------------------------------------------
> ---
>
> Section 12.1.3
>
> I would like to comment broadly on the generate statement (as defined
> under "Generate instantiation" in Section 12.1.3) in three parts:
>
> 1) Is the construct appropriate for the language?
>
> The proposed "generate" construct marks such a major departure from
> the rest of the Verilog language that it is reasonable to consider
> whether the construct itself is appropriate.
>
> It's difficult not to begin with the simple comment that Verilog
> is not VHDL.
>
> The fact that a construct exists within VHDL is neither a sufficient
> reason - nor even a good indication - that it should be added
> to the Verilog language.
>
> The two languages have their own individual look, feel and
> self-consistency. What is appropriate in one, does not necessary
> have any business whatsoever in the other.
>
> Much of the appeal of Verilog, much of what has made it the
> predominate hardware description language is that it has taken
> a clean minimalist approach. (Much as C has triumphed over the
> well-meaning, but overly-cluttered ADA).
>
> So before adding any construct to Verilog, it is important to
> determine that the construct is both necessary and consistent
> with the rest of the language; otherwise the language as a whole
> is degraded. It is difficult to accept that the generate construct
> meets these criteria.
>
> Moreover, one must consider the negative impact that this construct
> will have on tools supporting the Verilog language.
>
> Rather than, as the rest of the language does, describing hardware
> or the behavior thereof, this construct allows the language
> to be used in a completely different way. It allows Verilog to be
> used to describe the generation of Verilog. This is not just
> a new entity within the language, it a completely new process.
>
> It changes all of the rules, assumptions, and conventions that
> previously existed within the language. The natural barrier between
> simulation and elaboration has been removed.
>
> The consequence of this will be that commercial tools based on the
> Verilog HDL will either require massive revision or must choose
> not to support the construct. It seems not unlikely that they will
> choose the latter.
>
>
> 2) Is the construct reasonably defined?
>
> The definition of "generate" attempts to build upon existing
> constructs in the language (for, if, case, ...etc.). The problem
> is that - because this is Verilog and not VHDL - these constructs
> do not properly fit its purpose.
>
> In VHDL, the loop semantics are sufficiently restrictive that
> this may be done. But not surprisingly, this does not map well
> into the Verilog language.
>
> The much more open semantics of the Verilog language result in
> the ability to express a much wider, more varied set of generation
> loops, very nearly all of which are illegal.
>
> In other words, the vast majority of loops which may be expressed
> within the syntax of the language, are not meaningful to this purpose.
>
> The loops only make sense if we impose a set of arbitrary restrictions
> upon them. (That both loop assignmentments must write to the
> same variable, that the variable cannot be assigned within the loop,
> that the variable must be of a special new type, ...etc.)
>
> All of this runs contrary to the logical intuitive feel of the language.
>
> Proper language design should make non-meaningful declarations
> syntactically inexpressible. It should not allow us to express
> any numbers of loops, and then pattern-match to see if we happened
> to understand one.
>
> The generate construct as specified also forces the addition of a
> whole new sub-set of the Verilog language in form of support
> constructs, such as genvar, constant functions and localparam's.
> (Or, more properly a subset of the VHDL language is being introduced
> into Verilog to support this VHDL construct which is being forced
> into the Verilog language).
>
> So what we have is a construct which is cluttered, non-intuitive, and
> inelegant. (Which, not coincidentally, is what one would expect as
> the result of grafting part of one language into another).
>
> Anyone who fully appreciates the importance of proper language
> design should find this implicitly unacceptable.
>
>
> 3) What are the specific low-level technical objections?
>
> Before listing these, it should be pointed out that many of them
> fall out of the objections stated previously. I.e. they are a
> side-effect of the inelegance of the definition. Properly defining
> the construct would obviate the need for many of these objections.
>
> 1) Section 12.1.3.1 defines genvars as "positive integers".
>
> What is meant by this? Is "integer" in this context defined
> as a Verilog integer? Does "positive" mean that they are
> unsigned integers? This needs to be more precisely defined.
>
> 2) Can genvars take undefined values? I.e. can they be X or Z
> as Verilog integers can? (If not, then they are not Verilog
> integers and need to be defined. What is their size, ...etc.).
>
> 3) If genvars cannot be undefined, what is their initial value?
>
> I.e. what would this loop do?
>
> genvar i;
>
> generate for (i=i; i < 2; i = i + 1)
> begin:name
> ...
> end
>
> 4) If genvars can be undefined, what is the behavior of a generate
> loop with an undefined genvar. I.e. what would this loop do:
>
> genvar i;
>
> generate for(i = 1'bx; i !==1; i = 1)
> begin:name
> ...
> end
>
> 5) What happens if the loop never ends? Is there a maximum number
> of instantiations? Is there an error? Does it just hang?
>
> 6) What happens if the loop is executed twice with the same
> genvar value?
>
> 7) What happens if the execution of the loop modifies one of the
> parameters governing its behavior? Especially if the change
> implies that the loop should never have been executed and is
> thus logically inconsistent. I.e. what would this do?
>
> generate for (i=0; i < name[0].p; i = i + 1)
> begin:name
> sub #0 i0();
> end
>
> module sub;
> parameter p = 1;
> endmodule
>
> 8) Why are generated instance identifiers created by adding the
> string "[genvar's value]" to the generate block name?
>
> This seems bad for several reasons:
>
> a) It gives the false impression that there is an array of
> such names when there is not.
>
> b) It is inconsistent with arrays of instances (or any other
> indexing construct in the language).
>
> c) It is ambiguous. There are many ways of representing a
> value as a string. Which is chosen? Is it binary? Hex?
> Integer? Left-justified? Right-justified? Can there
> be Z's or X's within the value? If so, how are they
> represented?
>
> d) It can create (a previously impossible) dynamic name clash.
>
> Say there is an existing instance of something called
> "foo[4]" (this would be represented in the HDL as "\foo[4]",
> but the "\" is not considered part of the name), and an
> instance loop called "foo". The execution of the loop with
> the genvar value of 4, will create a dynamic name clash.
>
> e) It prevents reference of the elements in the blocks in any
> parameterized fashion. This runs counter to the idea that
> the functionality of the generates can be expressed
> algorithmically. What if we wish to reference them by name?
> If we need to know the names, then we need to know the final
> output of the algorithm to know what the generated strings
> will be.
>
> f) Finally, it prevents a generate block from referencing
> another instance of itself. I.e. we cannot do this:
>
> generate for (i=0; i < SIZE; i = i + 1)
> begin:name
> wire out = name[i-1].out + in[i];
> end
>
> The set of changes which specify the generate enhancement should be removed
> from the standard.
>
> ----------------------------------------------------------------------------
> ---
>
> Section 13.3.1.1 Page 207
>
> What if there are multiple top modules in a configuration other than
> the top level configuration? I think it should be an error.
>
> ----------------------------------------------------------------------------
> ---
>
> Section 13.3.1.2 Page 207
>
> The second paragraph, last line says:
>
> For other expansion clauses, there cannot be more that one default clause
> which specifies the expansion clause.
>
> Since, according to the BNF, you cannot have a default clause anywhere
> else, what does this mean?
>
> I think this sentence should be removed.
>
> ----------------------------------------------------------------------------
> ---
>
> Section 13.3.1.6 Page 208
>
> What should be the behavior of an unbound instance? Currently, in both
> Verilog-XL and NC-Verilog it is an error to have unbound instances at the
> end of elaboration.
>
> ----------------------------------------------------------------------------
> ---
>
> Section 13.3.1.6 Page 209
>
> Paragraph 4 says:
>
> If the lib.cell being referred to by the use clause is a
> config which has the same name as a module/macromodule/primitive in the
> same library, then the optional :config suffix can be added to the
> lib.cell to specify the config explicitly.
>
> What is the correct behavior if you have a module and a config of the
> same name in a library?
>
> The precedence rules (i.e. the config is always picked before the module)
> should be specified explicitly.
>
> ----------------------------------------------------------------------------
> ---
>
> Section 13.3.2 Page 209
>
> In the example, does the liblist for config 'bot' override the liblist
> for config 'top' when both of them are specified and the tool is trying
> to bind an instance in 'bot' which does not match any other specific
> clause?
>
> What if there were no liblist specified in config 'bot'? Does it then
> inherit the liblist from config 'top'?
>
> Similarly what are the inheritance rules for the cell clause? Will the
> one on config 'bot' override the one on config 'top'?
>
> The precedence rules should be specified explicitly.
>
> ----------------------------------------------------------------------------
> ---
>
> Section 13.4.4 Page 210
>
> Line 3 says:
>
> In the case where the config includes a design statement, then the specified
> cell shall be the top level module, regardless of the presence of any
> uninstantiated cells in the rest of the source file.
>
> According to the BNF (Syntax 13-4), the design statement is NOT
> optional. If it were optional, then what happens when we have a sub
> configuration (say config 'bot' from section 13.2.2) without a design
> statement?
>
> What should be the behavior of the uninstantiated cells? Do they
> generate warnings/errors for unbound instances if any, or silently hog
> memory?
>
> The design statement should be made optional. Then it should be specified
> what happens if a sub-configuration does not have a design statement.
>
> ----------------------------------------------------------------------------
> ---
>
> Section 13.5.4 Page 212
>
> The last line says:
>
> Since liblist is inherited, all of the descendants of top.a2 inherit
> liblist from the instance selection clause.
>
> Does this mean that for instances below a2, all bindings are done using this
> liblist (until another configuration is hit perhaps?). If not found
> in that liblist, is the instance left unbound?
>
> The precedence rules should be specified explicitly.
>
> ----------------------------------------------------------------------------
> ---
>
> Section 14.6.1
>
> The PLI routines acc_append_delays(), acc_replace_delays(), and
> vpi_put_delays() can cause the pulse error and reject limits to become
> inconsistent. The error conditions behavior needs to be documented.
>
> ----------------------------------------------------------------------------
> ---
>
> Section 16.2.4 Page 280
>
> The fourth paragraph says:
>
> Hierarchically overlapping connections are permitted. This occurs
> when the annotations to or from the same port take place at different
> hierarchical levels and therefore do not correspond to the same
> hierarchical subset of ports.
>
> The last paragraph states:
>
> Overlapping annotations can occur in many different ways, particularly on
> multi-source/multi load nets and SDF annotation shall properly resolve all
> the interactions.
>
> I am not sure what "properly" means and think that it needs to be spelled out.
>
> Think of a scenario like this: (A,B are inputs,C,D are outputs and E,F
> the intermediate ports)
>
> A ----- -------C
> | |
> E|_____ |F
> | |
> | |
> B ----- -------D
>
> You can potentially have interconnect delays
>
> A->E,A->F,A->C,B->E,B->F,B->D ...etc.
>
> What happens if delay(A->E ) > delay(A->C)?
> What if delay(A->F) conflicts with delay(A->E)?
>
> If there are multiple SDF files and if the interconnect is through
> multiple levels of hierarchy, tracking this can be crazy, and I don't
> think you can guarantee that all conflicts will be resolved or that all
> tools which support SDF annotation will do that in the same way. I
> think it would be better to give a error or warning and use the last
> value.
>
> In any case, this feature has no value unless the actual placement of
> the modules follows the same grouping as the HDL hierarchy since
> interconnect delays are only a way to model wire lengths. How likely is
> that?
>
> We should not allow overlapping hierarchical connections. Only pin to
> pin connections should be allowed.
>
> //*****************************************************************//
> // Cliff Cummings Phone: 503-579-6362 //
> // Sunburst Design, Inc. FAX: 503-579-7631 //
> // 15870 SW Breccia Drive E-mail: cliffc@sunburst-design.com //
> // Beaverton, OR 97007 Web: www.sunburst-design.com //
> // //
> // Expert Verilog, Synthesis and Verification Training //
> //*****************************************************************//
Attachment Converted: "C:\Documents and Settings\stefen\Application Data\Qualcomm\Eudora\andersn32.vcf"
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:54:13 PDT
and
sponsored by Boyd Technology, Inc.