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

• $log/$nolog
• $countdrivers
• $sreadmemb/$sreadmemh

• CLI
• $save/$restart/$incsave, tf_write_save/tf_read_restart
• $reset/$reset_value/$reset_count
• $list
• $key/$nokey
• $input
• $getpattern
• $scale/$scope/$showscopes

7.2 Verilog® 2

• @(*)....
• $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

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".

ANSI	Cadence® 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)