| blob | 861ce8205af4d0cfcb84f1ac32f0a7b50c4a07e3 |
3 <html>
4 <head>
10 </head>
11 <body>
16 Copyright 2000 Stephen Williams
18 The IEEE1364 standard is the bible that defines the correctness of the
19 Icarus Verilog implementation and behavior of the compiled
20 program. The IEEE1364.1 is also referenced for matters of
21 synthesis. So the ultimate definition of right and wrong comes from
22 those documents.
24 That does not mean that a Verilog implementation is fully
25 constrained. The standard document allows for implementation specific
26 behavior that, when properly accounted for, does not effect the
27 intended semantics of the specified language. It is therefore possible
28 and common to write programs that produce different results when run
29 by different Verilog implementations.
32 STANDARDIZATION ISSUES
34 These are some issues where the IEEE1364 left unclear, unspecified or
35 simply wrong. I'll try to be precise as I can, and reference the
36 standard as needed. I've made implementation decisions for Icarus
37 Verilog, and I will make clear what those decisions are and how they
38 affect the language.
40 * OBJECTS CAN BE DECLARED ANYWHERE IN THE MODULE
42 Consider this module:
44 module sample1;
45 initial foo = 1;
46 reg foo;
47 wire tmp = bar;
49 endmodule
51 Notice that the ``reg foo;'' declaration is placed after the first
52 initial statement. It turns out that this is a perfectly legal module
54 statement ``reg foo;'' is a module_item_declaration which is in turn a
55 module_item. The BNF in the appendix of IEEE1364-1995 treats all
56 module_item statements equally, so no order is imposed.
58 Furthermore, there is no text (that I can find) elsewhere in the
59 standard that imposes any ordering restriction. The sorts of
60 restrictions I would look for are "module_item_declarations must
62 textually before they are referenced." Such statements simply do not
63 exist. (Personally, I think it is fine that they don't.)
65 The closest is the rules for implicit declarations of variables that
66 are otherwise undeclared. In the above example, ``bar'' is implicitly
68 is written before foo is declared, foo *is* declared within the
69 module, and declared legally by the BNF of the standard.
71 Here is another example:
73 module sample2;
74 initial x.foo = 1;
75 test x;
77 endmodule
79 module test;
80 reg foo;
81 endmodule;
83 From this example one can clearly see that foo is once again declared
84 after its use in behavioral code. One also sees a forward reference of
85 an entire module. Once again, the standard places no restriction on
86 the order of module declarations in a source file, so this program is,
87 according to the standard, perfectly well formed.
89 Icarus Verilog interprets both of these examples according to "The
90 Standard As I Understand It." However, commercial tools in general
91 break down with these programs. In particular, the first example
92 may generate different errors depending on the tool. The most common
93 error is to claim that ``foo'' is declared twice, once (implicitly) as
94 a wire and once as a reg.
96 So the question now becomes, "Is the standard broken, or are the tools
97 limited?" Coverage of the standard seems to vary widely from tool to
98 tool so it is not clear that the standard really is at fault. It is
99 clear, however, that somebody goofed somewhere.
101 My personal opinion is that there is no logical need to require that
102 all module_item_declarations precede any other module items. I
103 personally would oppose such a restriction. It may make sense to
104 require that declarations of variables within a module be preceded by
105 their use, although even that is not necessary for the implementation
106 of efficient compilers.
108 However, the existence hierarchical naming syntax as demonstrated in
109 sample2 can have implications that affect any declaration order
110 rules. When reaching into a module with a hierarchical name, the
111 module being referenced is already completely declared (or not
112 declared at all, as in sample2) so module_item order is completely
114 ordering, by requiring that modules that are used be first defined.
117 * TASK AND FUNCTION PARAMETERS CANNOT HAVE EXPLICIT TYPES
119 Consider a function negate that wants to take a signed integer value
120 and return its negative:
122 function integer negate;
124 negate = -val;
125 endfunction
127 This is not quite right, because the input is implicitly a reg type,
128 which is unsigned. The result, then, will always be a negative value,
129 even if a negative val is passed in.
131 It is possible to fix up this specific example to work properly with
133 needed is clarification on whether an input can be declared in the
134 port declaration as well as in the contained block declaration.
136 As I understand the situation, this should be allowed:
138 function integer negate;
141 negate = -val;
142 endfunction
144 In the -1995 standard, the variable is already implicitly a reg if
145 declared within a function or task. However, in the -2000 standard
146 there is now (as in this example) a reason why one might want to
147 actually declare the type explicitly.
149 I think that a port *cannot* be declared as an integer or time type
150 (though the result can) because the range of the port declaration must
151 match the range of the integer/time declaration, but the range of
152 integers is unspecified. This, by the way, also applies to module
153 ports.
155 With the above in mind, I have decided to *allow* function and task
156 ports to be declared with types, as long as the types are variable
157 types, such as reg or integer. Without this, there would be no
158 portable way to pass integers into functions/tasks. The standard does
159 not say it is allowed, but it doesn't *disallow* it, and other
160 commercial tools seem to work similarly.
163 * ROUNDING OF TIME
165 When the `timescale directive is present, the compiler is supposed to
166 round fractional times (after scaling) to the nearest integer. The
167 confusing bit here is that it is apparently conventional that if the
168 `timescale directive is *not* present, times are rounded towards zero
169 always.
172 * VALUE OF X IN PRIMITIVE OUTPUTS
175 symbols is allowed in input columns, but is not allowed in
176 outputs. Furthermore, none of the examples have an x in the output of
180 output_symbol characters. The standard is self contradictory. So I
181 take it that x is allowed, as that is what Verilog-XL does.
184 * REPEAT LOOPS vs. REPEAT EVENT CONTROL
186 There seems to be ambiguity in how code like this should be parsed:
190 There are two valid interpretations of this code, from the
191 IEEE1364-1995 standard. One looks like this:
193 procedural_timing_control_statement ::=
194 delay_or_event_control statement_or_null
196 delay_or_event_control ::=
197 event_control
198 | repeat ( expression ) event_control
201 be executed after the 5th posedge of clk. However, there is also this
202 interpretation:
204 loop_statement ::=
205 repeat ( expression ) statement
209 these are both equally valid interpretations of the example, yet they
210 produce very different results. The standard offers no guidance on how
211 to resolve this conflict, and the IEEE1364-2000 DRAFT does not improve
212 the situation.
214 Practice suggests that a repeat followed by an event control should be
215 interpreted as a loop head, and this is what Icarus Verilog does, as
216 well as all the other major Verilog tools, but the standard does not
217 say this.
219 * UNSIZED NUMERIC CONSTANTS ARE NOT LIMITED TO 32 BITS
221 The Verilog standard allows Verilog implementations to limit the size
222 of unsized constants to a bit width of at least 32. That means that a
224 fact, it is common to limit these values to 32bits. However, a
225 compiler may just as easily choose another width limit, for example
226 64bits. That value is equally good.
228 However, it is not *required* that an implementation truncate at 32
229 bits, and in fact Icarus Verilog does not truncate at all. It will
230 make the unsized constant as big as it needs to be to hold the value
231 accurately. This is especially useful in situations like this;
235 The programmer wants the constant to take on the width of the reg,
236 which in this example is parameterized. Since constant sizes cannot be
237 parameterized, the programmer ideally gives an unsized constant, which
238 the compiler then expands/contracts to match the l-value.
240 Also, by choosing to not ever truncate, Icarus Verilog can handle code
242 particular, any constants that the user does not expect to be
243 arbitrarily truncated by his compiler will also not be truncated by
244 Icarus Verilog, no matter what that other compiler chooses as a
245 truncation point.
248 * UNSIZED EXPRESSIONS AS PARAMETERS TO CONCATENATION {}
250 The Verilog standard clearly states in 4.1.14:
252 "Unsized constant numbers shall not be allowed in
253 concatenations. This is because the size of each
254 operand in the concatenation is needed to calculate
255 the complete size of the concatenation."
261 exactly the same so far as the compiler is concerned.
263 Unfortunately, Cadence seems to feel otherwise. In particular, it has
265 is accepted. Further testing shows that any expression other then a
266 simple unsized constant is accepted there, even if all the operands of
267 all the operators that make up the expression are unsized integers.
269 This is a semantic problem. Icarus Verilog doesn't limit the size of
272 "The number of bits that make up an unsized number
273 (which is a simple decimal number or a number without
275 [emphasis added]
277 Icarus Verilog will hold any integer constant, so the size will be as
279 more. With this in mind, what is the value of these expressions?
281 {'h1_00_00_00_00}
286 These examples show that the standard is justified in requiring that
287 the operands of concatenation have size. The dispute is what it takes
288 to cause an expression to have a size, and what that size is.
291 created, but how wide is the adder when adding unsized constants?
296 operand to a concatenation is not a violation of the letter of the
297 law. However, the very next sentence of the quote expresses the
299 seems to be a violation of that intent.
301 Whatever a compiler decides the size is, the user has no way to
303 any differently then (16). Therefore, Icarus Verilog takes the
304 position that such expressions are *unsized* and are not allowed as
305 operands to concatenations. Icarus Verilog will in general assume that
306 operations on unsized numbers produce unsized results. There are
307 exceptions when the operator itself does define a size, such as the
308 comparison operators or the reduction operators. Icarus Verilog will
309 generate appropriate error messages.
312 * MODULE INSTANCE WITH WRONG SIZE PORT LIST
314 A module declaration like this declares a module that takes three ports:
316 module three (a, b, c);
317 input a, b, c;
318 reg x;
319 endmodule
321 This is fine and obvious. It is also clear from the standard that
322 these are legal instantiations of this module:
324 three u1 (x,y,z);
325 three u2 ( ,y, );
326 three u3 ( , , );
327 three u4 (.b(y));
329 In some of the above examples, there are unconnected ports. In the
330 case of u4, the pass by name connects only port b, and leaves a and c
331 unconnected. u2 and u4 are the same thing, in fact, but using
332 positional or by-name syntax. The next example is a little less
333 obvious:
335 three u4 ();
337 The trick here is that strictly speaking, the parser cannot tell
338 whether this is a list of no pass by name ports (that is, all
339 unconnected) or an empty positional list. If this were an empty
340 positional list, then the wrong number of ports is given, but if it is
341 an empty by-name list, it is an obviously valid instantiation. So it
342 is fine to accept this case as valid.
344 These are more doubtful:
346 three u5(x,y);
347 three u6(,);
349 These are definitely positional port lists, and they are definitely
350 the wrong length. In this case, the standard is not explicit about
351 what to do about positional port lists in module instantiations,
352 except that the first is connected to the first, second to second,
353 etc. It does not say that the list must be the right length, but every
354 example of unconnected ports used by-name syntax, and every example of
355 ordered list has the right size list.
357 Icarus Verilog takes the (very weak) hint that ordered lists should be
358 the right length, and will therefore flag instances u5 and u6 as
359 errors. The IEEE1364 standard should be more specific one way or the
360 other.
362 * UNKNOWN VALUES IN L-VALUE BIT SELECTS
364 Consider this example:
368 [...]
369 vec[idx] = 1;
371 So long as the value of idx is a valid bit select address, the
372 behavior of this assignment is obvious. However, there is no explicit
373 word in the standard as to what happens if the value is out of
374 range. The standard clearly states the value of an expression when the
375 bit-select or part select is out of range (the value is x) but does
376 not address the behavior when the expression is an l-value.
378 Icarus Verilog will take the position that bit select expressions in
379 the l-value will select oblivion if it is out of range. That is, if
380 idx has a value that is not a valid bit select of vec, then the
381 assignment will have no effect.
384 * SCHEDULING VALUES IN LOGIC
386 The interaction between blocking assignments in procedural code and
387 logic gates in gate-level code and expressions is poorly defined in
388 Verilog. Consider this example:
390 reg a;
391 reg b;
392 wire q = a & b;
394 initial begin
395 a = 1;
396 b = 0;
398 if (q !== 0) begin
400 $finish;
401 end
402 end
404 This is a confusing situation. It is clear from the Verilog standard
405 that an assignment to a variable using a blocking assign causes the
406 l-value to receive the value before the assignment completes. This
407 means that a subsequent read of the assigned variable *must* read back
408 what was blocking-assigned.
411 gate logic between a/b and q. The standard does not say whether a read
412 out of logic should read the value computed from previous assigns to
415 value or the existing value?
417 In fact, existing commercial tools do it both ways. Some tools print
418 the FAILED message in the above example, and some do not. Icarus
419 Verilog does not print the FAILED message in the above example,
420 because the gate value change is *scheduled* when inputs are assigned,
421 but not propagated until the thread gives up the processor.
423 Icarus Verilog chooses this behavior in order to filter out zero-width
424 pulses as early as possible. The implication of this is that a read of
425 the output of combinational logic will most likely *not* reflect the
426 changes in inputs until the thread that changed the inputs yields
427 execution.
430 * BIT AND PART SELECTS OF PARAMETERS
432 Bit and part selects are supposed to only be supported on vector nets
433 and variables (wires, regs, etc.) However, it is common for Verilog
434 compilers to also support bit and part select on parameters. Icarus
435 Verilog also chooses to support bit and part selects on parameter
436 names, but we need to define what that means.
438 A bit or a part select on a parameter expression returns an unsigned
439 value with a defined size. The parameter value is considered be a
440 constant vector of bits foo[X:0]. That is, zero based. The bit and
441 part selects operate from that assumption.
443 Verilog 2001 adds syntax to allow the user to explicitly declare the
445 (or should) use the explicitly declared vector dimensions to interpret
446 bit and part selects.
449 * EDGES OF VECTORS
451 Consider this example:
454 always @(posedge clock) [do stuff]
456 The IEEE1364 standard clearly states that the @(posedge clock) looks
457 only at the bit clock[0] (the least significant bit) to search for
458 edges. It has been pointed out by some that Verilog XL instead
460 reduction or of the vector. Cadence Design Systems technical support
461 has been rumored to claim that the IEEE1364 specification is wrong,
462 but NC-Verilog behaves according to the specification, and thus
463 different from XL.
465 Icarus Verilog, therefore, takes the position that the specification
466 is clear and correct, and it behaves as does NC-Verilog in this
467 matter.
470 * REAL VARIABLES IN $dumpoff DEAD-ZONES
472 The IEEE1364 standard clearly states that in VCD files, the $dumpoff
473 section checkpoints all the dumped variables as X values. For reg and
474 wire bits/vectors, this obviously means 'bx values. Icarus Verilog
475 does this, for example:
477 $dumpoff
478 x!
479 x"
480 $end
482 Real variables can also be included in VCD dumps, but it is not at
483 all obvious what is supposed to be dumped into the $dumpoff-$end
485 variables to the dead-zone value of 0.0, whereas other tools, such as
486 ModelTech, ignore real variables in this section.
488 For example (from XL):
490 $dumpoff
491 r0 !
492 r0 "
493 $end
495 Icarus Verilog dumps NaN values for real variables in the
496 $dumpoff-$end section of the VCD file. The NaN value is the IEEE754
497 equivalent of an unknown value, and so better reflects the unknown
498 (during the dead zone) status of the variable, like this:
500 $dumpoff
501 rNaN !
502 rNaN "
503 $end
505 It turns out that NaN is conventionally accepted by scanf functions,
506 and viewers that support real variables support NaN values. So while
507 the IEEE1364 doesn't require this behavior, and given the variety that
508 already seems to exist amongst VCD viewers in the wild, this behavior
509 seems to be acceptable according to the standard, is a better mirror
510 of 4-value behavior in the dead zone, and appears more user friendly
511 when viewed by reasonable viewers.
515 $Log: ieee1364-notes.txt,v $
517 Spelling fixes.
520 Make some effort to preserve bits while
521 operating on constant values.
524 NaN in dead zones of VCD dumps.
527 Edge of vectors notes.
530 Support parameters with defined ranges.
533 Spelling patch (Larry Doolittle)
536 Support selecting bits from parameters.
539 Notes about scheduling
542 Handle x in l-value of set/x
545 Accept empty port lists to module instantiation.
548 I allow function ports to have types.
551 Rant about bit widths.
554 Resolve repeat ambiguity in favor of loop.
557 repeat loops ambiguity.
560 rounding of time and x in primitives.
563 Integer parameter comments.
566 Document ieee1364 issues.</pre>
568 </div>
569 </body>
570 </html>