( ESNUG 269 Item 4 ) -------------------------------------------- [10/24/97]
Subject: (ESNUG 266 #5 267 #1 268 #5) *WHO* Is Using Behavioral Compiler?
> 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
From: Victor_Duvanenko@truevision.com (Victor Duvanenko)
Hi, John and the Gang,
On Behavioral Compiler... I took the BC class from Synopsys and even read
through half of the book that one of the BC designers published. I take
issue with anyone that says "It's going to take a while to switch engineers
from RTL to a higher-level." This is absolute rubbish. VLSI engineers are
a very clever and resourceful bunch and they would gladly do it a better
way. It also doesn't take that much of a mind switch to go to BC-style -
c'mon if they can teach it to you in a couple of days - it's definitely not
differential equations or sub-atomic physics!
BC is just not ready - plain and simple.
BC does not follow the fundamental design methodology of hierarchy - it's
hard to hook two BC generated blocks together. BC wants the freedom to
change the interface on each of the blocks (a very block-centric approach).
BC does not understand the concept of "stalling data pipes", such as when
your block is surrounded by FIFO's and there happened to be no data available
for the pipe to work on, so BC doesn't know how to design pipes that stop
for a while and wait for data to get there. Currently BC is really an
implementation compiler. When BC is ready I'll be the first to jump on
it - I've been ready to give up RTL-level coding since my first design with
Design Compiler 1.0.
- Victor J. Duvanenko
Truevision
---- ---- ---- ---- ---- ---- ----
From: Doug Warmke <doug@ikos.com>
John,
In the BC discussion, one thing that is really important to us that might
be worthy of public discussion is the risk-reduction point.
Our RTL FSM's simply got too out of hand. They are of the "pipelined FSM
form", where the FSM is simultaneously controlling several stages worth of
pipeline. This kind of FSM is necessary when you're dealing with a
synchronous resource like an external Late-Write SRAM, which has a couple
cycles latency on its results. (Too hard to explain in crystalline form
here.)
BC reduced our code substantially (3x less lines), and most importantly, we
could convince ourselves that we had the algorithm implementation
fundamentally sound by visual inspection.
In the RTL versions, we just couldn't tell, and we were continually running
into hard-to-find corner cases with difficult and risky eventual solutions.
It's an interesting philosophical point, I think.
- Doug Warmke
Ikos Systems, Inc.
---- ---- ---- ---- ---- ---- ----
From: Robert Hoffman <bobh@siforge.com>
Hi John,
Just a brief note on BC, since I didn't see anyone mention this.
About 6 months back, I evaluated the tool for use in a DSP modem asic
(QAM256). Previously, I had used verilog and found the use of parameterized
designs for handling datapath to be an incredible timesaver. Carrying this
forward, I concluded that the use of vhdl with its more robust generic
command (allowing for optional hw elements) in combination with BC would
result in excellent architectural flexibility.
Now the bad news, I found that BC was incompatible with the use of
parameterization. This to me was a fundamental flaw -- I would rather have
parameterization over scheduling.
Just wanted to forewarn others - and I never got a Synopsys commitment to
fixing this.
- Robert Hoffman
Siforge
|
|
