( ESNUG 271 Item 4 ) -------------------------------------------- [11/14/97]
Subject: (ESNUG 268 #5 269 #4 270 #5) *WHO* Is Using Behavioral Compiler?
> For designs that contain memories and/or sequential Designware components
> that BC is required to stall, Victor Duvanenko is absolutely correct. For
> other designs, BC can support the stall functionality. We are currently
> planning on expanding the scope to include memories and sequential
> Designware components.
>
> - [ A Synopsys BC CAE ]
From: Victor_Duvanenko@truevision.com (Victor Duvanenko)
John,
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
> If you choose to use BC in the super-state mode, then the tool has
> additional degrees of freedom. These degrees of freedom can be used to
> adjust latency and other cycle-specific behavior. If you want to take
> advantage of efficiencies which can be generated by allowing the
> compiler to decide when an output becomes available then you need to be
> careful at the interfaces. Using a data available signal to handshake
> with external blocks can make your design more robust, flexible and
> reusable in general. When the cycle specific timing is unknown then the
> handshaking is essential.
>
> If using handshakes is unacceptable within your design methodology then
> BC can equally be used in cycle_fixed mode which preserves the
> cycle-specific behaviour of the design at the behavioral, RTL and the
> gate level. BC is still able to schedule and share operations etc in
> your design.
>
> - [ A Synopsys BC CAE ]
From: Victor_Duvanenko@truevision.com (Victor Duvanenko)
John,
Maybe it's been a while since I've looked at BC, or maybe BC has improved,
but here is the scenario that I remember which BC could not tackle and why
I say that BC fails in the basics of hierarchical design. I code up a BC
block that may or may not generate a data item on every cycle, so I have a
signal calle "valid" that accompanies the data output. Then since my blocks
are symmetrical, my next block can take the input on every cycles, but once
in a while it can't. So, my next block has a handshaking signal going back
to the first block called "got_it".
This methodology is followed at nausium.
What BC could not handle is the fact that there was a two-way handshaking
mechanism (which is very common - like PCI-bus's IRDY# and TRDY# signals),
where the sender and the reciever both have flow control. BC wanted only
one of the blocks to be able to control the flow of data, but not both. To
me that meant that I could design only certain blocks with BC (the ones that
BC could handle) and the rest with an RTL methodology. That once again may
be enough of a productivity gain for some "design spaces", and there maybe
lots of "design spaces" that BC can handle very well, just not the one I
needed. At the time when I took the BC class I spoke to the BC CAE and he
admitted that BC couldn't handle stalling or the two-way handshake, but that
in the future BC would improve and take on more "design spaces". I'm just
more ready that most to move beyond this RTL-level design methodology that
we've been crawling with. I'm very glad that Synopsys continues their
relentless march toward the next level of design tools (good job!) - I just
wish that it was here already.
Enjoy,
- Victor J. Duvanenko
Truevision
|
|
