( ESNUG 265 Item 5 ) -------------------------------------------- [9/10/97]
From: Hesham El Adly <hesham@cae.ca>
Subject: Impressions Of BC With BOA, BRT, DesignWare Developer, & BCView
Hi John,
I've read with some interest the comments about BC recently on ESNUG. I
thought that I would share some experiences with BC mixed with BOA, BRT,
DesignWare Developer, & BCView.
We've been using BC for quite some time and are fairly experienced with the
"subtleties" of the tool. We design high-end real-time graphics systems for
the commercial and military flight simulator market.
Our deep sub-micron ASIC designs are datapath intensive and highly
synchronous. Our datapaths typically use large-bit width operators, make
extensive use of pipelining, and are sometimes massively parallelized to
meet performance goals.
We've focused much of our efforts with BC on using its BOA/BRT optimization
capability since most of our resources are clocked on every cycle - ergo no
scheduling required.
BOA, Behavioral Optimization of Arithmetic functions, can transform a
datapath structure to a functionally equivalent structure using faster
arithmetic operators such as carry-save-adders. Engineers skilled at
datapath design have been manually coding their datapath to perform
"BOA type" optimizations for years but BC can do some of these
optimizations nearly automatically. Timing of datapaths arranged in
tree structures can be improved with BOA with a potential hit in area
and without requiring the engineer to be a datapath expert.
BRT is just a smarter "balance_registers" that requires a BC license. BRT
can move registers across hierarchy and will try to place registers where
they have the least area impact. "Balance_register" will simply place
registers at fixed points in a timing path without taking into account the
area impact. "Balance_register" is also not able to move registers across
hierarchy.
We still schedule some of our designs through BC to take advantage of some
BC features such as loop pipelining, automatic fsm generation, etc. We
also, of course, have many RTL blocks that are compiled with DC.
Wrapping sections of code with DesignWare Developer is a critical
requirement in achieving high performance designs with a behavioral
methodology. Wrapping components is done to:
- improve timing accuracy
- speed up BC compile time
- reduce complexity of a design to BC
- encapsulate memories
In order to speed up compile, BC makes some assumptions as it times through
operators. Unfortunately, these assumptions sometimes leads to operators
that BC thinks do not fit into the specified cycle time. These same
operators, when compiled (default switches) with DC, are then sometimes
found to meet the cycle constraint. This issue can be resolved by either
pre-compiling these components and wrapping them or by relaxing the clock
period through BC.
DesignWare Developer is a very useful tool but is unfortunately difficult
to use properly. Synopsys needs to put some effort into improving
Developer's ease of use, providing more automation, improving its error
reporting, and providing better documentation.
One stumbling block many users have with BC has been with the lack of an
efficient interface. Users trying to debug their designs are sometimes
frustrated by the difficulty in understanding and correlating BC's reports.
With the introduction of BCView, the interface has been greatly improved.
The new graphical interface is very intuitive and a breeze to learn. We
have been using BCView for the last few months and have been part of its
beta program.
Overall, we have been successful in using a behavioral methodology with
BC. I hope I have not sounded too much like a cheerleader - we've had some
frustrating issues with BC but we've been able to resolve most of them by
working with Synopsys.
- Hesham El-Adly
CAE Electronics Ltd, Quebec
|
|
