[ Editor's Note: This is a continuation of ESNUG Post 235. - John ]
( ESNUG 236 Item 1 ) ---------------------------------------------- [3/96]
Embedded Memory Issues
----------------------
+ Inferred memory requires DesignWare model
One nice feature of BC is its ability to infer memory and the required
read/write manipulations from a simple Verilog array. Use is simple:
reg [23:0] CLUT_m [0:256;
/* synopsys resource RAM_CLUT_m:
variables = "CLUT_m",
map_to_module = "RAM_256x24"; */
RGB_r = CLUT_m[Index_r]; // generates all the operations to read
This requires that you obtain a DesignWare model of the memory element.
The DesignWare model turns out to simply be a wrapper with some
indications to Synopsys of how to control the RAM. Apparently, Synopsys
expects these models to be supplied by your local ASIC vendor. This
situation would eliminate the requirement for every customer to own
DesignWare developer. Due to the newness of the product, most ASIC
vendors may not setup for this quite yet.
Such was the case for us. Since we desired to use this feature, then we
had to obtain a solution. Synopsys does currently make available a short
term license for DesignWare developer; however, in the end we chose to
purchase the product.
Another issue that did not come up for us, was that BC only manages
synchronous designs. Thus you need to create a wrapper providing such an
interface to your memories for this style usage.
+ Dual port memories managed as external RTL with m4 macros
Unfortunately the above memory feature is only supported for single port
memory. Synopsys is rumored to be working on multi-port memories, but
don't hold your breath. Some of the implications are quite difficult.
Since we had some dual port memories, we considered several approaches.
One interesting approach tried was to use the dc_shell externalize_cell
command on two single port memories, and create a special memory wrapper
module to connect the two. This has some the bad simulation implication
that behavioral code was not simulatable without nasty ifdef's.
In the end, explicit external memories (RTL module) was settled on. To
simplify coding, a common access technique using text macros was created.
There were macros to declare external memory ports, read and write them.
The timing delays discussed previously were incorporated into this macro
set.
Licensing Issues
----------------
+ DC uses BC license unexpectedly
A familiar and undesirable aspect of BC is that of license requirements.
At the outset, I expected the tool to require licensing for only the new
commands (e.g. bc_check_design and schedule). It turns out that during
dc_shell compile, there are times when the Behavioral-Compiler license is
required. This is not dissimilar to HDL-Compiler license usage which has
been highlighted previously in ESNUG postings.
On the other hand I had the expectation that the output of the schedule
command along with writing a behavioral db file would be an RTL
database. I had hoped to run BC in parallel with multiple RTL compile
jobs (including BC scheduled jobs). Instead, a script to wait on BC
license availability and acquire it was used prior to all compiles. This
allowed us to fire off jobs without fear of loss. It did slow down
overall compilation.
It is our recommendation that your BC license to DC license count be
closer to 1:1 if you wish to maximize parallel job execution. Due to
budget constraints, we did not choose this option, and remained with 1:2.
DC supports limited behavioral style without BC license!
One large surprise came late into the project when a particular module
failed to compile successfully. Synopsys was called to resolve the
issue. They acknowledged a bug, and suggested as a work-around that I use
RTL compilation of the module unchanged. I was surprised to say the
least. They pointed out that this module used a fixed schedule and did
not invoke any of the fancier BC features. Apparently, the standard
HDL/DC compiler accepts the behavioral compiler coding style for "simple
fixed cycle" designs.
Talking with other Synopsys folks it was clear that this feature is not
very well documented nor understood. This area is currently under
investigation by Synopsys marketing (surprised them slightly).
I did a simple experiment to verify this feature by sending a toy ALU
example to an associate at another company that did not have access to
BC. He was able to successfully compile this design under 3.0c! It is
suggested that caution be used in this area until Synopsys documents this
better.
DesignWare Issues
-----------------
+ DW Developer almost required
As mentioned earlier, DesignWare developer is needed to create wrappers
for inferred memory element unless your ASIC vendor happens to supply this
for you. There are some other areas where this tool appears to be almost
a required part of the design toolset. Fortunately, it is likely that
only one license is needed for an entire site. This is because once
developed, DesignWare models can be bundled and used by multiple users.
Reduce the number of operations seen by BC
One area that makes DesignWare Developer highly attractive is its impact
on the performance of behavioral compiler. As the number of operators in
a design grows, the number of scheduling possibilities increases
exponentially and with it compilation time. One of our designs became
slow enough that we asked for help. The recommendation was to identify
common operations and implement them as functions mapped to DesignWare.
After trying this, our compile times reduced substantially (hours rather
than days).
+ pipelined multiplier to improve timing
A second area benefiting from DesignWare, was that of timing. In one
situation, a series of operations was failing to meet timing. By
implementing a multiplication operator as a DesignWare component and
implementing it as a registered operation, we were able to pipeline the
operation into two cycles and meet our goals.
DW models can be simple
Finally, lest you fear the "yet another tool to learn", I found that
DesignWare models do not have to be complex. Certainly, if you plan to
optimize area and timing for a variety of bus widths and technologies for
use by a lot of varied engineering groups, then there is a large cost
associated with design, testing and documentation. However; for
application specific models, you can write models quickly in Verilog with
reasonable performance.
In fact Synopsys provides a script to analyze your functions and create
wrappers for this task. I went further and was able to use the initial
functions as the implementation. Using a homegrown mini-tool I am able to
quickly generate DesignWare models with very little overhead.
Execution Issues (v3.3b)
In general, I had very few execution problems with this tool; however,
there were a few rough spots. In all cases, Synopsys was extremely
responsive and helpful. This section of the paper illustrates the types
of issues that come up with early adoption, and to note that Synopsys does
address them.
+ HP not supported as well as Sun
Synopsys internally appears to develop first for Sun and then follows
quickly with a port to HP. There are some differences that I experienced
as a result of this. Several times early in development (v3.2a), BC
fataled during scheduling. I came to discover that error handling on the
HP workstations was not as graceful. As a work-around it was suggested
that I compile behavioral code on Sun for these cases. At the time I only
had access to an HP. Fortunately, for reasons entirely separate from
Synopsys, we were in the process of acquiring a Sparc workstation. This
"mini-crisis" helped to speedup the acquisition, and it solved my problems.
To my knowledge, the above problems have been solved on HP for v3.3b, and
I now routinely compile on any available platform without concern. I do
not have any official statement that Synopsys has done anything to address
the "Sun first" issue, and so this could crop up again for me other
"feature".
+ Problems with large case statements (register selects)
We also encountered an issue when a module apparently had a "large" case
statement and was taking extremely long (>18 hours) time to compile.
Synopsys acknowledged that this was to be addressed in a future version of
design compiler. They suggested I break down the case statement and drop
the parallel_case directive if possible. This did help a bit. I am eager
for this to be addressed.
+ Problems with synchronous reset controls
Finally, a familiar "feature" seemed to rear its ugly head again. The
issue was "synchronous resets". Apparently, a default setting of some
variables combined with my settings to create a fatal situation. A quick
call to the factory, providing them with a test case and some discussion
revealed the problem. Simply, setting the variables correctly avoided the
problem; however, it did take some time to track down.
Naturally, none of these "features" appeared at a good time, and they all
introduced small delays. They also provided learning opportunities and
are for leading edge design a part of the landscape. None of this reduced
my respect for the company, because they responded quickly with honest
answers, and an intent to help me solve my problems quickly.
Training Issues
---------------
I am not aware of the state of the current Behavioral training for Verilog
course, but expect it has improved. When I attended training in March
1995, everyone was surprised that the "Behavioral Compiler training for
Verilog" included a one day crash course in VHDL! Although, the material
for the rest of the week was attempting to be Verilog; they were not
certain enough at the time to rely on Verilog only. As the course was
new, I will do give them credit for having a course together with short
notice.
A nice feature of the course for me was that the main example was a video
processing design. I am also encouraged that the course used a
substantially sized example instead of the typical dozen gates so often
encountered in classes. It is always frustrating to compile small designs
in class and then go back to the real world. They have done an excellent
job in this area.
Another aspect that could have been improved was spell checking and
verification that code and script examples worked as shown (cut & paste
back into Synopsys). This comment applies to most EDA training.
Overall, I do recommend Synopsys' training for this product. Don't try
this product without training or at least get a copy of the course
material!
Documentation Issues
--------------------
Once again, I am reminded that Synopsys has a VHDL leaning whenever I read
the manuals. Although, the examples always include Verilog; it appears
obvious that the writers feel more comfortable in VHDL. I think separate
manuals for Verilog behavioral compilation might improve the situation
because it would force a Verilog thought process on the documentation.
Another opportunity for improvement is better documentation of all the
Synopsys pragmas that are embedded in Verilog as stylized comments. In
several cases, there is no "syntax" or specific rules. Trial and error
have worked, but leave an empty feeling. Personally, Backus-Naur Format
(BNF) would be a great improvement; although, it might leave some
non-programming types out cold.
Finally, it would be nice to understand fully what pieces of the
behavioral coding style are supported outside of the BC licensing.
Synopsys marketing can view this as a sales tool since many of the major
benefits are not experienced without the license (e.g. superstates and
pipelining).
Enhancement Requests
--------------------
Having experienced the tool, I have several feature requests for Synopsys
to work on. Some are currently under investigation.
+ N port memory management (tricky)
Memory inference of single port RAM's is nice. Can the same be done for
dual ported memory?
+ Optimize case statement usage
As previously stated, large case statements need improved handling.
+ Improve multiplexor utilization
The ever present "how do I infer the best multiplexors for my
design/target library" question needs to be answered. With behavioral
compiler, I believe larger designs will have greater needs for good
multiplexor utilization. I understand some new features along this line
are in the works. I am hoping that multiplexors will become DesignWare
mappable operators.
+ Support HDL Advisor
HDL Advisor is an exciting product; however, it does not work for
Behavioral Compiler code. Work is being done to remedy this. Hopefully,
the result is an integrated solution and not a "Behavioral Advisor"
product. Real designs will involve both behavioral and RTL code. Advisor
is useless without both from our perspective.
+ Provide inexpensive DW developer for wrapper only models
For applications not requiring the other advantages of DesignWare
Developer (i.e. performance or library licensing), it would be ideal for
Synopsys to provide a RAM wrapper only version of the tool bundled or at
low cost.
+ Improve HP support
For support issues and performance, I prefer HP platforms for EDA
applications currently. It would be nice to receive the same level of
product for any/all supported platforms.
Closing Remarks
---------------
Synopsys Behavioral Compiler is an excellent product. Especially
considering its youthfulness as a product (just over a year old in
production). I would really hate to be forced to go back to RTL only as a
coding approach. This product has definitely improved productivity.
I would like to complement the Synopsys staff for being very helpful and
responsive to our issues.
One area to complain about is cost. Real designs also need: HDL Compiler,
Design Compiler, and beneficially DesignWare Developer. Add up the cost
of these tools, and the small developer or team is left out in the cold.
This is a marketing issue, but likely solvable via creative licensing.
The plethora of inexpensive synthesis tools showing up is beginning to
show, and I believe Synopsys will need to adapt.
Finally, I must say this has been an enjoyable experience in spite of the
frustrations. Yes, I would do it again.
- David C. Black
Apple Computer
|
|
