| blob | 00ddca7bf991e3ee13137d986e86a20d1e753ba4 |
5 <head>
12 <link rel="search" type="application/opensearchdescription+xml" href="http://geda.seul.org/wiki/lib/exe/opensearch.php" title="geda Wiki" />
14 <link rel="contents" href="http://geda.seul.org/wiki/geda:icarus_ieee1364?do=index" title="Index" />
15 <link rel="alternate" type="application/rss+xml" title="Recent Changes" href="http://geda.seul.org/wiki/feed.php" />
16 <link rel="alternate" type="application/rss+xml" title="Current Namespace" href="http://geda.seul.org/wiki/feed.php?mode=list&ns=geda" />
17 <link rel="alternate" type="text/html" title="Plain HTML" href="http://geda.seul.org/wiki/_export/xhtml/geda:icarus_ieee1364" />
18 <link rel="alternate" type="text/plain" title="Wiki Markup" href="http://geda.seul.org/wiki/_export/raw/geda:icarus_ieee1364" />
22 </head>
23 <body>
28 <h1><a name="icarus_verilog_vs._ieee1364" id="icarus_verilog_vs._ieee1364">Icarus Verilog vs. IEEE1364</a></h1>
31 Copyright 2000 Stephen Williams
33 The IEEE1364 standard is the bible that defines the correctness of the
34 Icarus Verilog implementation and behavior of the compiled
35 program. The IEEE1364.1 is also referenced for matters of
36 synthesis. So the ultimate definition of right and wrong comes from
37 those documents.
39 That does not mean that a Verilog implementation is fully
40 constrained. The standard document allows for implementation specific
41 behavior that, when properly accounted for, does not effect the
42 intended semantics of the specified language. It is therefore possible
43 and common to write programs that produce different results when run
44 by different Verilog implementations.
47 STANDARDIZATION ISSUES
49 These are some issues where the IEEE1364 left unclear, unspecified or
50 simply wrong. I'll try to be precise as I can, and reference the
51 standard as needed. I've made implementation decisions for Icarus
52 Verilog, and I will make clear what those decisions are and how they
53 affect the language.
55 * OBJECTS CAN BE DECLARED ANYWHERE IN THE MODULE
57 Consider this module:
59 module sample1;
60 initial foo = 1;
61 reg foo;
62 wire tmp = bar;
64 endmodule
66 Notice that the ``reg foo;'' declaration is placed after the first
67 initial statement. It turns out that this is a perfectly legal module
69 statement ``reg foo;'' is a module_item_declaration which is in turn a
70 module_item. The BNF in the appendix of IEEE1364-1995 treats all
71 module_item statements equally, so no order is imposed.
73 Furthermore, there is no text (that I can find) elsewhere in the
74 standard that imposes any ordering restriction. The sorts of
75 restrictions I would look for are "module_item_declarations must
77 textually before they are referenced." Such statements simply do not
78 exist. (Personally, I think it is fine that they don't.)
80 The closest is the rules for implicit declarations of variables that
81 are otherwise undeclared. In the above example, ``bar'' is implicitly
83 is written before foo is declared, foo *is* declared within the
84 module, and declared legally by the BNF of the standard.
86 Here is another example:
88 module sample2;
89 initial x.foo = 1;
90 test x;
92 endmodule
94 module test;
95 reg foo;
96 endmodule;
98 From this example one can clearly see that foo is once again declared
99 after its use in behavioral code. One also sees a forward reference of
100 an entire module. Once again, the standard places no restriction on
101 the order of module declarations in a source file, so this program is,
102 according to the standard, perfectly well formed.
104 Icarus Verilog interprets both of these examples according to "The
105 Standard As I Understand It." However, commercial tools in general
106 break down with these programs. In particular, the first example
107 may generate different errors depending on the tool. The most common
108 error is to claim that ``foo'' is declared twice, once (implicitly) as
109 a wire and once as a reg.
111 So the question now becomes, "Is the standard broken, or are the tools
112 limited?" Coverage of the standard seems to vary widely from tool to
113 tool so it is not clear that the standard really is at fault. It is
114 clear, however, that somebody goofed somewhere.
116 My personal opinion is that there is no logical need to require that
117 all module_item_declarations precede any other module items. I
118 personally would oppose such a restriction. It may make sense to
119 require that declarations of variables within a module be preceded by
120 their use, although even that is not necessary for the implementation
121 of efficient compilers.
123 However, the existence hierarchical naming syntax as demonstrated in
124 sample2 can have implications that affect any declaration order
125 rules. When reaching into a module with a hierarchical name, the
126 module being referenced is already completely declared (or not
127 declared at all, as in sample2) so module_item order is completely
129 ordering, by requiring that modules that are used be first defined.
132 * TASK AND FUNCTION PARAMETERS CANNOT HAVE EXPLICIT TYPES
134 Consider a function negate that wants to take a signed integer value
135 and return its negative:
137 function integer negate;
139 negate = -val;
140 endfunction
142 This is not quite right, because the input is implicitly a reg type,
143 which is unsigned. The result, then, will always be a negative value,
144 even if a negative val is passed in.
146 It is possible to fix up this specific example to work properly with
148 needed is clarification on whether an input can be declared in the
149 port declaration as well as in the contained block declaration.
151 As I understand the situation, this should be allowed:
153 function integer negate;
156 negate = -val;
157 endfunction
159 In the -1995 standard, the variable is already implicitly a reg if
160 declared within a function or task. However, in the -2000 standard
161 there is now (as in this example) a reason why one might want to
162 actually declare the type explicitly.
164 I think that a port *cannot* be declared as an integer or time type
165 (though the result can) because the range of the port declaration must
166 match the range of the integer/time declaration, but the range of
167 integers is unspecified. This, by the way, also applies to module
168 ports.
170 With the above in mind, I have decided to *allow* function and task
171 ports to be declared with types, as long as the types are variable
172 types, such as reg or integer. Without this, there would be no
173 portable way to pass integers into functions/tasks. The standard does
174 not say it is allowed, but it doesn't *disallow* it, and other
175 commercial tools seem to work similarly.
178 * ROUNDING OF TIME
180 When the `timescale directive is present, the compiler is supposed to
181 round fractional times (after scaling) to the nearest integer. The
182 confusing bit here is that it is apparently conventional that if the
183 `timescale directive is *not* present, times are rounded towards zero
184 always.
187 * VALUE OF X IN PRIMITIVE OUTPUTS
190 symbols is allowed in input columns, but is not allowed in
191 outputs. Furthermore, none of the examples have an x in the output of
195 output_symbol characters. The standard is self contradictory. So I
196 take it that x is allowed, as that is what Verilog-XL does.
199 * REPEAT LOOPS vs. REPEAT EVENT CONTROL
201 There seems to be ambiguity in how code like this should be parsed:
205 There are two valid interpretations of this code, from the
206 IEEE1364-1995 standard. One looks like this:
208 procedural_timing_control_statement ::=
209 delay_or_event_control statement_or_null
211 delay_or_event_control ::=
212 event_control
213 | repeat ( expression ) event_control
216 be executed after the 5th posedge of clk. However, there is also this
217 interpretation:
219 loop_statement ::=
220 repeat ( expression ) statement
224 these are both equally valid interpretations of the example, yet they
225 produce very different results. The standard offers no guidance on how
226 to resolve this conflict, and the IEEE1364-2000 DRAFT does not improve
227 the situation.
229 Practice suggests that a repeat followed by an event control should be
230 interpreted as a loop head, and this is what Icarus Verilog does, as
231 well as all the other major Verilog tools, but the standard does not
232 say this.
234 * UNSIZED NUMERIC CONSTANTS ARE NOT LIMITED TO 32 BITS
236 The Verilog standard allows Verilog implementations to limit the size
237 of unsized constants to a bit width of at least 32. That means that a
239 fact, it is common to limit these values to 32bits. However, a
240 compiler may just as easily choose another width limit, for example
241 64bits. That value is equally good.
243 However, it is not *required* that an implementation truncate at 32
244 bits, and in fact Icarus Verilog does not truncate at all. It will
245 make the unsized constant as big as it needs to be to hold the value
246 accurately. This is especially useful in situations like this;
250 The programmer wants the constant to take on the width of the reg,
251 which in this example is parameterized. Since constant sizes cannot be
252 parameterized, the programmer ideally gives an unsized constant, which
253 the compiler then expands/contracts to match the l-value.
255 Also, by choosing to not ever truncate, Icarus Verilog can handle code
257 particular, any constants that the user does not expect to be
258 arbitrarily truncated by his compiler will also not be truncated by
259 Icarus Verilog, no matter what that other compiler chooses as a
260 truncation point.
263 * UNSIZED EXPRESSIONS AS PARAMETERS TO CONCATENATION {}
265 The Verilog standard clearly states in 4.1.14:
267 "Unsized constant numbers shall not be allowed in
268 concatenations. This is because the size of each
269 operand in the concatenation is needed to calculate
270 the complete size of the concatenation."
276 exactly the same so far as the compiler is concerned.
278 Unfortunately, Cadence seems to feel otherwise. In particular, it has
280 is accepted. Further testing shows that any expression other then a
281 simple unsized constant is accepted there, even if all the operands of
282 all the operators that make up the expression are unsized integers.
284 This is a semantic problem. Icarus Verilog doesn't limit the size of
287 "The number of bits that make up an unsized number
288 (which is a simple decimal number or a number without
290 [emphasis added]
292 Icarus Verilog will hold any integer constant, so the size will be as
294 more. With this in mind, what is the value of these expressions?
296 {'h1_00_00_00_00}
301 These examples show that the standard is justified in requiring that
302 the operands of concatenation have size. The dispute is what it takes
303 to cause an expression to have a size, and what that size is.
306 created, but how wide is the adder when adding unsized constants?
311 operand to a concatenation is not a violation of the letter of the
312 law. However, the very next sentence of the quote expresses the
314 seems to be a violation of that intent.
316 Whatever a compiler decides the size is, the user has no way to
318 any differently then (16). Therefore, Icarus Verilog takes the
319 position that such expressions are *unsized* and are not allowed as
320 operands to concatenations. Icarus Verilog will in general assume that
321 operations on unsized numbers produce unsized results. There are
322 exceptions when the operator itself does define a size, such as the
323 comparison operators or the reduction operators. Icarus Verilog will
324 generate appropriate error messages.
327 * MODULE INSTANCE WITH WRONG SIZE PORT LIST
329 A module declaration like this declares a module that takes three ports:
331 module three (a, b, c);
332 input a, b, c;
333 reg x;
334 endmodule
336 This is fine and obvious. It is also clear from the standard that
337 these are legal instantiations of this module:
339 three u1 (x,y,z);
340 three u2 ( ,y, );
341 three u3 ( , , );
342 three u4 (.b(y));
344 In some of the above examples, there are unconnected ports. In the
345 case of u4, the pass by name connects only port b, and leaves a and c
346 unconnected. u2 and u4 are the same thing, in fact, but using
347 positional or by-name syntax. The next example is a little less
348 obvious:
350 three u4 ();
352 The trick here is that strictly speaking, the parser cannot tell
353 whether this is a list of no pass by name ports (that is, all
354 unconnected) or an empty positional list. If this were an empty
355 positional list, then the wrong number of ports is given, but if it is
356 an empty by-name list, it is an obviously valid instantiation. So it
357 is fine to accept this case as valid.
359 These are more doubtful:
361 three u5(x,y);
362 three u6(,);
364 These are definitely positional port lists, and they are definitely
365 the wrong length. In this case, the standard is not explicit about
366 what to do about positional port lists in module instantiations,
367 except that the first is connected to the first, second to second,
368 etc. It does not say that the list must be the right length, but every
369 example of unconnected ports used by-name syntax, and every example of
370 ordered list has the right size list.
372 Icarus Verilog takes the (very weak) hint that ordered lists should be
373 the right length, and will therefore flag instances u5 and u6 as
374 errors. The IEEE1364 standard should be more specific one way or the
375 other.
377 * UNKNOWN VALUES IN L-VALUE BIT SELECTS
379 Consider this example:
383 [...]
384 vec[idx] = 1;
386 So long as the value of idx is a valid bit select address, the
387 behavior of this assignment is obvious. However, there is no explicit
388 word in the standard as to what happens if the value is out of
389 range. The standard clearly states the value of an expression when the
390 bit-select or part select is out of range (the value is x) but does
391 not address the behavior when the expression is an l-value.
393 Icarus Verilog will take the position that bit select expressions in
394 the l-value will select oblivion if it is out of range. That is, if
395 idx has a value that is not a valid bit select of vec, then the
396 assignment will have no effect.
399 * SCHEDULING VALUES IN LOGIC
401 The interaction between blocking assignments in procedural code and
402 logic gates in gate-level code and expressions is poorly defined in
403 Verilog. Consider this example:
405 reg a;
406 reg b;
407 wire q = a & b;
409 initial begin
410 a = 1;
411 b = 0;
413 if (q !== 0) begin
415 $finish;
416 end
417 end
419 This is a confusing situation. It is clear from the Verilog standard
420 that an assignment to a variable using a blocking assign causes the
421 l-value to receive the value before the assignment completes. This
422 means that a subsequent read of the assigned variable *must* read back
423 what was blocking-assigned.
426 gate logic between a/b and q. The standard does not say whether a read
427 out of logic should read the value computed from previous assigns to
430 value or the existing value?
432 In fact, existing commercial tools do it both ways. Some tools print
433 the FAILED message in the above example, and some do not. Icarus
434 Verilog does not print the FAILED message in the above example,
435 because the gate value change is *scheduled* when inputs are assigned,
436 but not propagated until the thread gives up the processor.
438 Icarus Verilog chooses this behavior in order to filter out zero-width
439 pulses as early as possible. The implication of this is that a read of
440 the output of combinational logic will most likely *not* reflect the
441 changes in inputs until the thread that changed the inputs yields
442 execution.
445 * BIT AND PART SELECTS OF PARAMETERS
447 Bit and part selects are supposed to only be supported on vector nets
448 and variables (wires, regs, etc.) However, it is common for Verilog
449 compilers to also support bit and part select on parameters. Icarus
450 Verilog also chooses to support bit and part selects on parameter
451 names, but we need to define what that means.
453 A bit or a part select on a parameter expression returns an unsigned
454 value with a defined size. The parameter value is considered be a
455 constant vector of bits foo[X:0]. That is, zero based. The bit and
456 part selects operate from that assumption.
458 Verilog 2001 adds syntax to allow the user to explicitly declare the
460 (or should) use the explicitly declared vector dimensions to interpret
461 bit and part selects.
464 * EDGES OF VECTORS
466 Consider this example:
469 always @(posedge clock) [do stuff]
471 The IEEE1364 standard clearly states that the @(posedge clock) looks
472 only at the bit clock[0] (the least significant bit) to search for
473 edges. It has been pointed out by some that Verilog XL instead
475 reduction or of the vector. Cadence Design Systems technical support
476 has been rumored to claim that the IEEE1364 specification is wrong,
477 but NC-Verilog behaves according to the specification, and thus
478 different from XL.
480 Icarus Verilog, therefore, takes the position that the specification
481 is clear and correct, and it behaves as does NC-Verilog in this
482 matter.
485 * REAL VARIABLES IN $dumpoff DEAD-ZONES
487 The IEEE1364 standard clearly states that in VCD files, the $dumpoff
488 section checkpoints all the dumped variables as X values. For reg and
489 wire bits/vectors, this obviously means 'bx values. Icarus Verilog
490 does this, for example:
492 $dumpoff
493 x!
494 x"
495 $end
497 Real variables can also be included in VCD dumps, but it is not at
498 all obvious what is supposed to be dumped into the $dumpoff-$end
500 variables to the dead-zone value of 0.0, whereas other tools, such as
501 ModelTech, ignore real variables in this section.
503 For example (from XL):
505 $dumpoff
506 r0 !
507 r0 "
508 $end
510 Icarus Verilog dumps NaN values for real variables in the
511 $dumpoff-$end section of the VCD file. The NaN value is the IEEE754
512 equivalent of an unknown value, and so better reflects the unknown
513 (during the dead zone) status of the variable, like this:
515 $dumpoff
516 rNaN !
517 rNaN "
518 $end
520 It turns out that NaN is conventionally accepted by scanf functions,
521 and viewers that support real variables support NaN values. So while
522 the IEEE1364 doesn't require this behavior, and given the variety that
523 already seems to exist amongst VCD viewers in the wild, this behavior
524 seems to be acceptable according to the standard, is a better mirror
525 of 4-value behavior in the dead zone, and appears more user friendly
526 when viewed by reasonable viewers.
530 $Log: ieee1364-notes.txt,v $
532 Spelling fixes.
535 Make some effort to preserve bits while
536 operating on constant values.
539 NaN in dead zones of VCD dumps.
542 Edge of vectors notes.
545 Support parameters with defined ranges.
548 Spelling patch (Larry Doolittle)
551 Support selecting bits from parameters.
554 Notes about scheduling
557 Handle x in l-value of set/x
560 Accept empty port lists to module instantiation.
563 I allow function ports to have types.
566 Rant about bit widths.
569 Resolve repeat ambiguity in favor of loop.
572 repeat loops ambiguity.
575 rounding of time and x in primitives.
578 Integer parameter comments.
581 Document ieee1364 issues.</pre>
583 </div>
584 </div>
585 </body>
586 </html>