( ESNUG 319 Item 1 ) --------------------------------------------- [5/26/99]
Subject: No, We Actually Think Behavioral Compiler *Is* The Way To Go
> The Big Shiney Plastic Prize one was supposed to get for opening the
> Behavioral Compiler breakfast cereal box was BOA and BRT; two very nice
> come-ons, but not worth the hassles & headaches of BC/DW. So, like
> hiding the idiot uncle in the basement when guests visit, Synopsys has
> wisely de-emphasized BC, moved BOA/BRT into DC-Ultra, and you now see
> there are 18 Module Compiler classes for every 6 BC classes given
> at Synopsys Corporate.
From: david_johnson@paging.mot.com (David Johnson)
John,
I'd like to respond to the commentary in the SNUG'99 Trip Report on BC.
There is much more to Behavioral Compiler (BC) than just Behavioral
Optimization of Arithmetic (BOA) and Behavioral Retiming (BRT).
Fundamentally, BC allows the systems/hardware designer to think and
write code algorithmically and still get efficient implementations.
I've known several designers that made up their mind that they did not want
to use BC without ever even seeing any presentations on BC. To these
designers that are used to being handed a micro-architectural spec, BC
is a mysterious, black-magic proposition. The paper I presented at
DesignCon98 "Design Automation of a Receiver: Breaking the RTL Cycle Time
Barrier Using Behavioral Compiler" was intended to explain the basic
concepts of architectural synthesis in a very intuitive way. The proof
is in the working silicon and the fact that all new blocks within our
group are designed using BC. One experienced ASIC designer I know
didn't see any value in BC until one of his RTL blocks was re-written
algorithmically for BC and BC did a more efficient job of resource sharing
fully automatically than the original manual RTL. A new designer in the
group took to BC like a fish to water -- he had a good systems background
and he had no prior experience designing ASICs in RTL, hence no
prejudices against BC. One reason for the quick learning curve for the
new designer with BC was that he was presented with a complete end-to-end
flow, not just the BC point solution, and he was provided with existing
design examples in BC for our type of applications. Any time he had
a question as he was ramping up, help was readily available.
It may take a while for designers to appreciate the new possibilities
available with BC, for example the reality and utility of quickly
being able to generate different architectures from the same code.
In order to take advantage of the latest R&D for one design, I needed
to change the number of cycles in a loop from 3 to 1, (lower latency,
more parallel resources) and incorporate loop-pipelining. I could
do this all with a few behavioral synthesis commands and no change
to the code. The new IC features would not even have been considered
without the proven quick-turnaround time using BC in the methodology.
Loop-pipelining is another concept mysterious to many experienced RTL
designers, but nevertheless yet another very powerful capability in BC,
and well worth the effort to learn the concept.
For combinational tasks/functions, user DesignWare has been virtually
eliminated in BC. Yes, DesignWare hoops are still needed in some cases
for sequential/pipelined tasks/parts. I don't want to have to deal with
DesignWare memories either -- that should completely be handled by the
ASIC vendor, but for now there is a new GUI BC MemWrap to make that
process very straightforward for memories (we've seen it in Beta).
I expect that over time, as the designers who invest in educating
themselves on how to use Behavioral Compiler experience first-hand the
significant productivity improvements available over designing manually
in RTL, the debate over Behavioral Synthesis will become moot. BC
expertise will become as necessary for ASIC designers to have on their
resume as DC RTL expertise has been.
- David Johnson
Motorola
|
|
