"Stock prices have reached what looks like a permanently high plateau."
- economics professor Irving Fisher of Yale University, a few
months preceeding the October 1929 stock market crash
( ESNUG 359 Subjects ) ------------------------------------------- [9/13/00]
Item 1 : May God Help You If You Use The Synopsys Dual-Clock DW FIFO Parts
Item 2 : User Reactions To Cadence's New "cdsdoc" (OpenBook Replacement)
Item 3 : BOA, simple_compile_mode, Area Recovery, Vera, & Boston SNUG'99
Item 4 : Tools/Ways To Draw On-Grid 45 Degree Lines In Cadence Layouts
Item 5 : Designer Seeks DC/PT Script To Detect Paths Across 2 Clock Domains
Item 6 : How Would You Design An Over 64-bit Multiplier-Accumulator (MAC)?
Item 7 : My Design's Very Small & I'm Looking For Cheap-But-Good ATPG
Item 8 : Workaround For A Little Control-C "dc_shell | tee logfile" Gotcha
Item 9 : Exactly How Did You Use ClearCase For Your Design Data Management?
Item 10 : ( ESNUG 358 #7 ) DW PCI Core Doesn't Work For Both FPGAs & ASICs!
The complete, searchable ESNUG Archive Site is at http://www.DeepChip.com
( ESNUG 359 Item 1 ) --------------------------------------------- [9/13/00]
From: "Jay Adams" <Jay.Adams@marconi.com>
Subject: May God Help You If You Use The Synopsys Dual-Clock DW FIFO Parts
Hi, John,
You may be aware Synopsys admits 2 bugs in the DesignWare dual-clock FIFOs
and FIFO controller (DW_FIFO_S2_SF and DW_FIFOCTL_S2_SF.) Those are only
the beginning. Here are two additional features that they did not tell you
about:
1) When in the almost_empty state, the pop_ae flag can be deasserted at
any time there is a push, regardless of the number of words in the
FIFO. There is similar behavior for the half_full & almost_full flags.
2) When pushes and pops are occurring simultaneously, the empty state can
be mistakenly hit regardless of how many words are in the FIFO. Yes,
that's right, the empty state, and if your logic can't tolerate a
break in the data flow or you don't monitor the empty flag, then you're
screwed.
In other words, the flags on these Synopsys dual-clock DW FIFO parts are
useless.
I'm not going to explain the nuances of this behavior, I expect Synopsys to
do that and my time is needed to salvage the DISASTER that Synopsys has put
me in. I am writing this note because it is Synopsys's opinion that the
behavior designed above is as they designed it. Heres a summary of their
position:
"Yes, we are coming out with a new version on the next CD release
that doesn't exhibit these "qualities", but that is in no way is an
indication that we have done anything wrong in this component. Since
the FIFO is working as *we* have always intended it to, we do not
intend on informing the design community."
And heres one more bit of information. The FIFO model that they intend on
including in the next CD release will fix the above bugs, but only if the
depth is a power of 2. If its not a power of 2, then the bugs can still
occur! They claim that they will document this clearly. They also claimed
to me that bugs I listed are also documented in the current documentation.
So go read that and decide for yourself what they mean by documentation.
So heres what I say to the design community: If you are using Synopsys's
dual-clock DesignWare FIFO controllers - May God be with you. This only
applies to the dual clock FIFO controllers, because I'm sure that everything
else in DesignWare is absolutely stable and that they are not holding any
"as designed" behaviors to themselves.
- Jay Adams, Manager, ASIC Design
Marconi Communications Warrendale, PA
( ESNUG 359 Item 2 ) --------------------------------------------- [9/13/00]
From: jdl@user2.teleport.com (Jay Lessert)
Subject: User Reactions To Cadence's New "cdsdoc" (OpenBook Replacement)
Let me preface this by saying that it *is* possible that I'm the only
Cadence customer in the world that actually likes OpenBook. :-)
But I've found OpenBook to be far and away superior to any on-line
documentation I've used from Mentor, Avant! or Synopsys.
I just loaded LDV 3.1 (I'm currently running IC 4.4.3/4.4.5 and LDV 3.0
in production), and was surprised to find OpenBook gone, replaced by an
HTML-based thing called cdsdoc. They fire up an http server (from
Verity, Inc., apparently) on localhost port 9000, attempt to hijack any
web browser you already running, and away you go.
I've no quarrel with the document *content* (which is largely unchanged,
as you would expect). But I've run into the following miscues, omissions
and differences compared to OpenBook. I'm not happy.
1) We fire up an http server running as the user on port 9000. I know
nothing about Verity Inc., but if I was in a security-conscious
environment, I would *never* do that with (e.g.) Apache; it's just
asking for trouble.
2) We hijack the existing Netscape browser window if it exists. Bad
idea. Guess what? I had that window up for a *reason*, and I didn't
want it to disappear without warning.
3) cdsdoc is useless unless we have JavaScript enabled on the
browser. Blank pages. Apparently no one at Cadence is aware of
the vast array of JavaScript security problems embodied in modern
browsers. This is really very serious.
Worse, there is no attempt to warn of this, either in the HTML, or
in the documentation.
4) While the content of documents (e.g., Verilog-XL reference manual) is
the same, the formatting is no where near as good as OpenBook; this
is to be expected with HTML, of course, and the formatting is not
bad, considering. But a loss nonetheless.
5) The search window is replaced when I say "Go" (replaced by the
search output). This makes iterated, increasingly refined searches
much more painful. Unforgiveably, when I hit "Back" to return to
the search page, there is no history. Hmmm, no, I see. You only
get history with cookies enabled, another security problem, and
no attempt to warn the user.
Even with cookies enabled, the history is only for the "current"
search, nothing like OpenBook's history list.
6) The documents I've looked at so far have no hot-button for Index,
so I have to go to Contents, *then* Index. This should be pretty
trivial to fix, of course.
The Verilog-XL Reference Index takes 5 seconds to load every single
time I go to it (Ultra30/300). This appears to be Netscape rendering
time, I guess. OpenBook is instant once the document is loaded.
I think I understand the motivation behind the change (Adobe declines
to port Frameviewer to Linux, right?), and if I only compare cdsdoc to
Mentor & Avant!'s offerings, it still whips 'em pretty good.
But I'm gonna cuss every minute I spend over the next two-three years
getting cdsdoc up to where it needs to be. C'est la vie, huh?
- Jay Lessert Portland, Oregon
---- ---- ---- ---- ---- ---- ----
> Let me preface this by saying that it *is* possible that I'm the only
> Cadence customer in the world that actually likes OpenBook. :-)
>
> But I've found OpenBook to be far and away superior to any on-line
> documentation I've used from Mentor, Avant! or Synopsys. ...
>
> - Jay Lessert Portland, Oregon
From: jeffb@el.nec.com (Jeff Buckles)
You're referring *only* to the Cadence doc infrastructure, right? Their
doc tools, formatting and layout, not the content? I hope?
At risk of starting a "my docs were worse than your docs" war, I must say
that the only documentation *content* that I found less useful than the
Cadence doc was the old Valid documentation. Of course nothing could beat
the ASIC vendor's doc that explained an "Item Error" message by "There is
an error in the item".
Here's an example: The CTGEN documentation uses the expression
"rise_fall_min_max" in the syntax description for some commands. One could
reasonably expect to find the definition of "rise_fall_min_max" by going to
section "R" in the index. To quote a co-worker "You could think that. But
you'd be wrong."
It has been this way *any* time I try to find useful information in
Cadence's OpenBook, among physical verification, physical design, timing,
and P&R tool docs. Only the Verilog docs come close to having a useful
index.
So, thanks for raising the topic, thereby giving me a chance to vent this
long-suppressed rant. Now I'll sit back and start watching the flames fly.
Oh, regarding the HTML docs, HLD seems to have gotten it pretty close to
"right". They still "hijack" your browser ( -remote OpenURL() ) but they
reference a static hierarchy of html files that (IIRC) do not use
javascript. Too bad Cadence didn't stick with this....
- Jeff Buckles
NEC Electronics Inc
Portland ASIC Design Center
---- ---- ---- ---- ---- ---- ----
> You're referring *only* to the doc infrastructure, right? The doc tools,
> formatting and layout, not the content? I hope?
From: jdl@user2.teleport.com (Jay Lessert)
Hmmmm, nope. I'm talking "percentage of time I find what I need in the
docs, and how long it takes me to find it".
> Here's an example: The CTGEN documentation uses the expression
> "rise_fall_min_max" in the syntax description for some commands. One
> could reasonably expect to find the definition of "rise_fall_min_max" by
> going to section "R" in the index. To quote a co-worker "You could think
> that. But you'd be wrong."
Use the force... :-) While it's unfortunate the some of the indices
suck, I just did a full search for "rise_fall_min_max", and hit the
BNF for rise_fall_min_max in the GCF reference manual:
rise_fall_min_max
::= NUMBER
||= NUMBER NUMBER
||= NUMBER NUMBER NUMBER NUMBER
Not that this is terribly exciting...
- Jay Lessert Portland, Oregon
---- ---- ---- ---- ---- ---- ----
From: Barbara Heninger <barbh@cadence.com>
Jay,
Thanks for your comments about using the new web-based online documentation.
Yes, change is annoying, and using a new system is always frustrating when
you're used to another. I'm appending an HTML file that outlines how to do
similar tasks in OpenBook and in the new web-based system. It was our goal
to avoid losing any features that were in the previous system. The
differences between the two browsers mean that we do have to do some things
differently.
Regarding some of the specific comments:
* If you prefer a "page"-like look and feel, we do provide PDF versions
of each of the documents. Click "View/Print PDF" from any document
and you'll open a PDF version of the entire book in Acroread/Acrobat.
The PDF versions include a hyperlinked table of contents, and hyperlinks
within that document are supported. The PDF versions are optimized
for printing part or all of a book.
* It's not clear how running a local http server compromises your system's
security. Can you explain your concerns in more detail?
* Over the years, we've received comments from customers both saying
we open "too many" windows, and saying we should always open
additional windows whenever opening any document. We get slightly
more comments asking us to re-use windows (that's why OpenBook
reuses its windows by default). We're going to add a "Preferences"
command to the next iteration of cdsdoc that lets you choose:
- Whether to open a new browser window when starting the system
- Whether to open a new browser window when showing Search results
At present, you can use your browser's New command to open a second
window and then start cdsdoc. Not optimum, I grant you.
* We use JavaScript 1.3 by default, which is available if you use Netscape
4.51 or higher or Internet Explorer 5.0 or higher. The requirements for
the browsers is stated in the documentation, but it doesn't state
explicitly that one reason is due to use of Javascript; I will add that
to the documentation now! Thanks for pointing this out.
* Cookies are not required, but as you note, turning them off means
any changes or entries you made in the Search form will not be
kept. Accepting cookies internally shouldn't be a security issue,
but I understand if your browser is on the web you may have turned
cookies off. I will add a note to the documentation about the
use of cookies.
* Yes, we are going to add a navigation button for "Index." We had
omitted it only because, at the time this system was developed,
many writing groups were not creating indices due to lack of manpower.
* You are correct, one reason for the change is that supporting a
separate browsing tool that is not always available on all platforms
is a big issue for us. But we also changed because, since 1996,
customers have been asking us when we would provide HTML-based
documentation. They preferred to use a single browser and were
familiar with web browsers, and they wanted to be able to link
directly to Cadence documents from internal sites.
At the International Cadence User's Group meetings in 1997 and 1998,
more than half of the users said they would like a web-based system.
Even more wanted a central website from which they could view documents,
but supporting that is more difficult due to issues regarding
which user has access to what document. We are still looking
into how to support this.
At the ICUG meeting in 1999, we showed a prototype of this system
and told users that this would be the future system. We asked for
feedback and got responses like "We've needed this for a long time!"
We asked users to try the system and a clear majority ("Yes" answers
ranged from 91% to 99% of responses) said that they thought the
new system would meet their needs for tasks like finding information
about their products, finding information in specific books, and
generally browsing installed documentation. Granted, looking at a
system in a demo is different than installing it on your own machine.
I appreciate your comments and hope that some of this information
can help you with the new system. I will also make the changes you
suggested in the documentation.
- Barbara Heninger
Sr. Tech Pubs Consultant
Cadence Design Systems San Jose, CA
[ Editor's Note: I put Barbara's html file in the "Downloads" section of
http://www.DeepChip.com to save space in this ESNUG post. - John ]
---- ---- ---- ---- ---- ---- ----
From: jdl@user2.teleport.com (Jay Lessert)
Barbara,
Thank you so much for your follow-up, it is greatly appreciated.
> * If you prefer a "page"-like look and feel, we do provide PDF versions
> of each of the documents. Click "View/Print PDF" from any document
> and you'll open a PDF version of the entire book in Acroread/Acrobat.
> The PDF versions include a hyperlinked table of contents, and hyperlinks
> within that document are supported. The PDF versions are optimized
> for printing part or all of a book.
I haven't noticed that yet. Yes, that should take care of the times
when you're doing extended reading and format matters more. At the
expense of a fair bit of disk, I suppose. :-)
% du -s ldv30/doc
61825 doc
% du -s ldv31/doc
120665 /tools/ldv31/doc
Yup!
> * It's not clear how running a local http server compromises your system's
> security. Can you explain your concerns in more detail?
This matters in organizations that need to enforce host-by-host
security. Universities are the extreme example, but some corporations
operate this way.
cdsdoc ends up with something like this:
katra:/home/jayl 6> bps | egrep 'PID|https'
USER PID %CPU %MEM VSZ RSS TT S STIME TIME COMMAND
jayl 11246 0.7 1.5 7128 3672 pts/6 S 13:56:11 0:00 ./https -port 9000 -silent -p cdsdoc
and anyone can connect to it:
katra:/home/jayl 7> telnet katra 9000
Trying 192.168.17.51...
Connected to katra.
Escape character is '^]'.
HTTP / 1.0
HTTP/1.0 200 OK
Date: Tue, 01 Jun 1999 10:10:10 GMT
Expires: Tue, 01 Jan 1980 10:10:10 GMT
Server: Verity CDPub Search Engine 4.0
MIME-version: 1
Content-type: text/html
Since the server runs as the local user, the concern is that (for
example) a buffer overflow/stack-smashing exploit on the server would
be able to run commands or read files as that local user. There are
any number of such exploits available for various versions of Apache,
IIS, Netscape/Enterprise, etc. this is one reason why a normal Unix
Apache or Netscape/Enterprise installation usually runs as user
"nobody".
A Google search for +exploit +apache, or +exploit +iis may be
illuminating. Even a search for +exploit +verity looks interesting,
though I didn't do any detailed reading. :-)
> Over the years, we've received comments from customers both saying
> we open "too many" windows, and saying we should always open
> additional windows whenever opening any document. We get slightly
> more comments asking us to re-use windows (that's why OpenBook
> reuses its windows by default).
My sympathies, I know you can't make 'em all happy. There is a bit
of qualitative difference between hijacking a Frameviewer window
(which is most likely not being used for anything besides OpenBook)
and hijacking a Netscape window (which is almost certainly being used
for 10 things besides cdsdoc).
> We're going to add a "Preferences"
> command to the next iteration of cdsdoc that lets you choose:
>
> - Whether to open a new browser window when starting the system
> - Whether to open a new browser window when showing Search results
Terrific. That goes a long way. Make sure I can set a default for
the full installation, then let users override if they need to.
> At present, you can use your browser's New command to open a second
> window and then start cdsdoc.
Yup, I'm opening training myself to grab Netscape and do an alt-N before I
click help.
> * We use JavaScript 1.3 by default, which is available if you use Netscape
> 4.51 or higher or Internet Explorer 5.0 or higher. The requirements for
> the browsers is stated in the documentation, but it doesn't state
> explicitly that one reason is due to use of Javascript; I will add that
> to the documentation now! Thanks for pointing this out.
The issue with JavaScript is security, not available versions.
In the paragraph below you can basically s/cookies/JavaScript/g.
> * Cookies are not required, but as you note, turning them off means
> any changes or entries you made in the Search form will not be
> kept. Accepting cookies internally shouldn't be a security issue,
> but I understand if your browser is on the web you may have turned
> cookies off. I will add a note to the documentation about the
> use of cookies.
That's a good start. Both JavaScript and cookies need to be in
doc/cdsuser/trouble.html, for sure. And it would be preferable
if the server could check and generate warnings, as well.
> * Yes, we are going to add a navigation button for "Index." We had
> omitted it only because, at the time this system was developed,
> many writing groups were not creating indices due to lack of manpower.
Good, thanks. You do have existing OpenBook documents that do have
good indexes (Verilog-XL reference manual comes to mind in the current
context), there's no reason to handicap it just because other documents
are deficient.
> * You are correct, one reason for the change is that supporting a
> separate browsing tool that is not always available on all platforms
> is a big issue for us. But we also changed because, since 1996,
> customers have been asking us when we would provide HTML-based
> documentation. They preferred to use a single browser and were
> familiar with web browsers, and they wanted to be able to link
> directly to Cadence documents from internal sites.
Hmmm, we've been running tools/bin/viewer from our .mailcap for years:
application/framemaker;viewer.netscape %s
application/msword;soffice %s
application/pdf;acroread %s
application/postscript;ghostview %s
application/vnd.ms-access;soffice %s
application/vnd.ms-excel;soffice %s
application/vnd.ms-powerpoint;soffice %s
> At the International Cadence User's Group meetings in 1997 and 1998,
> more than half of the users said they would like a web-based system.
Well, I guess you've finally given me a reason to go to ICUG. :-)
Thanks again for responding publically.
- Jay Lessert Portland, Oregon
---- ---- ---- ---- ---- ---- ----
From: "stockg" <stockg@yahoo.com>
The real reason for changing is neither User Group nor everything else
mentioned by the Cadence doc writer. They are follows in the order they
appear:
1. Adobe had said they would not support ANY FrameMaker from 2000 onwards.
Cadence had to look at other alternatives. Licensing for Framemaker
could have been the issue.
2. Speed of OpenBook. And here the web-page feel nad look had an advantage
over PDF. Although if I know correctly, Cadence is still working on
getting the PDF version too later.
This is also a good time to request for any changes like a new browser. And
it should be easy to implement even for a hotfix. I believe this way they
also introduce a mechanism to give a doc for hotfix, too. Else we were
stuck with the same doc for the 100th hotfix of the same release.
- "stockg"
---- ---- ---- ---- ---- ---- ----
> The real reason for changing is neither User Group nor everything else
> mentioned by the doc writer. They are follows in the order they appear:
>
> 1. Adobe had said they would not support ANY FrameMaker from 2000 onwards.
From: jdl@user2.teleport.com (Jay Lessert)
"stockg",
Can you provide a reference for this claim please? No sign of dropping
FrameMaker on www.adobe.com that I can find, and there are a large
group of manual and databook writers back at my day job that will be
most unhappy if they have to start working in Word or StarWriter or
such.
- Jay Lessert Portland, Oregon
( ESNUG 359 Item 3 ) --------------------------------------------- [9/13/00]
From: [ Original Author Unknown ]
Subject: BOA, simple_compile_mode, Area Recovery, Vera, & Boston SNUG'99
[ Editor's Note: This is a user trip report from last year's Boston SNUG
(1999). I accidentally found it on a search of my database and, after
reading all the technical meat, thought it worthy of ESNUG. - John ]
This is a quick trip report, for the Boston SNUG. In general the two-day
conference was very useful, and has highlighted some areas that we may want
to think about.
Big technology "takes" - described below.
a) compile_sequential_area_recovery = true
b) hdlin_use_cin = true
c) Multibit Register Inference
d) Don't use full_case parallel_case
e) Plan verification early, and have a dedicated team to do it.
The first day was a day of tutorials, and the second day was user sessions.
I have the entire proceedings on my desk if anyone is interested in reading
the presentations. I will only comment on the sessions I attended, although
some of the others looked useful, and may well be worth a look.
The first tutorial I attended was the "Getting the most from Design
Compiler: Area optimizing techniques and synthesis for high performance
designs". This tutorial was basically talking about, designs that are
multi-instance, multi-channel, parallel, designs running less than 100Mhz.
Set_Max_Area
------------
Set to 0 to enable the best area recovery.
DC now has three compile steps now, with delay being prioritized over area;
they are:
1) Delay optimization TNS
2) Design rules fixing 1 ( delay highest priority)
3) Design rules fixing 2 ( design rules highest priority)
4) Area optimization.
TNS is the Total Negative Slack of a design (i.e. the sum of all the worst
negative slacks per endpoint.) DC can prioritize area over TNS by the
set_max_area -ignore_tns. A critical range can be set to further optimize
critical paths, BUT an overly aggressive value will hurt run-time. TNS is
also shown as a column in the compile log.
Simple_Compile_Mode
-------------------
Simple_compile_mode has the following benefits compiles faster, reduces
area, does not need a uniquify, and automatically does a bottom up compile.
This is for designs that don't have aggressive timing goals, have multiple
instances, spends significant time during High-Level optimization, and
doesn't spend significant time in top-level optimizations such as DRC,
set_fix_hold, and global nets.
We may not be able to use this, but it may be a good "initial compile"
thought. It is set PRIOR to a compile by set_simple_compile_mode true.
Area_Effort
-----------
Compile has a new switch -area_effort [none | low | med | high]. Focuses
compile onto area, by taking advantage of wide fanin gates. This follows
the value of -map_effort, and vice-versa.
Sequential Area Recovery ( THIS COULD BE GOOD)
----------------------------------------------
Enabled by compile_sequential_area_recovery = true. It remaps all the
sequential cells to try and recover area, but doesn't hurt critical path
slack, and may reduce positive slack.
Behavioral Optimization of Arithmetic (BOA)
-------------------------------------------
This is a set of arithmetic transformation techniques that optimizes the
implementation of arithmetic functionality performed by transform_csa. It
uses Carry Save Arithmetic (CSA).
Behavioral Retiming (BRT)
-------------------------
This moves registers around combinational cells, using sequential
optimization techniques. Has a primary goal of timing, with a secondary goal
of area. It preserves functionality at I/O boundaries.
Other Switches To Control Area
------------------------------
hdlin_use_cin = true (this looks good for us - not the default either)
hdlin_infer_mux = default (this is the default, and OK)
hlo_resource_allocation = area_only (not advisable, let the default be)
hlo_resource_allocation = area_only (not advisable, let the default be)
compile -top This only optimizes paths through the top level. This
could be good for us.
The big "takes" for this were compile -sequential_area_recovery, and
hdlin_use_cin. It may also be good to have a look and see how the compile
-area_effort works for us. BOA and BRT look good, but probably won't do
anything for our designs. Also some of these need the DC ultra license,
which we have fewer of.
The afternoon session that I attended was "Breaking the Verification
Bottleneck: Hierarchical Functional Verification". This was primarily a
high level overview, and really did not tell anything that we had not really
thought about before. Maybe an interesting read in your spare time.
Friday brought two user sessions and the keynote speech from Aart de Geus.
The speech was good, and focused on the direction Synopsys is heading in.
There are three areas that they are trying to link together - Physical
Synthesis, IP design and re-use, and High level verification. This has been
enabled by a bunch of new products - TetraMAX, VERA, Chip Architect,
FlexRoute, Core Consultant, and Core Builder.
The first user session was "Synthesis / Design Productivity", which was
split into three presentations.
1) Using Multibit Register Inference. This was good, and is something
that I think we would really want to do. It revolves around using
bus wide cells in the library, instead of using single bit cells.
Ultimately the best implementation is to have wide cells in the
library (which I have begun to pursue), but it can have an impact with
out this. Turned on by hdlin_infer_multibit = default_all. Usage of
the automatic multibit inference capabilities available in Synopsys
leads to a fully-automated flow of inferring gated clocks with
associated power savings of up to 60%. Combined with an innovative
cell design, the inference technique provides area savings of up to
50% in storage elements area, which in turn lead to area savings of
up to 15% in chip area. Tight control over the structure of the
multibit elements enables low-skew CTS, even when combined with
non-gated storage elements.
2) "full_case parallel_case", the Evil Twins of Verilog Synthesis. Two
of the most over used and abused directives included in Verilog models
are the directives "// synopsys full_case parallel_case". The popular
myth that exists surrounding "full_case parallel_case" is that these
Verilog directives always make designs smaller, faster and latch-free.
This is false! Indeed, the "full_case parallel_case" switches
frequently make designs larger and slower and can obscure the fact that
latches have been inferred. These switches can also change the
functionality of a design causing a mismatch between pre-synthesis and
post-synthesis simulation, which if not discovered during gate-level
simulations will cause an ASIC to be taped out with design problems.
This paper details the effects of the "full_case parallel_case"
directives and includes examples of flawed and inefficient logic that
is inferred using these switches. This was EXCELLENT, and when the
electronic version comes out, I will pass it on.
3) Understanding your cell library. This was boring, totally irrelevant
to our needs, and incomprehensible.
The next user session was "Design Reuse/IP Prototyping", which was again
split into three presentations.
1) VHDL Coding Styles for Synthesizable, Reusable Designs. Behavioral
(RTL). VHDL has features that can greatly enhance the process of
reusing a design. High-level languages provide ways to optimize and
modify reusable designs without compromising the integrity of the
underlying design. In this paper, we explore several methods of
coding designs that allow user-customizable features and optimal
synthesis (performance and gate count), using the native language
features of VHDL. We examine the use of the following features that
render reusability to the code and at the same time does not hamper
the synthesizability: - Generics - A Package of constants - Generate
statements - Tying of ports and leaving ports "open" - Unconstrained
arrays and aggregates - Configuration specifications - VHDL
attributes - Block statements. This paper also presents real-life
examples of such reusable constructs and the results of synthesis using
Synopsys. Designers can apply any or all of these ideas to make their
designs more feature-rich, efficient, and highly reusable to create
multi-million gate System-On-A-chip designs. This was an excellent
presentation, and maybe we should look into it.
2) Design Methodology for Developing IP in FPGA's for ASIC Production.
This was all about trying to keep the ASIC flow and the FPGA flow as
near to identical as possible. Interesting, but not applicable to us.
3) Designing for Flexibility. This was about busses, and the different
schemes available. It was badly presented, and I lost the thread. It
presented three busses - Non-Pipeline, Pipelined, and Out of Order, and
that was essentially it. If you are interested in busses, then this may
be interesting.
The last user session was "High-Level Verification", which was again split
into three presentations.
1) A Recipe for Multi-million Gate ASIC Verification. Was interesting,
and came away with the following conclusions a) Have a verification
plan, and make it at the beginning of the project b) Set up the
verification infrastructure early, and allow the RTL designers to
regress against it. c) Use Buss Functional Models, and simple
behavioral models that everyone has access to. d) Have a verification
team
2) Object Oriented Approach to Verification. The task of verifying the
correct behavior of an Application Specific Integrated Circuit (ASIC)
is challenging. A hardware verification team must interpret the
specification of one or more bus protocols and the ASIC, then verify
that the ASIC behaves as specified while adhering to the bus protocols.
Typically the verification process involves modeling the bus protocols
and ASIC in a hardware simulator using a hardware description language.
Hardware description languages are well suited to describe the behavior
of circuits, but fall short when used as a verification language.
Hardware description languages don't provide any high level programming
support such as strong type checking, user defined data types and
generic programming. These features are beginning to become a
necessity to create an effective verification test environment. This
paper will discuss how Verilog, C++ and Object Oriented methodologies
have been used to create verification environments at Sun. It will
also discuss Object Oriented methodologies that can be used to help
decrease development time and increase the quality of verification
environments. These methodologies aren't language dependent and will
work for Vera as well as they do for C++. Interesting, could be useful.
3) Application of MicroPlatform Engineering Techniques in the Development
of VGA Compatible Cores. By working on multiple abstraction levels
the hardware-software co-verification of the INT416-SM and INT416-EX
VGA compatible cores was accelerated. Device drivers for the VGA and
the VGA HDL model developed concurrently, communicating through the
Primitive Device Drivers/Hardware Abstraction Layer/Bus interface. Our
system initially modeled the RTL for the VGA core using VCS, using a
PLI/socket interface to the PDD. The CPU, bridge, and memory subsystems
were initially abstracted as software processes, and later added to the
RTL HDL simulation. Foundation Express/FPGA Express was used to
implement the INT416-SM configuration onto a Xilinx Virtex XCV300 FPGA.
The key point out of this talk was develop models concurrently. My
brain was fried trying to follow this guy, and decipher the project
specific information. I don't think totally useful.
And that was it.
- [ Original Author Unknown ]
( ESNUG 359 Item 4 ) --------------------------------------------- [9/13/00]
Subject: Tools/Ways To Draw On-Grid 45 Degree Lines In Cadence Layouts
> Does anyone have a fix/work around for drawing diagonal lines in a Cadence
> layout, say on a metal layer, at a 45 degree angle but has the corners of
> the bends on grid?
>
> Currently I can draw the 45 no problem, but have to draw a polygon around
> the corners to get it to DRC etc... changing the grid spacing is not an
> option as it violates the technology rules.
>
> - A. Jale
From: Jos Hesdal <jos@hl.siemens.de>
My opinion is that there is no solution. Even the boundaries of the 45 path
are not on grid. That has to be, simple mathematics. The only thing you
can do is: draw polygons.
- Jos Hesdal
Siemens AG
---- ---- ---- ---- ---- ---- ----
From: reb@cypress.com
Long ago we wrote our own tool (in Cadence Skill code) including that
capability. I'd expect some commercial tools may do it also (browse
Connections Partners on the Cadence site)? As a fun basic starting point,
develop a pcell to emulate the path (points, width, layer, grid, etc.) but
keep it on grid. (One of the 4.4.x releases has (will have?)
mouse-draggable "handles" on pcells? Anyone play with that yet?)
- Reb
---- ---- ---- ---- ---- ---- ----
From: "Chuck King" <charles.a.king@intel.com>
There is a "fix" that is commercially available. You can find this at
http://www.stxcadware.com/ (a connections partner). They have written, in
SKILL, a series of programs one of which is called "polypath". Using that
program, you enter a path and when you have completed your entry the path is
converted into a polygon automatically, design rule correct and with the 45
degree angles made properly. The width of the 45 degree segment will be
slightly wider depending upon working grid and of course the square root of
2 issue.
This is not an endorsement of Stx Cadware, I am simply, as a fellow user,
offering a suggestion.
- Chuck King
Intel
( ESNUG 359 Item 5 ) --------------------------------------------- [9/13/00]
From: Subha Pindiproli <Subha.Pindiproli@emulex.com>
Subject: Designer Seeks DC/PT Script To Detect Paths Across 2 Clock Domains
John,
I have a world with two clock domains:
SysCLK Domain PCI CLK Domain
------
| |
-->| ff |-------->|----------|
| ------ | |
| | comb. | Sync FF's
| ------ | logic | ------ ------
| | ff | | | | | | |
|-->| |-------->| |------->| |--->| |----> FSM
| ------ | | | | | |
| | | ------ ------
| ------ | | |__________|________ PCI_CLK
| | ff |-------->|__________|
|-->| |
| ------
|
SYSCLK
As you can see from the above diagram, the output of SYSCLK FFs go into some
combinational logic and feed into FFs clocked by PCI_CK. The outputs of
the PCI_CLK FFs go into a FSM.
Let's say a glitch were to occur at the posedge of SYSCLK:
1) This could trigger a false (high) start signal and the output of
combinational logic would register a high. Because PCI_CLK has no
way to verify that this is a glitch, not a valid signal, it would
start the PCI_CLK FSM.
2) The correct solution is to put another FF after the combinational logic
clocked to the SYSCK, thereby preventing this glitch.
Are there any DRC tools out there that might catch this type of problem? Do
your users have any DC scripts that could test for this type of problem?
- Subha K. Pindiproli
Emulex Network Systems Costa Mesa, CA
( ESNUG 359 Item 6 ) --------------------------------------------- [9/13/00]
From: "Neel Das" <neeldas98@yahoo.com>
Subject: How Would You Design An Over 64-bit Multiplier-Accumulator (MAC)?
Dear John,
I would love to hear from your readers how they'd design a large Multiplier-
Accumulator (MAC) for over 64-bit operands. I'm considering Module
Compiler. Our implementation technology is not decided yet, but I'm
guessing 0.18um or smaller. We're targeting a freq in excess of 133MHz.
In terms of speed/power, any pointers/numbers would be greatly appreciated,
as also techniques to verify this type of circuit. (Obviously, we're not
circuit designers, and would probably do a very poor job at a custom
multiplier.) Ideas? Pointers?
- Neel Das
( ESNUG 359 Item 7 ) --------------------------------------------- [9/13/00]
From: Morgan Monks <MMonks@Gain.com>
Subject: My Design's Very Small & I'm Looking For Cheap-But-Good ATPG
Hi John,
Long time no email. I am now at a small company having left the "Bat Wing"
palace and am in need of a "cheap but good" ATPG tool.
Do any of your many well educated and knowledgeable readers have some
cheaper ATPG tools to recommend? I won't be generating scan for a million
gate ASIC so a small tool would work nicely. We can't afford the Mentor,
Cadence, or Synopsys products, and our design is small. Right now I'm
working on a very small, specialized design that's only 7 kgates. I don't
need to buy a $300K suite of tools for this. Ideas?
- Morgan Monks
Gain Technology Phoenix, AZ
( ESNUG 359 Item 8 ) --------------------------------------------- [9/13/00]
From: "Robert Wiegand" <rwiegand@nxtwavecomm.com>
Subject: Workaround For A Little Control-C "dc_shell | tee logfile" Gotcha
Hi John,
I got hit by a little gotcha recently that I thought I should share.
I've got into the habbit of using the "dc_shell | tee logfile" syntax for
interactive debugging so I can have a logfile for the session. One nice
thing about interactive sessions, is that a control-C will allow you to
checkpoint, or stop something that is compiling into oblivion and see what's
wrong. This may be very obvious to some, but I found out the hard way that
when using the " | tee" syntax, the control-C is passed to the "tee" instead
of the dc_shell session. This basically breaks the pipe and stops the job,
with no way that I could find to recover. Any UNIX gurus out there know
how to recover if this happens? To prevent this from happening, make sure
to use the -i switch on tee, which tells it to ignore interrupts as follows:
"dc_shell | tee -i logfile"
This allows the use of control-C for dc_shell.
- Bob Wiegand
NxtWave Communications Langhorne, PA
( ESNUG 359 Item 9 ) --------------------------------------------- [9/13/00]
From: Shuhui Lin <Shuhui.Lin@usa.alcatel.com>
Subject: Exactly How Did You Use ClearCase For Your Design Data Management?
Hi John,
I was searching through ESNUG archives and found several people recommending
the ClearCase configuration management tool for hardware design [ESNUG 345
& ESNUG 281]. I would appreciate it if anyone who is using ClearCase could
elaborate on the usage model for ASIC design. Specifically, is the entire
ASIC database (including Synopsys .db files and other miscellaneous files
and directories created by various ASIC tools) under ClearCase management or
just the HDL source? Managing the entire database seems to be overkill, but
if a file is not managed it is not easily visible to other users working in
other "views".
- Shuhui Lin
Alcatel USA Raleigh, NC
( ESNUG 359 Item 10 ) -------------------------------------------- [9/13/00]
Subject: ( ESNUG 358 #7 ) DW PCI Core Doesn't Work For Both FPGAs & ASICs!
> We're looking for a soft PCI master-target core. The idea is to implement
> it in Xilinx Virtex, test it, then migrate it to ASIC. The frequency we
> need is 33 MHz and the bus width 32 bits. We tried with Synopsys DWPCI.
> Unfortunately, we were unable to implement it in the Virtex.
>
> At first I used the constraints files and synthesis scripts provided by
> Synopsys, and later I changed the scripts to try different options and
> strategies. After a lot of tries, I got, in the best case, a pad-to-setup
> slack of -20 ns (after place and route). As for the synthesis software, I
> used both FPGA Compiler (Design Compiler for FPGAs) and FPGA Compiler II
> (the results were very alike in both cases). It seems there is a lot of
> combinational logic at the inputs, and, as you might imagine, I am
> somewhat disappointed.
>
> Does anybody know a good PCI soft core that can be implemented in FPGA and
> later migrated to ASIC?
>
> - Angel Ramiro
> Systems on Silicon, Inc.
From: "jok" <jok@erols.com>
With regard to PCI cores, John, it seems that the devil lies in the fact
that the clock latency can kill you when you are trying to meet the tight
clock to q times. This same clock is used for pulling data into the bus
interface.
It would appear that most core vendors assume a low latency clock, or maybe
this is not a consideration at all. The other constraint surfaces when
considering I/O timing, which can be application specific. But, the bottom
line is that core vendors may not add this I/O variable into their synthesis
scripts.
From what I have read, it would appear that many FPGA vendors are hand
tweaking the cores on the physical end to fix some of the variation in
I/O timing and clock distribution. The other issue which I don't have a
handle on is on what technique is used for the FIFO, if needed. If registers
are used, this could cause more load on the clock and variation in the
route. If a FIFO is used, the loading might be fixed, but you are still
presented with FPGA vs. ASIC timing.
The optimum solution might be to have a core with paramters on how much
margin one has in these various areas. Robbing Peter to pay Paul, if you
will. But at least you would know the budget.
Just some thoughts off the top off my head.
- Jim Jok
============================================================================
Trying to figure out a Synopsys bug? Want to hear how 11,000+ other users
dealt with it? Then join the E-Mail Synopsys Users Group (ESNUG)!
!!! "It's not a BUG, jcooley@world.std.com
/o o\ / it's a FEATURE!" (508) 429-4357
( > )
\ - / - John Cooley, EDA & ASIC Design Consultant in Synopsys,
_] [_ Verilog, VHDL and numerous Design Methodologies.
Holliston Poor Farm, P.O. Box 6222, Holliston, MA 01746-6222
Legal Disclaimer: "As always, anything said here is only opinion."
The complete, searchable ESNUG Archive Site is at http://www.DeepChip.com
|
|
