( ESNUG 268 Item 5 ) -------------------------------------------- [10/9/97]
Subject: (ESNUG 264 #2 266 #5 267 #1) *WHO* Is Using Behavioral Compiler?
> Of course, we had to learn the BC coding style, which is not entirely
> straightforward and definitely takes getting used to. One does also
> give up some control when moving to a higher level, which is not easy
> for most engineers. In my opinion, the difficulty in adjusting to the
> style is probably a big reason for slow market acceptance, just as
> adopting RTL was difficult at first for many long-time schematic
> designers. (However, when RTL synthesis first came out, many designers
> were already used to writing PAL equations, which is really a form of
> RTL. Since BC coding is radically different from RTL, I believe it's a
> bigger leap!)
From: "Janick Bergeron" <janick@qualis.com>
Hi, John,
The discussion about the merits and inadequacies of Behavioral Compiler
brought back some vivid memories:
Ottawa, Bell-Northern Research (now Nortel) CAD group, November 1988.
My first job, fresh out of Univerity of Waterloo: write a
standard-cell/gate-array mapper and optimizer for the in-house logic
synthesis tool then in development. Six months later, through a superb
team effort, we had a tool that could translate our proprietary HDL into
gate-level netlist. My module was ugly, bulky and slow - but it gave
better results than Synopsys 1.0 and Trimeter (anybody remember
Trimeter? :-). That was also before the regular calls from Synopsys
(and later Ambit) offering jobs... but I disgress.
Our group was actively trying to promote its use by logic designers
but reactions were mixed: "I can't edit the netlist to fix bugs? I
have to fix the HDL code?", "I implemented the same function in half
the gates last year!", or "but I want *these* gates!". I still
remember fondly the call from a designer, trying to translate a truth
table into HDL, asking me "how do I compare to don't care?": after two
hours, I'm not sure I had succesfully explained that you simply don't.
Others were overjoyed: a designer - who later became my manager - was
working on memory BIST and pleased to be able to describe his test
procedure in HDL, then quickly get gates, with only minor modifications
required for memories of different size and depth. His comments and
feed-back greatly improved the subsequent releases and helped shape
the RTL synthesis methodology that was later migrated to Synopsys.
The comments I see about BC (and behavioral synthesis in general) are
along the same line. It is still a (relatively) young tool. The
current uses are helping to shape future features and improvements.
Methodologies are evolving as well as design practices. You can't
expect to get as good a result with BC that you can get with manual
RTL coding - that is not its purpose. It is a time-saving device that
let's you implement your functionality faster, with less errors, at
the cost of some area and clock speed. You can't expect to bring BC
into your design process and see benefits overnight. Companies that
are just now making the switch to RTL and logic synthesis, with well
established tools and methods, aren't seeing benefits until the 2nd or
3rd project. BC moves design to another level of abstraction which
means you need to rethink how to capture a design - and that can't
happen without effort and time: with the enormous time pressure and
work load engineers are often under, there is little room for taking
the necessary time to learn a new way to design.
BC - and other application-specific synthesis tools like test synthesis
and protocol synthesis - is a taste of how designs are going to be done
in the future.
- Janick Bergeron
Qualis Design Corporation
|
|
