From: pwaddell@mfi.com (Pete Waddell)
>John, as Editor-in-Chief of Printed Circuit Design magazine I'm intimately
>familiar with all of the Cadence Allegro, Composer (Concept) and BoardQuest
>products. I alerted my associates upon hearing about your dog food drive
>for Joe Costello and we laughed so hard we cried. (John, you've outdone
>yourself this time!) I passed the hat around and collected $24.00, three
>washers, and one homemade Mentor POG disk for our beloved Joe. Please tell
>Joe we cheerfully wish him "Bon Appetit!"
>
> - Pete Waddell, Editor-in-Chief
> Printed Circuit Design magazine
From: "Anonymous" at Digital Equipment Corporation
>John, enclosed is a check for $11.00 to buy a 20 lb bag of "Kibbles'N Bits"
>as marked on your order form. Could you please take a marker & relabel the
>bag as "Quibbles On Bits" in "honor" of Cadence's decision to drop support
>of DEC platforms after protracted negotiations? Thanks for the relabeling!
In reference to my stating that I'll personally collect and deliver all the
dogfood to Cadence Chelmsford, Jeff Markham (markham@cadence.com) replied:
>I'll make sure the dobermans are aware of your delivery.
>
> - Jeff Markham, Cadence Design Systems
This explains much if Cadence has Dobermans wandering the hallways as part
of some sort of bizzare employee discipline/retention plan! :^)
- John Cooley
the ESNUG guy
P.S. Keep those letters with checks for / cans of dog food coming!
( ESNUG 223 Item 1 ) ---------------------------------------------- [7/95]
Subject: (ESNUG 215 #5 217 #4 220 #4) Specific Reasons Why Synopsys Sucks!
>Not only that, but the *extensive* help almost never leaves you stranded.
>How many tools allow you to do things like 'help HDL-103' to get an extended
>description of why its unhappy along with instructions for what to try next?
>In fact, just as a test, I just tried to read in a non-existent file:
>
> design_combobulator>read -f vhdl none.vhd
> Error: Cannot read file 'none.vhd'. (UID-58)
> {}
>
>Now, just in case that's not enough information, I could do:
> design_combobulator>help UID-58
From: biswal@india.ti.com (Krutibas Biswal)
John,
I don't agree with this point. Yes, Synopsys has this feature, but the help
it prints are not always sufficient. Let us take for example if the above
command "read -f vhdl foo.vhd" fails, then it is obvious and intuitive that
either the file does not exist or the file has no read permissions. 90+% of
Synopsys users won't need an explanation for this. But trying "help SYNDB-3"
will get you a truely incomprehensive message when you REALLY need help.
design_analyzer> help SYNDB-3
or try, help SYNDB 1, 10, 11, 12, 13, DB-4, DDP-<n>, where <n> is any number!
There is no point in providing a feature which is not actually there.
- Krutibas Biswal
Texas Instruments (India) Pvt Ltd
( ESNUG 223 Item 2 ) ---------------------------------------------- [7/95]
Subject: (ESNUG 222 #1) Verilog Parsers, full_case, parallel_case in 3.3a
>Personally, I hate the new Synopsys Verilog 3.3a parser. With the following:
>
> always@ (A0 or M)
> case (A0) // synopsys full_case
> 3'b 000 : z0 = 0;
> 3'b 001 : z0 = M[0];
> 3'b 010 : z0 = M[1];
> 3'b 100 : z0 = M[2];
> default : z0 = 1'bX;
> endcase
>
>It has a "default" statement therefore it is complete by definition -- yet I
>get the following message:
>
> Warning: You are using the \fBfull_case\fP directivewith a case
> statement in which not all cases are covered. (HDL-370)
>
>What is "\fBfull_case\fP" ?? Not all cases covered?? It has a "default"!
> (Fortunately, the resulting logic seems correct.)
From: celia@netcom.com (Celia Clause)
From my understanding of the synopsys full_case function, I would expect
some sort of warning from this code. From what I have read, and seen
generated, the full_case statement should normally ignore your default. You
have told the compiler that the case statement is fully defined (i.e. No
default condition is necessary.) If you take out the //synopsys full_case
you probably won't get the warning or you could get rid of the default, since
stating full_case implies a default of X for all unspecified cases anyway.
I am not actually using this version of Synopsys, so this is just a guess,
but the warning is probably just a clairification of the functionality that
already existed. (i.e. Use full_case or default, not both.)
- Celia Clause
---- ---- ---- ---- ---- ---- ----
From: [ No Muck Please ]
John,
Please don't use my name or direct e-mail. Just wanted to get another vote
in on the "parallel_case" and "full_case" compiler directives spitting out
that warning. (Synopsys & my company have a "cooperative" relationship, and
I'd rather stay out of the muck...) I tend to write state machines directly
as one-hot (with states defined as "000001", 000010", etc). I always
completely specify the case statements, and use full/parallel case to make
sure the logic is minimized. I, too, am now seeing these bogus warnings from
the 3.3a Verilog reader/parser.
I sent them a test case which they have received -- no resolution yet.
- [ No Muck Please ]
( ESNUG 223 Item 3 ) ---------------------------------------------- [7/95]
From: jcooley@world.std.com (John Cooley)
Subject: Can't Use Multiple Verilog "Always" Or VHDL "Process" Loops w/3.3a
My sources in Synopsys just told me that Design Compiler 3.3a may *fatal*
when encountering a Verilog reg or a VHDL signal in more than one of their
respective always/process loops if it infers either registers or latches.
(It fatals with error id=591124 in v3.3a.) The two workarounds are:
- Before compiling set a switch that defaults back to v3.0b with:
hdlin_seq_device_v30_mode = "true"
- or -
- Edit your Verilog/VHDL source code to contain only one "always" per
"module" or one "process" loop per "architecture."
In my opinion this is *basic* functionality of a synthesis tool. This tells
me that if you can avoid using v3.3a, do so!
- John Cooley
the ESNUG guy
( ESNUG 223 Item 4 ) ---------------------------------------------- [7/95]
From: gregg.lahti@tempe.vlsi.com (Gregg Lahti)
Subject: DC's Lunar-Phase-&-Presidential-Approval-Rating Naming Schemes
John,
My serious gripes with Design Compiler is the inability to keep the naming
convention used in the VHDL code. This is especially painful if you would
like to keep the naming convention throughout the design so that you can
create seeding (placement) scripts in the backend of the layout process for
a tighter design, or just have more readable schematics/design for debugging.
For example, suppose we wish to plop down a 32-bit loadable register element.
This would be the easiest way to do this:
PCI_REG: process (clk) begin
if clk'event and clk='1' then
if load_pci='1' then
pci_reg(31 downto 0) <= pci(31 downto 0) after 1 ns;
end if;
end if;
end process PCI_REG;
Fine, except going through synthesis, Design Compiler decides to *randomly*
change the naming convention from PCI_REG to some UXXXX number. It also may
not keep the bit numbering convention, either if you decide to get fancy
with your generates or bussing scheme.
Hand instantiating the registers and then apply a "dont_touch" won't work,
either. Using the example below (muxed flop):
g1: for b in 0 to 31 generate
PCI_REG: mfntnb
port map ( da => pci(b), db => pci_reg(b), sa => load_pci, cp => clk,
q => pci_reg(b), qn => open);
end generate g1;
and applying "dont_touch { PCI_REG* }" command in dc_shell doesn't work.
Design Compiler again drops the naming convention and will implement
U-numbers in some random-use-the-lunar-phase-and-presidential-approval-rating
numbering scheme. It will also go and change the signal naming conventions
from pci_reg to U290_port_qn or something that relates to the changed
component name.
- Gregg Lahti
VLSI Technologies, Inc.
( ESNUG 223 Item 5 ) ---------------------------------------------- [7/95]
From: st92j0gw@dunx1.ocs.drexel.edu (Chris T. Papademetrious)
Subject: Handling Unconnected Ports & Naming DesignWare Instantiations
John, Question for the masses: What's the accepted way of leaving a port
unconnected? We're instantiating transceivers in our design (to communicate
with off-chip signals), but the transceiver model has ports that we don't
need to use. Do we tie all these ports to an "unused" signal? Wouldn't this
tie them together then? How do I handle this?
Also, how would I go about naming the instantiation of a DesignWare adder
when implemented as an arithmatic operator, such as "c <= a + b;". Our
compilation guys need to know this stuff for their compile scripts. We would
like to ensure the names of such operators are known, regardless of the size
or number of adders in the design.
- Chrispy Papademetrious
Drexel University
( ESNUG 223 Item 6 ) ---------------------------------------------- [7/95]
From: oia@smtpgate.ashtech.msk.ru (Igor Orlovsky)
Subject: (ESNUG 219 #1) A Better "A Better Modified Buffer Tree Script"
Hi John,
I got mail from Marnix Arnold (M.Arnold@et.tudelft.nl) with the critique of
my buffer tree generation script having problems with tree generation on
primary nets -- those nets connected on the input ports of a module. (In my
original script I was only connecting between pins of internal macro cells.
When I needed to buffer tree on input port, first I inserted a root buffer.)
I've modified my script from ESNUG 219 #1 to support input ports of module.
Please have your readers e-mail me at "oia@ashtech.msk.ru" if they want this
new version.
- Igor Orlovsky
Ashtech, Inc., Moscow, Russia
( ESNUG 223 Item 7 ) ---------------------------------------------- [7/95]
From: buco_fan@vnet.ibm.com (Anderson H. Hunt)
Subject: Parameterized Verilog Functions with Ranges, Defining & Calling
John,
I want to define a collection of n-bit Verilog functions where the value of
n is controled by a parameter. Something like:
function [n-1:0] flip_bus;
parameter n = 32;
input [n-1:0] a;
integer i;
for( i = 0; i < n ;i = i + 1 )
flip_bus[i] = DP_INVERT_D( a[i] ); // synopsys label f
endfunction
The problem is that 'n' in the 'function' statement doesn't get defined until
until the next line. The Synposys "HDL Compiler for Verilog Reference
Manual" seems to indicate the functions are allowed in functions, but doesn't
give any examples of how to override parameters in a function call. (The
reason I need to do functions instead of modules is that functions can be
instaniated conditionally unlike modules. This allows me to do growable
macros better (as in, fanout gets to big, throw in a buffer.))
- Andy Hunt
IBM
[ Editor's Note: This smells a lot like VHDL's "generic's"; if there's a
clever way to do this in Verilog, I'd be very interested. - John ]
( ESNUG 223 Networking Section ) ---------------------------------- [7/95]
Colorado Springs, CO - Need sr. VLSI design eng. with Synopsys/Verilog exper.
for automotive ASICs. Death To Headhunters! "fmicos!martin@uunet.uu.net"
|
|
