A number of people have been asking what happened at the end of Earth
Day with "Ewald" the runt lamb. Because she was so weak & dehydrated,
I had to spend that night bottle feeding her every 90 minutes (between
watching rented movies on the VCR) to get her healthy enough to travel.
(She had lost the urge to suck on a bottle. I was lucky to get her to
drink 1-2 oz. of milk and was afraid her kidneys had shut down.) Once
Scott & Linda arrived 18 hours later to take "Ewald" home, I was bleary,
unwashed and oddly (to them) happy when, during my teaching them how to
bottle feed a lamb, "Ewald" urinated on my foot! (It meant her kidneys
*were* working!) I had to leave the next day for a week and later
wondered if "Ewald" had survived or died. Five days later I happily got:
From: scott.winick@exemplar.com (Scott Winick)
>John - "Ewald" thrives on 12-18 oz. four times/day! She is blossoming!
>The neighborhood kids help with the chores and bathed her (cold water
>and Woolite, of course), and she even smells nice now. She knows no
>fear - dogs, cats, power saws - nothing phases her in her relentless
>drive to be near someone, something, anything. Such devotion, mindless
>though it is, is refreshing.
> - Scott Winick
> Exemplar Logic
( ESNUG 218 Item 1 ) ---------------------------------------------- [5/95]
From: danj@mpd.tandem.com (Dan Joyce)
Subject: Rules Of Thumb For IKOS Runs
John,
The time for an IKOS run is a function of:
(# of gates in ASIC) X (# of vectors) X (# of faults)
Because the size of many ASIC's are 100k+ gates, the person running IKOS
has to target his runs to a small subset of vectors that are trying to
test a small subset of faults. This piecemeal approach was the only way
IKOS run times can be minimized. (As it is, it's not unusual to have IKOS
runs that last a week. If either your IKOS box or your workstation
connected to it has a power failure or a system reboot during the run, you
lose a weeks worth of work!) An additional factor that slows things
down is using timing-mode IKOS RAM models; these models run about 6X
slower than functional-mode RAM models.
- Dan Joyce
Tandem Computers
( ESNUG 218 Item 2 ) ---------------------------------------------- [5/95]
From: [ The Thin Man ]
Subject: The Skinny on Synopsys Tool Development & IBM PC's/Windows
John,
Please keep this anonymys...
We were talking to our Synopsys apps person about a rumor that they were
throwing out all their workstations and doing new development on PC's.
He said this is absolutely *not* what he had observed, but what *is*
true is that new tool development at Synopsys *is* being done on a MS
Windows environment.
Reason given: it's easy to port an application written for MS Windows to
an X environment, but quite difficult to go the other route. So if they
develop for a Windows platform they get the X version almost for free.
That way they can sell the same tools into both the Windows and workstation
markets as they see their future market to include Windows based EDA
platforms.
- [ The Thin Man ]
( ESNUG 218 Item 3 ) ---------------------------------------------- [5/95]
Subject: (ESNUG 216 #1 217 #1) Buffer Insertion Script From SNUG '95
>>buf.ss ... This dc_shell script adds buffers to an input port. By
>>multiple calls you can build a balanced buffer tree, with complete
>>control over the type and number of buffers at each level.
>
>That is the most ridiculous thing I have practically ever seen. I'll bet
>you could have done it by hand and gotten it right many, many, times,
>before figuring this out! Just because something is automated doesn't
>make it better, or even good.
From: vvallet@vnet.ibm.com (Vincent Vallet)
I myself had to write a ridiculous dc_shell script once to find a port
driven by a **logic_0** or a **logic_1**, and insert a buffer between the
**logic_something** and the port. (That way the schematic can be imported
to Cadence Composer. Otherwise Cadence Composer doesn't allow you to
drive an output port with a common signal. That limitation is also one
of the most ridiculous thing I have seen...)
Yes, if you do not need a script, they appear ridiculous. But, if you
are in a situation where you need them, they're lifesavers.
- Vincent Vallet
IBM France
( ESNUG 218 Item 4 ) ---------------------------------------------- [5/95]
Subject: Design Compiler 3.2a Produces Bad/Incorrect Logic!
From: landman@hal.com (Howard Landman)
>
>Hi, John,
>
>We have found a serious bug in DC 3.2a which produces incorrect logic.
>The first symptom we had was that a certain input signal simply vanishes
>from the resulting circuit. (This made no sense since the signal is in
>fact used.) Later we were able to get "compile -verify" to admit that
>something was wrong:
>
> Information: Verification Failed. (OPT-103)
> Verification endpoint sv_reg[2]/next_state is different.
> A distinguishing pattern is:
> i11 : 1
> i12 : 1
> sv_reg[0]/Q : 1
> sv_reg[1]/Q : 1
> sv_reg[2]/Q : 0
> All other inputs may be assigned any value to distinguish the circuits.
>
>Following is the test case source code:
>
> input d,clk,a0,a1,a2,a3; output we_a; reg we_a;
>
> always @( posedge clk )
> if (d)
> case ({a0,a1}) // synopsys full_case
> 2'b0_1 : we_a = a2;
> 2'b1_0 : we_a = a3;
> endcase
> else we_a = 1'b0;
>
>I'm not including our library in the hope that this isn't library
>dependent ... my sense was that the bug happened quite early, perhaps
>even while reading in the Verilog (before compile). This bug does not
>seem to occur in 3.2b ... at least not for this case. I haven't tested
>it on any earlier releases.
>
> - Howard A. Landman
> HaL Computer Systems
From: [ The Synopsys Hotline ]
Hi John,
In v3.2a, you see feedback from the output of the "we_a" flip-flop. If
d = 0, the "we_a" flip-flop should be cleared. Instead, it keeps the
previous value of we_a (due to the feedback). When you input the design
in v3.1b of HDL Compiler, the logic looks fine.
This STAR (24439) is a duplicate of STAR 22402, a problem appearing in
another form. The problem occurs when a "case" statement with a
"full_case" directive is followed by another conditional statement (i.e.
an "if" statement, "else" branch or "case" statement) in the same process.
In the above example, an "else" branch follows a "case" statement that
uses the "full_case" directive, and as a result, you are seeing the bad
logic problem.
This problem is fixed in v3.2b.
There are three workarounds to this problem in v3.2a.
The first possible workaround is to input the Verilog code into v3.1b
of HDL Compiler and write out an unmapped .db in v3.1b. This unmapped
.db can then be input to v3.2a of Design Compiler, and further processing
can continue in v3.2a.
The second possible workaround is to remove the "full_case" directive,
and add a "default" statement to the "case" statement instead (or fully
specify the "case" statement). Following is the modified example:
input d,clk,a0,a1,a2,a3; output we_a; reg we_a;
always @( posedge clk )
if (d)
case ({a0,a1}) // full_case directive was here
2'b0_1 : we_a = a2;
2'b1_0 : we_a = a3;
default : we_a = 1'b0; // a "default" statement is added
endcase
else we_a = 1'b0;
If you have enumerated all the possible cases that can occur in the case
statement, you can modify the "default" statement shown in the above code
(module "works") to assign "x" (don't care) values to the outputs that get
assigned in the "case" statement. The modified code is as follows:
input d,clk,a0,a1,a2,a3; output we_a; reg we_a;
always @( posedge clk )
if (d)
case ({a0,a1}) // Note: full_case directive was here
2'b0_1 : we_a = a2;
2'b1_0 : we_a = a3;
default : we_a = 1'bx; // a "default" statement is added
endcase // Note: Output assigned to "x" instead of 0
else we_a = 1'b0;
This 2nd module is more efficient than the 1st module (above it) from a
synthesis perspective since no additional logic is generated for the
"default" condition. Please note, if a state is not covered in the
case statement, but occurs during simulation, x's will get introduced in
the system. Therefore, specifying "x" in the "default" statement is only
recommended when nonenumerated cases will not occur.
The third possible workaround is to modify the code so no conditional
statements appear following the "full_case" "case" statement in the same
"always" block. Following is the modified example:
input d,clk,a0,a1,a2,a3; output we_a; reg we_a;
always @( posedge clk )
begin
we_a = 1'b0;
if (d)
case ({a0,a1}) // synopsys full_case
2'b0_1 : we_a = a2;
2'b1_0 : we_a = a3;
endcase
end
My suggestion is to create a "default" statement for each case statement.
- [ Synopsys Hotline ]
( ESNUG 218 Item 5 ) ---------------------------------------------- [5/95]
From: vincent@dtc.Kodak.COM (John Vincent)
Subject: Hey! - Mentor Graphics And Other EDA Tools Suck, Too!
John,
I understand from seeing a recent article or two of yours that you are an
independent consultant on CAE tools. Kodak has recently chosen to
standardize on Mentor tools for most CAE. Having used probably half a
dozen different tools over the course of my career, I have a basis for
comparison. I recently took training on Mentor's Idea Station (Design
Architect and Quicksim). I was really disappointed in the user interface
compared to other tools I've used. (It seemed needlessly complex and
confusing, giving the impression they had been developed by people who
had never really had to do a real design with them and had little concept
of structuring the user interface for ease of use for either productivity,
efficiency, or learn-ability.)
I recognize that I am quite spoiled by my exposure to other tools, and
want to see all the best features of each one, but I never cease to be
amazed by how poorly so many EDA tools are implemented. You would think
that by now something simple like schematic capture packages (for example)
would be pretty well settled, with convenient user interfaces. (After
all they have been around for about twenty years!) Yet it is amazing that
the major players (and I have worked with them all) have such significant
holes in very basic areas in their tools which I would have expected to
have been remedied a long, long time ago.
My question is whether in your experience you are aware of whether any
Mentor Graphics users have customized the user interface to the Mentor
tools by defining their own menu structures, function key setups, etc.?
Is there by any chance a third party which is selling an improved user
interface? Do you think there would be benefit in such a custom user
interface? John, have you ever considered the possibility of doing this
as an additional offering from your company?
- John Vincent
Eastman Kodak Company
[ Editor's Note: I couldn't help but get a chuckle out of this
item & the first ad in the Networking Section! :^) - John ]
( ESNUG 218 Networking Section ) ---------------------------------- [5/95]
Wilsonville, OR -- Mentor Graphics Corp seeks technical marketing support for
our proprietary synthesis tools. No Agencies. "martin_lampard@mentorg.com"
Silicon Valley, CA -- 15 yrs in VLSI/ASIC design & VHDL, Synopsys, VSS, JTAG,
Verilog, Mentor, verif., ATM, graphics. No Agencies. "jineth@netcom.com"
|
|
