( ESNUG 266 Item 5 ) -------------------------------------------- [9/18/97]

Subject: (ESNUG 262 #4 263 #1 264 #2) *WHO* Is Using Behavioral Compiler?

> I waited 3 years. I was starting a new project and brought BC in again.
> It seemed to have matured a bit and the AE's were competent. They
> also had an example design similar to my architecture.  The deal was
> that I would go to a BC training class (which I did). Then I would write
> the behavioral code and testbench (which I did).  They would "BC" it and
> give me back an RTL model and gate netlist which passed the testbench.  At
> that point I'd be obligated to purchase the tool (as long as there were
> no surprises). Everyone agreed this was a perfect target design for BC.
>
> For 6 months they worked on the design. They said over-and-over that they
> almost had the RTL working.  I finally ended it.  Again they were
> surprised. I never received a report or explanation for the poor results.


From: samng@corp.cirrus.com (Sam Ng)

Dear John,

I have use BC on and off for approximately 1 year mainly on 3D graphics 
accelerator designs.  The design I have used BC on is a triangle setup
/geometry  processing engine of ~40K gates in size at running at 100MHz.

The 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.

BC has done largely what I want but there are a few things to improve on
eg. unable to share memory between process (there is a tedious work-around),
unable to perform scheduling for a pre-existing architceture and lengthening
of schedule whenever conditional statements are encountered.

  - Sam Ng
    Cirrus

         ----    ----    ----    ----    ----    ----   ----

         ----    ----    ----    ----    ----    ----   ----

  [ Editor's Note: What follows is an exchange of specific e-mails on BC
    between Dwayne Bennet, Steve Molloy, and Arthur Marris.  - John ]

From: Dwayne Bennett <Dwayne.Bennett@Matrox.COM>

> My experience with BRT was very positive.  I had a circuit which needed an
> extra stage, but adding this extra stage would have seriously affected
> performance of the circuit and this could not be tolerated (the chip was
> for a giga-bit Fibre Channel Switch and operated at 53Mhz.)  The solution
> was to better make use of the stages I had by optimally placing them along
> the critical path.  Unfortunately this path involved indexing into arrays
> and so changing the placement of stages in verilog RTL would have been a
> mess and would have been time-consuming.  This is when I turned to BC.
> The change to the synthesis script was trivial; I just added the command 
> "optimize_registers" and let it run.  It resolved the problem and the
> circuit was able to meet our timing goals.  The cost in gates was minimal.
>
>  - Dwayne.Bennett
>    Matrox


From: molloy@ix.netcom.com ( Steve Molloy )
To: Dwayne Bennett <dbennett@matrox.com>

Dwayne,

Couldn't you have just used the balance_registers command of design compiler
to get the same effect?  This shifts around the existing registers in a
design to balance the delay between registers.

Just wondering,

  - Steve Molloy

         ----    ----    ----    ----    ----    ----   ----

From: Dwayne Bennett <dbennett@matrox.com>
To: molloy@ix.netcom.com ( Steve Molloy )

Agreed, Steve,

The two commands are similar but optimize_registers considers area in
determining placement of stages. 

  - Dwayne.Bennett
    Matrox

         ----    ----    ----    ----    ----    ----   ----

From: Dwayne Bennett <Dwayne.Bennett@Matrox.COM>

> I might add that a change to the verilog not only would have taken up my
> time, but also would have forced a slew of regression simulations to have
> to be re-run.  I think it is clear that BC/BRT saved me significant time
> and effort.
>
>  - Dwayne.Bennett
>    Matrox


From: Arthur.Marris@tiuk.ti.com ( Arthur Marris )
To:	Dwayne.Bennett@matrox.com ( Dwayne Bennett )

Dwayne,

Interesting comments you made.  Didn't you have to run a slew of regression
simulations on you gate level model after running BRT?  Or do you assume
that what you get out of Synopsys is correct by construction and not bother
doing exhaustive simulations of your gate-level netlist?

  - Arthur Marris
    Texas Instruments

         ----    ----    ----    ----    ----    ----   ----

From: Dwayne Bennett <dbennett@matrox.com>
To:	'Arthur.Marris@tiuk.ti.com'

Hi Arthur,

Yes, chip-based gate-level sims were run following synthesis, but a long
set of system-level source-code simulations were not necessary to repeat
since the source code was not actually changed.

  - Dwayne.Bennett
    Matrox



 Sign up for the DeepChip newsletter.
Email
 Read what EDA tool users really think.


Feedback About Wiretaps ESNUGs SIGN UP! Downloads Trip Reports Advertise

"Relax. This is a discussion. Anything said here is just one engineer's opinion. Email in your dissenting letter and it'll be published, too."
This Web Site Is Modified Every 2-3 Days
Copyright 1991-2024 John Cooley.  All Rights Reserved.
| Contact John Cooley | Webmaster | Legal | Feedback Form |

   !!!     "It's not a BUG,
  /o o\  /  it's a FEATURE!"
 (  >  )
  \ - / 
  _] [_     (jcooley 1991)