( ESNUG 308 Item 11 ) --------------------------------------------- [1/20/99]
From: David Black <dcblack@qualis.com>
Subject: Five Classic Mistakes Using Verilog "Disable" Within BC
John,
Behavioral Compiler supports the use of Verilog's 'disable' to emulate
VHDL's 'exit' and 'next'. This works if you follow their official examples
closely; however, overuse can lead to problems. Here are five common
mistakes I've found using "disable" in BC:
MISTAKE 1. Disabling the wrong block
begin :LOOP forever begin :BODY
@(posedge clock);
if (COND1) disable BODY; // equivalent to VHDL 'NEXT'
if (COND2) disable LOOP; // equivalent to VHDL 'EXIT'
end end
All too often, engineers leave out the enclosing begin-end pair. It seems
more natural; however, Verilog rules dicate that the inner begin block is
not connected with the forever.
MISTAKE 2. Asserting outputs and disabling without an intervening
clock:
request_out <= 1;
@(posedge clock);
begin :LOOP forever begin
if (acknowledge_in == 1'b1) begin
request_out <= 0;
disable LOOP;
end
@(posedge clock);
end end
Verilog-XL simulation will reveal that request_out never gets set to zero.
This behavior differs from VCS which will provide the expected zero. The
reason for Verilog-XL is that all events scheduled within a block that
gets disabled are removed from the event queue. In this case, 0 was
scheduled to be placed on request_out, but the disable cancelled it.
Verilog semantics consider this behavior as unspecified and hence both
simulators are within legal bounds. Insertion of @(posedge clock) before
the disable will fix this problem both from a simulation and synthesis
point of view.
MISTAKE 3. Attempting to disable more than one level of hierarchy Verilog
allows disabling any block from a simulation point of view. Unfortunately,
BC does not support exiting more than a single level of loop hierarchy.
This should be addressed in a future BC version (time unspecified).
MISTAKE 4. Disabling a labeled block not associated with a loop Verilog
semantics allow for disabling many things. Intuitively, disabling a block
is nice as an error escape mechanism. In code:
begin :CODE_SEQUENCE
...
if (ERROR_CONDITION) begin
error_flag = 1;
disable CODE_SEQUENCE;
end
...
if (ERROR_CONDITION) begin
error_flag = 1;
disable CODE_SEQUENCE;
end
...
if (ERROR_CONDITION) begin
error_flag = 1;
disable CODE_SEQUENCE;
end
...
if (ERROR_CONDITION) begin
error_flag = 1;
disable CODE_SEQUENCE;
end
...
end //CODE_SEQUENCE
Unfortunately, Synopsys does not support this at the present time. For some
designs this appears to work occasionally (can you say "feature" with a sly
grin???).
Their work-around involves setting a bogus variable to true and using a loop
that ends with a test that unconditionally exits. Unfortunately, there is
a drawback to this that is discussed in Mistake #5 below.
MISTAKE 5. Too many disables leads to long schedule times Synopsys has a
complexity problem if the number of states and transitions gets too large.
Because BC looks for the best places to place operations, when the number
of states and transitions gets large, the search space can get large
exponentially. This leads to slow scheduling by the tool. This is related
to Synopsys' recommendation that the number of operations be kept under 150
(artificial number) viewed from another angle. If there are a large number
of operations OR transitions, then there are a large number of combinations
to consider. The number of considerations directly impacts the tools
performance.
- David Black
Qualis Design
|
|
