( ESNUG 272 Item 4 ) -------------------------------------------- [11/19/97]
Subject: (ESNUG 271 #4) A Workaround For How BC Handles System Stalls
> The trouble with my design space is that a destination FIFO (where my
> results go) gets full and must tell the rest of the logic/pipe to stop
> (stall). BC needs to support simple VHDL constructs as follows:
>
> wait until clk = '1';
> go_registered <= go;
> if ( go_registered = '1' ) then
> all of my pipe logic goes here...
> end if;
>
> Currently BC generates such gobble-gook when it sees this... The result
> need to work not only with DesignWare components, but all BC constructs
> (such as memories, FIFOs, and random logic). Otherwise, the designer is
> more productive not using BC. Keep in mind, this is the case of "my design
> space". BC may work perfectly fine for other "design spaces", and the only
> frustration that I'm expressing is that of not being able to use a more
> powerful tool, to be more productive, when BC is so close to being able to
> handle "my design space".
>
> - Victor J. Duvanenko
> Truevision
From: [ A Synopsys BC CAE ]
Hi John,
This sounds like a great chance for me to get some great customer feedback,
from Victor and other interested parties. The way BC currently supports
this type of system stall is by setting a command:
set_behavioral_stall_pin "pin_name" -active high/low
This directs BC to set the stall pin to a specific signal for a specified
process or for all processes within the design, e.g.
set_behavioral_stall_pin go -active low
would cause an active high signal on the input port "go" to stall the BC
design.
This methodology does not presently work for memories or sequential
designware parts, that have to be stalled. Why? The problem with these
parts is that there was no way of specifing which pin on the memory or
sequential designware part is the stall pin. This functionality has been
added to the Designware Developer product and BC now has plans to use this
information to directly hook up the memories and sequential DW parts which
have the existing stall functionality specified. Random logic works as of
today.
Q: Is this going to fulfill your needs as a user? (I'd like to hear what
users think about this approach.)
OK, as to a workaround you can use today:
As you already know by default BC does not support stalling pipelined parts
and memories, if you try to run it you will get the following message:
WARNING: Pipelined parts and memories are not stalled by the stall pin.
This can cause incorrect behavior: you must correct
the circuit manually by adding a stall function to all such parts,
and then connect them to the stall signal.
Here's the workaround:
a) Set the following UNIX environmential variable before starting dc_shell
unix> setenv "bc_seq_stall" "true"
b) When you call the designware part connect a '0' to the stall port, i.e.
result <= mul_add_fl_p_s(clk, mant_1, exp_1, mant_2, '0');
c) Schedule the design
d) Remove the net attached to the stall pin and connect it to the stall
port instead. Here's a sample script which you can modify and use:
cnl = {}
ref_list = find(reference, *_state_*)
foreach(ref_member, ref_list) {
cnl = cnl + filter(find(cell,"*") "@ref_name == ref_member")
foreach(cn,cnl) { }
all_connected find(pin, cn + "/stall*")
disconnect_net dc_shell_status find(pin, cn + "/stall*")
all_connected find(port, stall[0])
connect_net dc_shell_status find(pin, cn + "/stall*")
}
(The part of the script you may need to change are *_state_* and
stall[0] depending on the names you've used for them.)
e) Levelize the output for simulation
vhdlout_levelize = true
verilogout_levelize = true
f) compile
I hope this helps, Victor.
- [ A Synopsys BC CAE ]
|
|
