Home Download Documentation FAQ Report a Bug SourceForge page
Previous Contents Next

Language compatibility and features supported

7.1 Verilog® 1

Verilog® 1 refers to the IEEE 1364 Verilog® draft 1 standard that was recently passed.

The vcomp compiler's main goal is to meet the Verilog® 1 standard.

  • specify and specparam declarations are accepted, but only timing checks are currently supported, related system tasks and acc_* and tf_* routines are implemented but report error messages
  • the PLA tasks $sync$and$array etc are not yet supported
  • we do not support PLI 2 (vpi_* routines) It is our intention to support all of the above over the next few months (except possibly for vpi routines) and are actively seeking suggestions as to which should be implemented first.

    The following non-ansi-standard, but common, features are implemented:

    • $log/$nolog
    • $countdrivers
    • $sreadmemb/$sreadmemh
    The following non-ansi-standard, but common, features are not implemented:
    • CLI
    • $save/$restart/$incsave, tf_write_save/tf_read_restart
    • $reset/$reset_value/$reset_count
    • $list
    • $key/$nokey
    • $input
    • $getpattern
    • $scale/$scope/$showscopes
    Our PLI support header files veriuser.h and acc_user.h are absolutely standard and available on the farm in /usr/include.

    7.2 Verilog® 2

    Our eventual goal is to support all of the IEEE 1364-2000 that has not yet been ratified. We do include some of the possible future features in our current implementation - be warned if they don't make it to the final standard we may remove them.
    • @(*)....
    • $fopen extensions/$fgetc/$fflush/$ftell/$fseek/$rewind/$ferror/$fgets (but not $fscanf/$sscanf/$fread* yet)
    • passing parameters by name to modules
    • $swrite/$sformat
    • the new input/output declaration and paramater declaration formats

    7.3 Comparative implementations

    What does 'compatible' mean? for Verilog® it used to mean compatible to Cadence® Verilog®, now days it could also mean 'compatible to ANSI Verilog®', also a lot of our potential customers are VCS® houses - we'd like to make conversion of simulation environments to ours as simple as possible, so for our first release compatibility has been our first goal.

    During our compatibility testing we uncovered a number of differences between ANSI 1364, Cadence® Verilog® and VCS®. In order to reconcile them we have in many cases introduced the '-compat' flag to the compiler, you can specify '-compat ansi' for strict 1364, '-compat verilog' for Cadence® Verilog®, '-compat vcs' for VCS® or the default '-compat ansix' 1364 compatibility with the ==/!= bug mentioned below fixed.

    Here's our listing of compatibility issues and how we have resolved them, note that we performed our testing against particular versions of the tools and current released versions may have fixed them.

    Verilog® and it's runtime environment is a very complex system it's not surprising that everyone still has bugs (we certainly do and want to find and fix them asap - don't forget to report them). What follows is basically a dump of our compatibility log - it doesn't include the unanalyzable things like "on test XYZ simulator S dumps core".
    ANSICadence® Verilog®VCS®vcomp
    multibit == and != in the presence of Xs, Verilog® and VCS® do this correctly in our opinion - ANSI says that one X bit in a multibit logical compare causes the result to be all Xs while the correct implementation would return non-X values from comparisons like "2'b1x != 2'b0x" - we consider this to be a bug in the standard this has been reported to the ANSI committee and will hopefully be fixed in 2.0 Correct Correct '-compat ansix', the default behaves correctly while '-compat ansi' gives the standard (but wrong) behavior
    Correct returns a multibit all-X value from an arithmetic comparison (<, >, <=, >=) where one of the operands has a X bit and the result is widened and stored to a multibit register. For example - reg [4:0]a; a=3'bx00 < 3'b100; stores 5'bxxxxx in a when it should store 5'b0000x. Correct '-compat verilog' emulates the buggy behavior, all other options perform the ANSI behavior
    Correct some divides by 0 of size >= 64 return a 0 value rather than X Correct '-compat verilog' emulates the buggy behavior
    Correct Correct some large concatenation create Xs from nowhere, for example "{2{{2{42'h2407}}}}" we consider this a genuine bug rather than language dialect and didn't try to emulate it
    Correct Correct under some situations modding a variable with itself ie AA%AA results in an X rather than the value 0 we consider this a genuine bug rather than language dialect and didn't try to emulate it
    Correct @(posedge X) or @(negedge X) where X is a multibit value is handled in a non-ansi manner - ANSI says that for edge detection of multi-bit variables all bits except the LSB are ignored - Verilog® does a more complex analysis Correct '-compat verilog' implements the Verilog® functionality but using it is not recommended since it it much less efficient for simulation than the standard - fortunately this construct is seldom used (and is not generally portable due to Verilog®'s different implementation

    Often with @(multi_bit_scalar_net) you will see multiple event triggers as the different bits of the net are separately propagated this is legal within the language spec - but sometimes confusing - for example if a net is driven with 2'b01 and you change it to 2'b10 you may see it transition to 2'b00 or 2'b11 before it settles to it's new value seems to not happen nearly as often if at all with vcomp you are less likely to detect this sort of thing due to the way we do event ordering, but it's not impossible, especially in an SMP environment
    ANSI doesn't specify which delay (rising/falling/etc) to use for a net that changes strength, but not value, nor does it specify which delay to use for a multibit net that changes from say 10 to 01 wires in scalared nets are treated as independent wires vectored nets seem to get delays that are the minimum of the applicable bits, it doesn't seem to scalar assign delays vector and scalar nets seem to be treated the same and a net going to a 0 value is a 0-delay time and all going non-0 is a 1-delay time This whole area is very fuzzy and probably needs some attention by the standards committee - we have implemented the Verilog® approach for scalared nets and the VCS® one for scalared nets - please let us know if this is a problem for you)

    Previous Contents Next