( ESNUG 270 Item 5 ) -------------------------------------------- [10/31/97]

Subject: (ESNUG 267 #1 268 #5 269 #4) *WHO* Is Using Behavioral Compiler?

> 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).
>
> - Victor J. Duvanenko
>   Truevision


From: [ A Synopsys BC CAE ]

John, This really depends on how Victor wishes to use BC.

If you choose to use BC in the super-state mode, then the tool has
additional degrees of freedom.  These degrees of freedom can be used to
adjust latency and other cycle-specific behavior.  If you want to take
advantage of efficiencies which can be generated by allowing the
compiler to decide when an output becomes available then you need to be
careful at the interfaces.  Using a data available signal to handshake
with external blocks can make your design more robust, flexible and
reusable in general.  When the cycle specific timing is unknown then the
handshaking is essential.

If using handshakes is unacceptable within your design methodology then
BC can equally be used in cycle_fixed mode which preserves the
cycle-specific behaviour of the design at the behavioral, RTL and the
gate level. BC is still able to schedule and share operations etc in
your design.

  - [ A Synopsys BC CAE ]


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

> About 6 months ago, I evaluated Behavioral Compiler for use in a DSP modem
> asic.  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


From: [ A Synopsys BC CAE ]

Hi, John,

As you know, the Verilog language allows you to create parameterized designs
by overriding parameter values in a module during instantiation.  In Verilog,
you can do this with the defparam statement or with the following syntax:

    module_name #(parameter_value,parameter_value,...)  \
            instance_name (terminal_list)

Currently neither HDL Compiler or Behavioral Compiler supports the Verilog
defparam statement, but HDL Compiler does support the above mentioned syntax.
Behavioral Compiler does not support the previous statement per se because
it does not support component instantiation.  However, this ESNUG reader
might be interested to know that it is possible to use parameters to define
bit widths or latency for modules within Behavioral Compiler.  Define your
module as follows:

    module par_des (a, b, c);
      parameter in_width  = 8;
      parameter out_width = 16;
    input  [in_width-1:0]  a, b;
    output [out_width-1:0] c;

Now, these parameters can then be overwritten at elaboration time using:

       elaborate -s par_des "in_width=>16,out_width=>32"

Of course, the RTL blocks which instantiate the Behavioral Compiler blocks 
can still use the "module_name #(parameter_val..." from above.  And for
those VHDL users out there, you can of course use generics instead of
parameters.  :-)

  - [ A Synopsys BC CAE ]


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

> 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.
>
> - Victor J. Duvanenko
>   Truevision


From: [ A Synopsys BC CAE ]

John,

For designs that contain memories and/or sequential Designware components
that BC is required to stall, Victor Duvanenko is absolutely correct.  For
other designs, BC can support the stall functionality.  We are currently
planning on expanding the scope to include memories and sequential
Designware components.

  - [ A Synopsys BC CAE ]



 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)