( ESNUG 267 Item 1 ) -------------------------------------------- [9/29/97]
Subject: (ESNUG 263 #1 264 #2 266 #5) *WHO* Is Using Behavioral Compiler?
> My goal for the design was to find the shortest schedule for performing all
> the operations in setting up a triangle for rasterisation on the smallest
> number of arithmetic units. BC, in this respect, is very useful since the
> turn-around time for behavioural code change to reschedule is quite short
> (10-15min) which allowed me to experiment with different latencies and
> throughputs for the arithmetic units.
From: Jonathan Liu <jonathan@ikos.com>
Hi, John,
I'd like to respond to the BC thread by letting everyone know
that within a month we will be taping out 2 chips which are partial-BC
designs. Each chip contains one behavioral block of about 5000 gates,
with the rest of the 50K gates or so being purely RTL (or RTL with
BRT). The application is highly control-intensive, with many SRAM
interfaces and a moderate amount of arithmetic operations as well. The
language is VHDL.
The primary reason we chose to use BC for these blocks was for
ease of specification and for peace-of-mind on design correctness. When
we tried to code them in RTL, the result was an extremely complex state
machine with heavy pipelining, many boundary conditions, and several
thousands of lines of code. When written behaviorally, the state
machine, SRAM control logic, and pipelining were all done automatically,
and it only took about 500 lines of code. Most importantly, it was much
easier to satisfy ourselves intuitively that the code was correct (which
is important, even when the design is heavily simulated). The
performance turned out at least as good as we could have expected in
RTL, if not better.
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!)
The reason we didn't use BC on a higher percentage of the design
was mainly because of design reuse -- it just wouldn't have been worth
it to port all the legacy code that only required minor modification.
I would guess this is another big reason in many companies' for not
switching to BC, as it seems rare now for new design starts to be
totally from scratch.
Next time I personally design a new chip, I would definitely prefer to
do most of the complex (non-reused) blocks in BC. However, I might not
feel the same way if I were managing a large team of RTL designers who
were not yet familiar with the behavioral style.
- Jonathan Liu
Ikos Systems, Inc.
---- ---- ---- ---- ---- ---- ----
From: dtkain@CCGATE.HAC.COM (Dan Kain)
Dear John,
I wanted to provide some feedback to your "listeners" on the
Synopsys Behavioral Compiler (BC) tool. The reason why I tried out the
BC tool was that I was hoping to increase my design productivity by
writing fewer lines of VHDL code at a higher level of abstraction. If
you remember back when Synopsys first came out with their Design
Compiler (DC) tool, we slowly learned that we could be more productive
ASIC designers by writing Synopsys compatible VHDL RTL code and
infering gates instead of instantiating gates with a schematic capture
tool. With that in mind, I thought that BC's new capability of
infering memories may result in my next productivity jump by
eliminating the need to instantiate RAM's inside my RTL code.
Well, I was dissapointed. Yes, BC does let you infer memories, but
it is very difficult to do and I think I can be more productive by
simply instantiating the memories in RTL code. After talking to
Synopsys AE's with regard to the large overhead "cost" of inferring
memories, the response I received was that it was very difficult to
support memory inferencing today due to the large quantity of
different types of ASIC memories presently available. My response to
this was that I was personally willing to reduce my choice with regard
to memory types if I could then very easily infer them in my VHDL code
to obtain the productivity improvement I so dearly desired.
Unfortunately, I do not think Synopsys has any near term plans to make
memory inferencing an easy task to perform.
Two features of BC that worked well for me were it's transform_csa
(BOA) and optimize_registers (BRT) commands. Don't ask me why Synopsys
had to come up with two names for each of these commands when one name
each would suffice. I guess from a marketing point of view, saying we
added this new BOA feature to the tool sells better than saying we
added the transform_csa command to the tool. Also, don't ask me why
Synopsys requires you to buy a BC license to run these commands since
they run perfectly find under DC shell (when you have a BC license).
The neat thing about these commands is that they synthesize pipelined
multiplier/adder trees much more efficiently than simply using
Synopsys designware.
In all fairness to Synopsys, they really did not market BC to me as
a memory infering tool or for its BOA/BRT capabitlities. They instead
marketed BC as a architectural trade-off tool for multi-cycle designs.
Synopsys was trying to sell to me that if I used their new BC tool I
would then become a more productive ASIC designer (ie super ASIC
designer) by enabling me to perform architectural trade-offs on
multi-cycle designs at the behavioral level of abstraction. The only
problem was that to date, all my designs have simply been single cycle
designs and so I really did not have a need for BC's architectural
trade-off capability. End of story.
- Dan Kain
Hughes
|
|
