( ESNUG 238 Item 5 ) ---------------------------------------------- [4/4/96]
Subject: Behavioral Compiler's Problems With Async Resets
>Achieving a design in Behavioral Compiler that has an asynchronous reset or
>strobes is, well, a big pain in the buttocks! Optimally, Behavioral
>Compiler likes to see one clock and a *synchronous* reset. ... If you use
>strobes, you can only use an asynchronous reset, AND your pre- and post-
>simulations will never match. (Oh, and when I SAY asynchronous reset, I do
>not mean the obvious WAY of attaching a reset line to all the flops...
From: [ A Synopsys (Field) Application Consultant ]
John,
I read Ted's comments about the use of Behavioral Compiler in the latest
ESNUG - I thought I'd pass on something that might help with async resets.
There is now a way to get BC to use async resets for more than just the FSM
registers. There is a variable called:
reset_clears_all_bc_registers="true"
that will connect an async reset to zero to all registers in the design.
Yes -- I meant that exactly -- *all* registers will be async reset to ZERO.
This means that BC will not currently encode async resets per the reset
portion of the behavioral code block - if there is a signal that must be set
asynchronously instead of reset, it would need to be manipulated by hand.
(I'm not sure what the status may be with an enhancement that would do that.
The current variable approach was implemented to at least get some sort of
async reset capability in there quickly.)
For sync resets, BC will use the encoding in the reset portion of the block
to set or reset signals. (I know that this variable was available in v3.3b
-- it may be available in v3.3a as well.) You'd use it along with:
set_behavioral_async_reset <pin name>
for getting async resets in the FSM.
- [ A Synopsys (Field) Application Consultant ]
|
|
