Editor's Note: Given the recent developements in the Avanti/Cadence
lawsuit(s) this week, how many of you expect to be using Avanti tools
a year from now? In your opinion, are we going to end up back in the
days where Cadence owns the monopoly in backend tools (yet again)?
- John Cooley
the ESNUG guy
( ESNUG 371 Subjects ) ------------------------------------------ [05/23/01]
Item 1 : ( ESNUG 370 #6 ) PhysOpt's Placement Of Clock Gating Cells
Item 2 : PhysOpt Clustering Creates Congestion Making Unroutable Designs
Item 3 : GlobeTrotter Licensing And The Screwy New SolvNet Login Changes
Item 4 : PhysOpt Won't Fix Hold Time Violations On Bi-directional Ports ?!
Item 5 : DFT Compiler Chokes On Synchronizers With Inputs Tied To Zero
Item 6 : Can I Get TimeMill To Report A Range Of Transition Times? How?
Item 7 : Formality Can't Handle 2D Arrays -- How About Other Formal Tools?
Item 8 : Maybe This Is How You Compare Two Strings In PrimeTime Tcl? Yes?
Item 9 : Physical Power Planing In Cadence Silicon Ensemble Sucks Big Time!
Item 10 : ( ESNUG 368 #8 ) Veritools Undertow Views The Bad Busses In VSS
Item 11 : ( SNUG 01 #15 ) STMicroelectronics Defends Synopsys Formality
Item 12 : Is Avanti Jupiter Plus Design Compiler Better Than PhysOpt Alone?
Item 13 : ( ESNUG 368 #5 ) Bitten By The New high_fanout_net_threshold
Item 14 : Are You Just As Disappointed With Synopsys Presto As We Are?
Item 15 : ( ESNUG 368 #1 ) PhysOpt/Avanti 2000.11 Utlities Are Worthless
Item 16 : The Prepended X Problem In EPIC Amps & Synopsys EPIC Tool Support
Item 17 : ( ESNUG 370 #5 ) Seven Workarounds On Nine DW_16550 UART Bugs
The complete, searchable ESNUG Archive Site is at http://www.DeepChip.com
( ESNUG 371 Item 1 ) -------------------------------------------- [05/23/01]
Subject: ( ESNUG 370 #6 ) PhysOpt's Placement Of Clock Gating Cells
> I'm a PhysOpt AC in Dallas. I can't answer Neel's question about Power
> Compiler, but I do know about using PhysOpt with Cadence and Avanti CTS
> tools. ... My specific flow steps may need to be tuned for each customer's
> environment, but it's a good starting point...
>
> - [ A Dallas PhysOpt AE ]
From: Neel Das <neel.das@corrent.com>
Hello John,
I have some preliminary data to report on PhysOpt and clock gating cells.
We're not using integrated clock gating cells, which makes this case *very*
interesting for us.
Around 71% of the clock gates have less than 10 um between the main gate
and the enable latch. Here's how PhysOpt placed them:
< 10 um - #################################################### 105
10 to 20 um - ################ 32
20 to 30 um - #### 8
30 to 40 um - # 2
> 40 um - 0
Total clockgates 147
I can provide more info later if you'd be interested... I'm curious to see
how our router handles these.
- Neel Das
Corrent Corporation
( ESNUG 371 Item 2 ) -------------------------------------------- [05/23/01]
From: [ Shrek's Donkey ]
Subject: PhysOpt Clustering Creates Congestion Making Unroutable Designs
Hi John, please keep me anonymous.
Though our design's overall row utilization is low, about 55%, PhysOpt
(since it doesn't have real global routing) keeps clustering cells to
create very high density areas. This happens with -congestion option,
even when we leave empty space around the cluster. This congestion makes
our design unroutable.
- [ Shrek's Donkey ]
( ESNUG 371 Item 3 ) -------------------------------------------- [05/23/01]
From: Scott Nogueira <sdn@world.std.com>
Subject: GlobeTrotter Licensing And The Screwy New SolvNet Login Changes
Hi John,
For one of the customers I support, there was a recent need to download
updated keys from SolveNet. Like other users, I received an e-mail from
Synopsys informing me that I'd need to login and reset my SolveNet username
and passwd. I encountered 2 problems (so far):
1. Despite having my original username (full e-mail address) and
passwd for the legacy SolveNet access, it refused to accept them
at the legacy page. I was forced to request a new legacy passwd.
No big deal I guess, as I received the temp passwd in a few minutes
via e-mail. I logged in, reset my info, picked new username/passwd
etc. One thing I noticed was that both sites I support were not
listed under the site ids.
2. I then proceeded to key retreival and was told that I was not
authorized for that function. News to me...
So now I wait for support to get back to me, meanwhile users are busting
down the door for the licenses.
It pays to watch in advance for expiring licenses, I guess. Too bad I
can't make GlobeTrotter's software to automatically watch for that. It
is way too much $$ and it's disfunctional anyway, but I digress.
- Scott Nogueira
EDA Plus, Inc.
( ESNUG 371 Item 4 ) -------------------------------------------- [05/23/01]
From: Dave Dixon <ddixon@micron.com>
Subject: PhysOpt Won't Fix Hold Time Violations On Bi-directional Ports ?!
Hi, John,
We currently have an issue with Synopsys Physical Compiler not fixing hold
time violations on bidirectional ports. It seems clear that PhysOpt
understands what the violations are; we don't understand why they are not
being fixed.
I was wondering if you or your readers have experience of the same, and
perhaps offer solution, or suggest workaround.
- Dave Dixon
Micron
( ESNUG 371 Item 5 ) -------------------------------------------- [05/23/01]
From: Rajkumar Kadam <rkadam@asic.qntm.com>
Subject: DFT Compiler Chokes On Synchronizers With Inputs Tied To Zero
Hi, John,
I have a design in which there are some instances of synchronizers whose
inputs will be tied to zero depending on the requirement. The problem is
that Design Compiler does not remove such instances. It keeps the instance
with the input tied and the output not defined at all in the gate level
netlist. All this is fine for gate level simulation, etc., but the problem
occurs when I try to insert scan in the design. DFT Compiler sees a
sequential cell with inputs defined and no outputs and issues a Warning as
this cell cannot be included in the scan chain.
Is there anyway to optimize away the unsed instances, using some Synopsys
variable? I know only of two solutions:
1. ungroup -- but I do not want to run ungroup on the design.
2. grep manually for such unused cells and remove it. Ugly.
Any other solution is welcome.
- Rajkumar Kadam
Quantum Corp.
( ESNUG 371 Item 6 ) -------------------------------------------- [05/23/01]
From: Raj Sayana <raj@mosys.com>
Subject: Can I Get TimeMill To Report A Range Of Transition Times? How?
Hi John,
I have checked Solv-it but found no answers there.
I want to know if TimeMill can report nets with transition time greater
than a specific threshold value. If so, which version of the TimeMill
release can do this?
- Raj Sayana
MoSys, Inc. Sunnyvale, CA
( ESNUG 371 Item 7 ) -------------------------------------------- [05/23/01]
From: Menno Spijker <menno_spijker@Mitel.COM>
Subject: Formality Can't Handle 2D Arrays -- How About Other Formal Tools?
Hi John,
I'm using in my VHDL code 2 dimensional arrays. For example:
type t_array is array(natural range <>) of std_logic_vector(7 downto 0);
signal s_array : t_array(15 downto 0);
Our formal verification tool, Formality, has a hard time with signals like
this. Our support guy from Synopsys rewrote the 2D arrays to a 1D array:
std_logic_vector(127 downto 0)
Now Formality can handle the design. He recommended not to use 2D arrays
in future designs, either in Verilog or VHDL.
I find that some Synopsys tools are not that great on VHDL. DC and
Formality still don't support all of VHDL-93. Further, some VHDL-93
constructs that are supported by DC are not supported by Formality. So
that makes me wonder what peoples experience is with other formal
verification tools with respect to 2D array's.
- Menno Spijker
Mitel Semiconductor Ottawa, Canada
( ESNUG 371 Item 8 ) -------------------------------------------- [05/23/01]
Subject: Maybe This Is How You Compare Two Strings In PrimeTime Tcl? Yes?
> I'd like to compare two strings in PrimeTime as:
>
> pt_shell> query $tmp_pins
> {"DMAC0_inst/IRQ_request/SCAND", "DMAC0_inst/IRQ_request/U0/SCAND"}
> pt_shell> query $tmp_net
> {"DMAC0_inst/IRQ_request/SCAND"}
> pt_shell> foreach_in_collection comp $tmp_pins {
> ? set res [string compare $comp $tmp_net]
> ? echo $res
> ? }
> Information: Defining new variable 'comp'. (CMD-041)
> 1
> 1
>
> But the result shows two mismatches. I would appreciate advice on how to
> compare two strings in PrimeTime.
>
> - Klaus Vongehr
> Philips Semiconductors Munich, Germany
From: jmcalvez@club-internet.fr (Jean-Marc Calvez)
I suppose that, in the above, tmp_pins and tmp_nets are two collections,
returned by get_pins and get_nets? You cannot compare directly two
collection elements, so you should try to compare the names (query_objects
will display the names, which may be identical, but the objects themselves
cannot be compared).
Two possible solutions: either use get_object_name (I think; I hope I
haven't forgotten an 's' somewhere), as in [get_object_name $tmp_net], or
you can use the name attribute, with [get_attribute $tmp_net name]. Note
that in some cases, name is not the correct attribute name; you may want
to use full_name instead. There are also restrictions when using
get_object_name. I think you cannot use it with collections of more
than one element. You will need to experiment a bit, I'm afraid.
So your script would become something like:
set net_name [get_object_name $tmp_net]
foreach_in_collection comp $tmp_pins {
set pin_name [get_object_name $comp]
set res [string compare $pin_name $net_name]
echo $res
}
Regards,
- Jean-Marc Calvez Grenoble, France
( ESNUG 371 Item 9 ) -------------------------------------------- [05/23/01]
From: Rick Burnett <destinytech@spacey.net>
Subject: Physical Power Planing In Cadence Silicon Ensemble Sucks Big Time!
Hi, John,
I am a chip designer and I do not understand why physical power planning has
to be so difficult. I have yet to find a tool that works. The power
planner in Silicon Ensemble is total crap. The same is true to any of
Cadence's current tools. Some MINIMUM features would be:
1. Any number layer support.
2. Single metal rings to avoid via shutouts (usually rings around
blocks do this).
3. Power meshing.
4. CORRECT via creation and layer connections that are DRC clean.
Thats all I want! Right now, I have tons of perl scripts that I use to try
to automate creating a power structure and it seems like a tool like that
could save at least two weeks of work.
- Rick Burnett
( ESNUG 371 Item 10 ) ------------------------------------------- [05/23/01]
Subject: ( ESNUG 368 #8 ) Veritools Undertow Views The Bad Busses In VSS
> I am trying to dump VCD files through the VSS VHDL simulator. By using
> the command vcdaddobjects 0 TEST_BENCH/*'sig, and then "vcddumpall". I
> am able to dump all the signals except individual signals for buses which
> are dumped as HEX values. The VCD viewer howvever does not show the
> correct intermediate value for buses.
>
> - Farhan Shahid
> Virginia Tech.
From: Robert Schopmeyer <schop@veritools.com>
Hi, John,
Have Farhan get a copy of Undertow or Undertow Suite from our web site at
http://www.veritools.com for this problem. We provide it at no cost to
universities. It is used today at MIT and University of Texas, plus
several hundred other universities world wide. It will both show the
correct values, and also they can make any set of signals into a bus in
seconds. Buses can be shown in either HEX or binary format. The signals
in a bus can also be seperated quickly to see exactly what is the value
of each signal.
- Robert Schopmeyer
Veritools, Inc.
( ESNUG 371 Item 11 ) ------------------------------------------- [05/23/01]
Subject: ( SNUG 01 #15 ) STMicroelectronics Defends Synopsys Formality
> EXIT WOUNDS: Out of the 27 e-mails I received on Formality, Verplex or
> Chrysalis: 22 were pro-Verplex; 5 were pro-Formality; and none were
> pro-Chrysalis.
>
> - from the SNUG'01 Trip Report
From: Umberto Rossi <Umberto.ROSSI@st.com>
Hi, John,
I'm the Formal Verification Manager in STMicroelectronics at Milan, Italy.
Formality is by far our most popular tool for the purpose of the Equivalence
Checking in STMicroelectronics worldwide. Formality is our official tool in
the RTL-to-Layout flow, performing RTL-to-Gate and Gate-to-Gate comparisons.
It is packaged in our standard design flow in order to perform Gate2Gate
comparisons with minimal intervention from the designer's side.
Formality has validated hundreds of designs for us in every market covered
by ST -- consumer, telecom, automotive -- in every product line -- ASIC,
microcontroller, set-top-box, graphics, combos and SystemOnChip -- with any
available technology -- .35u, .25u, .18u, .13u -- of sizes up to 2 Million
gates.
Formality has been proven effective for us with a well known synthesis flow
as well as other custom flows -- especially in data-path design.
In Formality, we find many features that are necessary for the verification
flow starting from the library level on up to designs needing sophisticated
setups aimed at the time & power convergence domain (e.g. Inverted Compare
Points, Asynchronous Bypass, Gated Clocks, Retiming, Constrained
Verification.)
Concerning run time performance we have seen a significant improvement in
the recent year and some designs that used to be inconclusive now succeed.
I'm talking about Formality 1999.10-FM1.0 vs. Formality 2000.05-FM2.0.
I can give you some examples: one design was a RTL-to-Gate ~40K gates. It
used to be inconclusive and now passes in ~2.5 hours. Another Gate2Gate
design that was inconclusive now passes in 2 days. In this case I have
just the container sizes around 20Mb (~500K gates). Often divisions send
us containers in order not to make the code available. In effect this is
a strange case for Gate2Gate but I think that designers took the first and
the last version of gate netlists through a very complex flow.
In these experiments we run Formality on the same machine: Sun Solaris
248MHz with 3.5 Gb memory.
Concerning custom design, we have asked Synopsys to address also the
verification of simple memories. Duplication will play a major role in
0.18 um and below and we are asking specific features to have it better
supported.
Concerning comparison with competitors our analysis is a bit out of date
although we think that a competitive race is the best challenge to get
the best performance out of the market. Other formal products definitely
have less features and they seem limited to streamlined design flows.
- Umberto Rossi
STMicroelectronics Agrate Brianza, Italy
( ESNUG 371 Item 12 ) ------------------------------------------- [05/23/01]
From: [ Timmy, from South Park ]
Subject: Is Avanti Jupiter Plus Design Compiler Better Than PhysOpt Alone?
Hi John, anonymous (please)
I am a Design Compiler user and am looking at Synopsys PhysOpt for our new
300 Mhz+ designs. Avanti is pushing their Jupiter. They claiming that
using Jupiter and Design Compiler together is far better than using PhysOpt.
I wonder if anyone has experience with this flow. Thank you.
- [ Timmy, from South Park ]
( ESNUG 371 Item 13 ) ------------------------------------------- [05/23/01]
Subject: ( ESNUG 368 #5 ) Bitten By The New high_fanout_net_threshold
> We encountered a poorly documented new variable in DC 2000.11 which is
> poised to cause you some pain. It's called high_fanout_net_threshold and
> is a new, potentially useful feature whereby nets over a certain fanout
> limit are considered to be clock trees which will be taken care of via
> clock tree synthesis. This provides a second strategy for the classic
> set_drive 0 approach to clock trees during synthesis. No attempt will be
> made to buffer these nets. It looks like this was thrown in last minute
> without the usual Synopsys QA process. Here are the problems:
>
> 1) No attempt to buffer the nets will be made, but timing arc involving
> these nets still are in the timing driven synthesis path groups, so
> DC will try for days to optimize nets which can't be buffered.
>
> 2) Variable does not exist in the distributed .synopsys_dc.setup file,
> therefore it is un-initialized.
>
> 3) Printvar thinks this variable does not exist.
>
> 4) Setting this variable to 0 causes the old operation, but it is not
> initialized and you can't check what its value is due to #3.
>
> 5) pipeline_design no longer tries to buffer stall signals even when this
> variable is set to zero. This may be a tangential issue, but is
> probably related to the implementation of this new feature.
>
> We now set high_fanout_net_threshold to 0. Personally, I think this
> variable was the wrong idea altogether.
>
> - Thomas Ayers
> Believe, Inc.
From: Scott Evans <scott@sonicsinc.com>
John,
I don't have much experience with this yet, but what I saw is that it is
actually initialized by dc_shell to be 1000 if you don't specify otherwise.
When I dug into which nets it was referring to, it turned out to be my
power and ground nets. I asked for an enhancement request to have the
program ignore such nets.
- Scott Evans
Sonics, Inc. Mountain View, CA
---- ---- ---- ---- ---- ---- ----
From: Tom Ayers <tomayers@believe.com>
Yes, Scott, it does have a non-zero value, but I do not think I found it
initialized in the global .synopsys_dc.setup file which is where it should
be found. It should also be defaulted to zero to exhibit the "old"
behaviour.
- Thomas Ayers
Believe, Inc.
---- ---- ---- ---- ---- ---- ----
From: Scott Evans <scott@sonicsinc.com>
I don't disagree with you, Tom. I believe there are a number of variables
which don't get initialized in the global .setup file but instead have
program defaults which are used instead. Definitely inconsistent.
- Scott Evans
Sonics, Inc. Mountain View, CA
---- ---- ---- ---- ---- ---- ----
From: Tom Ayers <tomayers@believe.com>
John,
In response to my post, Synopsys has been very supportive with this problem
and has confirmed the pipeline_design issue. STAR 119193 has been generated
to address that problem.
- Thomas Ayers
Believe, Inc.
( ESNUG 371 Item 14 ) ------------------------------------------- [05/23/01]
From: Richard Conlin <rich.conlin@paradigm-works.com>
Subject: Are You Just As Disappointed With Synopsys Presto As We Are?
Hi John,
We're investigating using the new Synopsys Presto Verilog 2000 features
like arrayed instantiation and multiply-dimensioned arrays. In our
preliminary evaluations of Presto's support for these features,
I have been sorely disappointed (using 2000.11-SP1). I have been even
more disappointed by the Synopsys On Line Documentation provided
describing Presto's support of these particular features.
We have also encountered some serious backwards incompatibility with HDL
Compiler issues (i.e., Verilog that works fine with HDL Compiler that
breaks Presto), and Synopsys has publicly stated its intent to make Presto
the default Verilog reader starting with the 2001.08 release.
I would be very interested in hearing about others' experiences with
Verilog 2000 and Presto to date.
- Rich Conlin
Paradigm Works Andover, MA
( ESNUG 371 Item 15 ) ------------------------------------------- [05/23/01]
Subject: ( ESNUG 368 #1 ) PhysOpt/Avanti 2000.11 Utlities Are Worthless
> Here are some Scheme scripts that enable data to move between Avanti and
> PhysOpt. I think they will work for Chip Architect and Flexroute as well.
> These scripts seem to work for my company, but I would guess that other
> folks may have to modify them to make them work at their site.
>
> - [ ASIC Designer #8 ]
From: [ A Little Bird ]
Hi John,
Please keep me anonymous.
I used to work in Synopsys. I have personally worked with the engineer who
wrote these Avanti Scheme scripts. He used to be a very good AC in Avanti
and he came to Synopsys with experience in Apollo and Jupiter tools. He is
the one who wrote the Scheme scripts for the interface between PhysOpt and
Avanti tools.
I've used this script for library preparation, and file transfer between the
two tools when I still worked in Synopsys. Lately, Synopsys had three new
utilities: "milkyway2plib", "adb2pdef" and "pdef2adb" in version 2000.11
release to do the Avanti/PhysOpt interface. I had a lot of problems using
them in our flow. First, their debugging capability is bad. Secondly, they
are VERY sensitive to the ownership of the files. For example, if the
library was installed by the cadmgr, as a user I can't run "milkyway2plib"
at all. I have to log in as cadmgr to execute the it. And, so far, I
haven't have much success with "adb2pdef" and "pdef2adb".
I am forced to used the old script now for my project. I wonder how many
people have success using these 3 new Avanti/PhysOpt utilities in 2000.11?
- [ A Little Bird ]
( ESNUG 371 Item 16 ) ------------------------------------------- [05/23/01]
From: John V. Harding <j.harding@motorola.com>
Subject: The Prepended X Problem In EPIC Amps & Synopsys EPIC Tool Support
John,
What follows are excerpts from an e-mail dialog between Synopsys support and
myself about an issue we saw with Amps version 5.5.
[Me to Synopsys]
Amps produces incorrect instance names in SPICE.
I ran Amps with the -S switch to produce a SPICE netlist from a Verilog
netlist and an STW file.
If there is an instance name in the Verilog netlist that begins with the
letter "x" the SPICE generated using AMPS is incorrect. Instance names
in SPICE have an "X" prepended on the Verilog instance name, however,
when that instance name begins with "x" AMPS does NOT prepend the "X"
like it should.
[Synopsys to me. Note the reference to marketing]
I double check EPIC netlist compiler behavior and found that for Verilog
netlist, our netlist compiler will drop leading X in the instance call.
If there is no leading X for instance call, then netlist compiler will
add an extra X to fit SPICE syntax.
For example, I write a simple test module like:
module top;
and1 XI1(1, 2, 3, 4);
and2 XI2(5, 6, 7, 8);
And netlist compiler will translate to
.subckt top
XI1 1 2 3 4 and1
XI2 5 6 7 8 and2
.ends top
And I did another test without leading X for instance call
module top;
and1 I1(1, 2, 3, 4);
and2 I2(5, 6, 7, 8);
endmodule
And netlist compiler will translate to
.subckt top
XI1 1 2 3 4 and1
XI2 5 6 7 8 and2
.ends top
Note that with/without leading X for instance call, EPIC netlist compiler
will give identical SPICE netlist. This is our internal algorithm to
compile Verilog netlist and if you want to see double Xs in the output,
then we need to file an enhacement request and go through marketing
review. But I do have question on with/without leading X, does the AMPS
output create any trouble in your follow up simulation flow?
[me to Synopsys]
What result will I get if my Verilog netlist was as follows:
module top;
and1 I1(1, 2, 3, 4);
and2 XI1(5, 6, 7, 8);
endmodule
[Synopsys to me.]
I tested in the netlist compiler and turns out:
.subckt top
XI1 1 2 3 4 and1
XI1 5 6 7 8 and2
.ends top
This will be a issue of duplicate instance name. I have initial a discuss
with marketing person and she said it will be difficult to prioritize this
issue as high as you expect. So we are wondering can this issue be solved
at Verilog coding phase? But anyway I will file an enhancement request on
this one.
[Synopsys to me, again]
I have filed a bug under bugid 117180. I will update you ASAP once I hear
back from marketing/R&D team. But I would expect a longer turn around
time.
End of saga. (Well, not really...)
- John Harding
Motorola StarCore Atlanta, GA
( ESNUG 371 Item 17 ) ------------------------------------------- [05/23/01]
Subject: ( ESNUG 370 #5 ) Seven Workarounds On Nine DW_16550 UART Bugs
> Recently I encountered the Ketchum tool you mentioned in your SNUG'01
> Trip Report. We were using DW_16550 UART in our design, and during usual
> simulation process, I uncovered few functional bugs. We were close to
> the tape out, so the situation was very tense, but, luckily, Synopsys's
> designers came up with a quick fix. It would be better not to have bugs
> in Synopsys DW IP at all, but "nobody's perfect".
>
> - Vladimir Sindalovsky
> Agere Systems
From: [A Synopsys DesignWare CAE Manager]
Hi, John,
If you are using the DW_16550, please read the details below, and upgrade
to the new release as soon as it's available. The target date for the
release is June 15, 2001. DesignWare customers will be able to download
this via: www.synopsys.com/designware/dwest. The "What's New" link will
indicate the release contains fixes for the DW_16550 part.
The only bug that we do NOT plan to fix in the next release is the last one,
"Under certain conditions, the DW_16550 asserts the txrdy_n and rxrdy_n
signals one clock cycle late [STAR 121181]."
1.) The DW_16550 loses Line Status Error Conditions when the Line Status
Register is read on the same clock cycle that data is being pushed
into the receive FIFO [STAR 121180]
If the following conditions are all true:
- DW_16550 in Synchronous Mode (sync_mode parameter = 1)
- FIFOs are enabled
- Receiver FIFO is empty
- Line Status Register is read on the same clock cycle that a
character is pushed into the Receiver FIFO
OR, if all of the following are true:
- DW_16550 in Asynchronous Mode (sync_mode parameter = 0)
- FIFOs are enabled
- Receiver FIFO is empty
- Line Status Register is read one clock cycle after a character is
pushed into the Receiver FIFO
This problem will occur:
In FIFO mode, the DW_16550 should push the Parity Errors, Framing
Errors and Break Interrupts, into the Receiver FIFO so that they appear
at the same time as the character that they are associated with. In
the conditions described above, the DW_16550 will lose the error flags
and they will not appear when the corresponding character is at the top
of the Receiver FIFO. The interrupts associated with these error
conditions will also not be raised. This problem will not occur if the
Line Status Register is always read in response to an interrupt or
activation of the txrdy_n or rxrdy_n signals. This problem may occur
if the CPU polls the DW_16550 instead of using interrupts.
Workaround:
Use interrupts or the txrdy_n and rxrdy_n signals to control reads and
writes to the DW_16550. Do not use the DW_16550 in polling mode.
2.) The DW_16550 doesn't assert the txrdy_n signal correctly in DMA Mode 0
[STAR 121177]
If the following conditions are all true:
- FIFOs are enabled
- DMA Mode 0 enabled
This problem will occur:
If FIFOs are enabled and DMA Mode 0 is selected (FIFO Control Register
Bit 3 = 0), the txrdy_n signal should go inactive as soon as a
character is written to the transmit FIFO. In the DW_16550 the txrdy_n
signal doesn't go inactive until several characters have been received.
Workaround:
None.
3.) The DW_16550 does not hold the Modem Status Bits and Serial Data Out at
logical '1' when in Loopback Mode [STAR 121161]
If the following condition is true:
- DW_16550 used in Loopback Mode
These problems will occur:
1. When it's in loopback mode the DW_16550 should hold the Modem
Status Bits (out1_n, out2_n, dtr_n, rts_n) at static '1', instead
it continues to assert the normal values.
2. When it's in loopback mode the DW_16550 should hold the Serial
Data Output (sout) signal at static '1', instead it continues to
assert the normal values.
Workaround:
None.
4.) The DW_16550 does not reset the FIFOs if they are disabled and
re-enabled during operation [STAR 121171]
If the following conditions are all true:
- The transmit or receive FIFO contains data
- FIFOs are disabled using FIFO Control Register bit 0
- FIFOs are re-enabled without clearing them using FIFO Control
Register bits 1&2
This problem may occur:
When you disable the FIFOs using FIFO Control Register bit 0, the FIFOs
are supposed to be reset automatically. The DW_16550 does not reset
the FIFOs. So, when you re-enable the FIFOs (using the same Control
Register bit 0), they will still contain the old data.
Workaround:
If you disable the FIFOs, then re-enable them, use bits 1 and 2 of the
FIFO Control Register to reset the Transmit and Receive FIFOs.
5.) When data is read from the DW_16550 very late, the DW_16550 status
flags may be incorrect [STAR 121173]
If the following condition is true:
- The CPU reads the RBR on the last possible clock cycle
These problems will occur:
In correct operation, once the DW_16550 has signaled that a character
has been received, the CPU has until the next character has been
received to read the data and clear the RBR. In FIFO mode, once the
FIFO is full, the CPU has until the next character has been received
to read one character from the receive FIFO. If the CPU fails to read
the data in time, an Overrun Error condition results.
There is a bug in the DW_16550 that causes the component to incorrectly
flag an Overrun Error if the CPU reads data and clears the RBR on the
last clock cycle before the overrun error would have occurred. Under
these conditions the DW_16550 incorrectly flags an overrun error, when
there is none. Specifically:
1. If new data is being pushed into the RBR on the same clock cycle
that the CPU is reading that data, the Data Ready (DR) bit of the
Line Status Register will not go active, even though new data is
there. This also affects the main Data Available Interrupt.
2. If new data is being pushed into the RBR on the same clock cycle
that the CPU is reading that data, the DW_16550 incorrectly
asserts an Overrun Error condition, even though none occurred.
Workaround:
There is no workaround for this problem. A system that is slow enough
in responding to Receiver Line Status Interrupts to see this problem
is probably also suffering from numerous legitimate overrun errors and
needs to have its response time improved.
6.) rxrdy_n continues to signal character timeouts, even when the receive
FIFO is empty [STAR 121173]
If the following conditions are all true:
- FIFO mode enabled
- DMA Mode 1 enabled
- You are using rxrdy_n to control when you read the receiver FIFO
This problem may occur:
When FIFOs are enabled and you are using DMA Mode 1, the DW_16550
should assert the rxrdy_n signal when the receiver FIFO level matches
the programmed threshold. In addition, the DW_16550 should assert
rxrdy_n when no data is read or written to the Receiver FIFO for a
period of four character times AND there is at least one character in
the receive FIFO. In this second case, the DW_16550 incorrectly
asserts rxrdy_n even when there is NO data in the receive FIFO.
The DW_16550 asserts the rxrdy_n signal on character timeout to trigger
the CPU or DMA controller to flush any data remaining in the receive
FIFO once no more characters are being received on the serial input.
If the rxrdy_n signal of the DW_16550 is used in this way, and the CPU
or DMA controller reads the receive FIFO when the rxrdy_n signal goes
active on character timeout without checking the Line Status Register,
the data read will not be a valid character.
Workaround:
1. If DMA Mode 0 is used, the rxrdy_n behavior is correct.
2. When the rxrdy_n signal is active, read the Line Status
Register to determine if a valid character is available
in the receive FIFO.
3. Use the Received Data Available interrupt instead of the
rxrdy_n signal to control reading the Receiver Buffer Register.
7.) A write to the transmit FIFO followed immediately by a write to
configuration register fails [STAR 121178]
If the following conditions are all true:
- DW_16550 in Synchronous Mode (sync_mode parameter = 1)
- FIFOs are enabled
- Back-to-back write to the Transmitter FIFO followed by a write
to any of the configuration registers
This problem will occur:
If a character is written to the transmit FIFO, and on the next clock
cycle data is written to any of the DW_16550 configuration registers,
the data intended for the configuration register will be written to
the Transmitter FIFO instead.
Workaround:
This is not a normal mode of operation. It would be very unusual to
write a character to be transmitted and then, on the next clock cycle
before the character has been sent, to change the configuration of the
DW_16550. To workaround this problem, allow at least one clock cycle
between writing a character to the Transmit Holding Register and
writing data to a configuration register.
8.) If a write to the Transmit Holding Register is followed immediately
by a read of the Line Status Register, the DW_16550 will generate
incorrect status [STAR 121179]
If the following conditions are all true:
- A character is written to the Transmit Holding Register and, on
the very next clock cycle, the Line Status Register is read
- The system is using the Transmitter Empty status bit of the Line
Status Register
This problem will occur:
As soon as a character is written to the Transmit Holding Register, the
DW_16550 should set the Transmitter Empty status bit of the Line Status
Register false. If a read of the Line Status Register occurs on the
clock cycle following a write to the Transmit Holding Register, the
Transmitter Empty status bit will incorrectly indicate that the
transmitter is completely empty.
Workaround:
If you use the Transmitter Empty status bit, work around this problem
by always allowing at least one clock cycle between a write to the
Transmit Holding Register and a read of the Line Status Register.
9.) Under certain conditions, the DW_16550 asserts the txrdy_n and rxrdy_n
signals one clock cycle late [STAR 121181]
NOTE: This STAR will NOT be fixed in the upcoming release targeted for
6/15/01.
If the following conditions are all true:
- DW_16550 in Synchronous Mode (sync_mode parameter = 1)
- FIFOs are enabled
- DMA Mode 1
- txrdy_n signal is checked on the same clock cycle as a write to the
Transmitter FIFO or rxrdy_n signal is checked on the same clock
cycle as a read from the Receiver FIFO
OR, if all of the following are true:
- DW_16550 in Asynchronous Mode (sync_mode parameter = 0)
- FIFOs are enabled
- DMA Mode 1
- txrdy_n signal is checked on the first cycle after a write to the
Transmitter FIFO or rxrdy_n signal is checked on the first cycle
after a read from the Receiver FIFO
This problem will occur:
If back to back writes to the Transmitter FIFO are being gated by the
txrdy_n signal, the txrdy_n signal will become inactive one clock
cycle after the Transmitter FIFO is full, potentially causing a FIFO
overflow. If back to back reads of the Receiver FIFO are being gated
by the rxrdy_n signal, the rxrdy_n signal will become inactive one
clock cycle after the FIFO is empty, potentially causing a FIFO
underrun.
Workaround:
If the txrdy_n or rxrdy_n signals are to be used to gate a series of
writes to the Transmitter FIFO or reads from the Receiver FIFO, do not
do back-to-back reads or writes. Allow at least 1 clock cycle between
reads to the Transmitter FIFO or reads from the Receiver FIFO.
John, I hope this helps your readers. In the DesignWare Group we like to
keep our customers informed of bugs and their workarounds as soon as we
find them. Our customers like this type of pro-active support. :)
- [A Synopsys DesignWare CAE Manager]
============================================================================
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
|
|
