( ESNUG 238 Item 2 ) ---------------------------------------------- [4/4/96]
Subject: (ESNUG 234 #5 235 #1 237 #3) "What's The Customer Story On BC & DW?"
> I'm looking for information / real user testimony on ESNUG on Behavioral
> Compiler. I am also interested in the use model for DesignWare.
From: ekadys@swi055.ericsson.se (Dyson Wilkes)
Hi, John,
The current writings on BC are interesting. It has been tried in a couple
of quite different application examples in Ericsson with completely different
degrees of success.
In one case the RTL designer got the basic design together in about a week.
The BC verison took 3 or 4 times to get through and was much larger and
slower. The main reason was that the code used in the BC case was not
suited to BC. Also it was an early verison and even Synopsys were on a
learning curve.
In another case the results were so encouraging that the designer involved
was advocating the use of BC. His main motivation was the reduction of
the number of lines of code you have to put in. I have no good metric but
my gut feeling is that the room for error increases geometrically with the
number of lines of code you have to enter to get a result. (Sit down! all
you Verilogers yelling Verilog is better than VHDL because the fewer number
of lines is less with Verilog for given function! -- I will just throw a
VHDL/Verilog scaling factor at you!)
The other major plus for BC is that you can verify the input to BC which
simulates >10 times faster (depends on how many clock cycles your
implementation takes to do the "loop" of course).
- Dyson Wilkes
Ericsson
> The next problem is that BC is limited to a total 150 operations. (An
> operation is defined as *any* mathematical operation, signal assignment, or
> variable assignment. This is quite a constraint, because most designs can
> burn up 150 operations quite quickly!) There are workarounds to this
> problem, like encapsulating complex operations into DesignWare components
> or not unrolling loops, but I consider it a definite limitation.
From: [ A Synopsys (Field) Application Consultant ]
John, the 150 operations number is a guidline. We usually say 150-200
operations as a guideline for running schedules pretty quickly. This is sort
of the same idea as recommending blocks of around 5-7k gates for Design
Compiler runs -- advice for keeping the run times reasonable. But, the
user's point is well taken -- you can burn up 150 operations fast. I've seen
some customer examples where they have used BC to make pipelined operators
out of several operations (say a custom MAC kind of function or something)
that may be require several cycles of latency -- then take the results back
into a higher level run of BC by means of DW. In that case, BC now sees the
complex DW operator as a single operator - BC understands how many cycles
that are required to process data through it. So, it can then schedule one
or more of those in the current design - and each will be a single operator
regardless of how many 'sub operations' reside in it.
- [ A Synopsys (Field) Application Consultant ]
|
|
