( ESNUG 351 Item 3 ) ---------------------------------------------- [5/4/00]
From: Dan Joyce
Subject: De-Glitching TransEDA's VeriSure Causes A 3X Sim Performance Hit
Hi, John,
There is an problem we found with the TransEDA's VeriSure code coverage tool
almost 2 years ago, that appears not to be unique to this tool. VeriSure
made a fix for it, but have not rolled that fix into their mainline tool (at
least not in the default mode) because of a 3X simulation performance cost.
I think their mainline tool does now finally have the ability to turn on the
"deglitch" feature that will solve this problem.
The problem has to do with coverage analysis of lines in combinatorial
always@ constructs - always@(signal_list). Since these constructs are
entered each time one of the signals in the signal_list changes, they get
executed several times per clock if several of the signals change. The
problem is that only the last time through the always@ - before the next
clock - really gets simulated. T his is because only the output settings
made on the last pass are clocked into DFFs. This can lead to false
positives in your coverage data.
Lines of code that show many executions can actually be completely
unverified by your tests!!!
Code in "always@(posedge Clock)" constructs are immune to this problem since
they are only executed once per clock. The part that really concerns me is
that much of the most important code in my Verilog HDL is written in
"always@(signal_list)" loops. Namely my state machines! This is where I
use code coverage first, and where I find it most useful. If you are
writing code for high performance designs, you usually need to generate
Mealy outputs from your state machines (outputs dependent on state variables
AND inputs.) With Mealy outputs it is much easier to describe the outputs
and next state outputs in an "always@(signal_list)" loop, and then send the
state variables and Moore outputs to "always@(posedge Clock)" and clock them
into DFFs separately.
This problem is with VeriSure at or before version 4.200B1. We saw the
false positives using Cadence Verilog-XL as the simulation engine. I
cannot tell if the problem still exists because we have solved it for
ourselves by turning on the "deglitch" feature in our VeriSure.par file.
To turn on Deglitch feature in VeriSure.par file with a time unit of 1
vsinstrument deglitch_compatible on
vssimulate deglitch_time 1
You can see if your VeriSure version has the deglitch feature supported by:
1. set up VeriSure as normal.
2. type vsinstrument -help
3. from the resulting messages check for "deglitch_compatible"
Unfortunately, I have not been able to turn "deglitch" off correctly and get
a good run. And I don't have any time to work on it.
My advice to others, especially if you are using Verilog-XL, or if you
suspect you are getting false positives in combinatorial always@'s
(always@(signal_list)), would be to run this code snippet:
module test1(
);
reg clk;
reg [4:0] register;
reg [4:0] register_next_state;
reg error;
reg error_next_state;
reg [11:0] count;
initial begin
//$dumpvars;
register <= 0;
error <= 0;
clk <= 0;
count <= 0;
#20 clk <= 1;
end
always@(clk) clk <= #20 ~clk;
always@(posedge clk) begin
count <= count+1;
if (count == 12'hfff) $finish;
end
always@(register) begin
if(register[0]) register_next_state = 5'b00000;
else register_next_state = 5'b11111;
case(register)
5'b00000 : error_next_state = 0;
5'b11111 : error_next_state = 0;
default : error_next_state = 1; // line should show NO coverage!
endcase
end
always@(posedge clk) begin
register <= register_next_state;
error <= error_next_state; // This line should show no coverage!!!
end
endmodule
While taking a VERA class at Synopsys, I had a CoverMeter AE run this code
on CoverMeter using VCS as the simulator. This showed no coverage (worked
correctly). I would like to see CoverMeter running Verilog-XL however.
- Dan Joyce
Compaq Computers
|
|
