( ESNUG 237 Item 3 ) ---------------------------------------------- [3/29/96]
Subject: (ESNUG 234 #5 235 #1) "What's The Non-Propaganda 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. We have
>been doing design for several years and have only been using the "free" DW
>components. Now with Behavioral Compiler, my Synopsys sales rep is really
>pushing DesignWare, saying that without it BC can't work its magic. (The
>only facts I can distill from my AE and the databooks is that I can't design
>pipelined arithmetic without DW.) He is also saying that in our industry,
>there is usually a DesignWare seat for every Design Compiler seat, which I
>found hard to believe.
From: khelifi@cae.ca (Djoudi Khelifi)
Hi John,
I'm a user of Behavioral compiler and DesignWare.
1.) BC is a very powerful tool for architectural exploration. You save
time and (vhdl lines) when coding in behavioral way.
2.) Coupled with BRT (behavioral retiming), BC performs a good job in area
and timing optimization.
3.) Designware is a very useful complementary feature for BC. The "magic"
is the capability of using piplined components and reducing complexity
of your BC code by encapsulating your bit-level logic operation
as DesignWare components.
4.) By using a DesignWare Developer you can create your own pipelined
arithmetic for BC.
This is only true if you change your RTL coding habits and learn how to code
in BC style way -- a specific design methodology.
- Djoudi Khelifi
CAE ELECTRONIQUE
---- ---- ---- ---- ---- ---- ----
From: TBOYDSTO@ic1d.Harris.COM (Theodore L. Boydston IV)
John,
I recently had the opportunity to use Behavioral Compiler for a couple of
mathematically complex blocks and was quite surprised at the high level
of resource efficiency the compiler produces. To get that efficiency and
verify the compiler's results, though, required overcoming many problems.
The first problem was trying to understand how Behavioral Compiler actually
constrains circuits. (This is a result of having to code your HDL quite
differently than you would if you were writing normal HDL Compiler code.)
This is compounded by Behavioral Compiler's ability to run in three different
constraining modes. Two of these modes give Behavioral Compiler the ability
to produce output that is timing and area efficient, although simulation
output between pre-synthesis and post-synthesis timing will, most likely, not
match! (To achieve pre-synthesis and post-synthesis simulations that match,
you must run Behavioral Compiler in a cycle-fixed mode, but then you will
not achieve the same timing/area efficiency!)
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. Oh, by the
way, these operations must exist in a single VHDL process (or Verilog always
loop) in order to achieve the best results. If you code multiple VHDL
processes or Verilog always loops, BC treats each as a seperate design!
Finally, achieving a design that has an asynchronous reset or strobes is,
well, a big pain in the buttocks! Optimally, Behavioral Compiler likes to
see one clock and a *synchronous* reset. This is because Behavioral Compiler
creates every design in terms of a state machine and associated logic.
(Behavioral Compiler does have the ability to use *asynchronous* reset, but
the output from pre- and post- simulations will not match!) If you use
strobes, you can only use an asynchronous reset, AND your pre- and post-
simulations will never match. (Oh, and when I SAY asynchronous reset, I do
not mean the obvious WAY of attaching a reset line to all the flops...
Oh No! -- Behavioral Compiler only puts asynchronous resets on certain
portions of the state machine. So, there are times where certain feedback
paths not in the state machine are not initialized and your simulation never
becomes defined!) The whole idea that I cannot use asynchrounous resets bugs
me, especially when I am using a resource limited device like an FPGA.
As for DesignWare, you will probably need it if you are doing a large design,
because of the 150 operations/process rule. Design Compiler only utilizes
the few of the non-free designware components, like the pipeline multiplier.
If you want to use any of the other DesignWare components, you will have to
instantiate them just like in your normal HDL code.
In summary, if you are building a design that has one clock and no strobes
and many small partitions, I say go for it. Otherwise, if you are doing a
complicated synchronous designs that use multiple strobes or resets, I would
be extremely careful using Behavioral Compiler. Hope this helps!
- Theodore L. Boydston IV
Harris Corporation
|
|
