[ Editor's Note: Given the amount of "reverse" engineering known to
go on in Asia, I laughed when I read this exchange. - John ]
From: wenqiang@public1.guangzhou.gd.cn (wenqiang)
Subject: Want To Copy Out Source Code Of Program From Inside Microchip
> I got a microchip, its width and length is about 5mm(millimetres), and
> it has probably 40 pins. I want to copy out the source program (set of
> microinstructions) written inside it, and write the codes to a new
> microchip. Because this microchip is so small, it's difficult to find
> the matched tools. Do anyone know what equipment should I use to
> accomplish this job? And what's the type of the equipment, where can
> I get it? Or if any company can do this, would you please let me know.
> Your helps would be highly appreciated.
>
> - Wenqiang
> Chinese Linux User Group Guangzhou, China
From: Charlie Burns <cburns@crl8.crl.com>
Generally, the type of equipment needed depends upon the size of the
micro instructions within the microchip. For example, if the micro
instructions are of the risc variety, you can get by with a single tool
(probably a 32 or 64 bit micro-wrench). On the other hand, if your
microchip contains cisc style instructions, you will need a complete
set of micro-wrenches ranging from 8 bits to several hundred bits. I
would avoid equipment which claims to extract variable length
instructions as these tend to strip (lose) the high or low order bits
every so often.
Once you acquire the proper micro-wrench(es), if you look closely at
some of the pins, you will find some marked "I" and some marked "D".
These signify the instruction and data pins respectivley. A risc chip
will just one "I" pin since it only has one size of instructions, a
cisc chip will have a pin for each size instruction (thus the need need
for multiple micro-wrenches). Place a device under each I pin, Martha
Stewert suggests a thimble, to catch the instructions. Slowly open the
"I" pin, with the micro wrench, and let the instructions run out into
the thimble. It's important that the thimble is on a anti-static pad,
especially if the micro chip supports dynamic loading.
Hope this helps,
- Charlie Burns
P.S. "Anybody seen my left-handed micro-wrench?"
---- ---- ---- ---- ---- ---- ----
From: pontius@btv.MBI.com (Dale Pontius)
For Christmas my wife got me a wonderful matched set of left & right handed
micro-wrenches. But they're MINE!
I thought you only used left-handed micro-wrenches on big-endian
architectures. Normally you would think it's the other way, but given the
preponderance of right-handed people and little-endian CPU's. Perhaps if
they'd gotten around to inventing micro-wrenches before the X86...
- Dale Pontius
IBM Microelectronics Division Essex Junction, Vermont
( ESNUG 290 Item 1 ) ----------------------------------------------- [5/98]
Subject: (ESNUG 280 #7) Need Help Doing Synopsys-HSPICE Correlation
> First of all, thanks for all the great information presented in the ESNUG
> postings. We are doing some Synopsys to hspice correlation. I am
> interested if anyone has an idea of how to automatically generate the
> input vector that correlates to the report_timing static analysis. In my
> particular case I am dealing with an asynchronous logic block, so there
> are no flip flops to disturb the path. Any ideas anyone?
>
> - Dave Schaefer
> Logical Silicon Solutions
From: sudershan.vuru@analog.com (Sudershan Vuruputoor)
John,
I am not aware if Synopsys timing analyser has this capability, but we have
successfully used Pathmill static timing analysis tool that has this
capability. (PathMill is static timing tool from the EPIC Technology Group
of Synopsys.)
We perform transistor level static timing analysis using Pathmill. Pathmill
has a command "print_spice_path" that generates HSPICE netlist for the
entire path, including all the input stimulus, clock waveforms and voltage
condition required for the dynamic circuit-level simulation for that
particular path. HSPICE can be run on the resultant netlist without any
manual changes for further analysis.
- Sudershan Vuruputoor
Analog Devices India Pvt Ltd.
( ESNUG 290 Item 2 ) ----------------------------------------------- [5/98]
From: [ Der Kaisers Kochen kann keinen Kalbskopf kochen! ]
Subject: Not Happy About Forced Migration From Motive To PrimeTime
Dear John,
After the merger of Synopsys and Viewlogic my fear is that some powerful
tools used in ASIC design are most likely going to vanish. Here in Europe,
Synopsys is trying to put quite a big pressure on Motive users to switch
to PrimeTime. The customer is supposed to sign a "Motive Upgrade
Certificate of discontinued Use" in which he agrees to cease the use of
Motive after a fixed date (12/98). For his signature, the customer is
offered a shared license which allows to check out either Motive or
PrimeTime plus a free substitution of the Motive license into a PrimeTime
license. To my knowledge PrimeTime does not provide the same features as
Motive at the moment.
My question to the ESNUG readers is how they react on this offer.
- Will Synopsys succeed to convince Motive users to move to PrimeTime?
- Do they move to PrimeTime without any complaints? Do they move at all?
- What about the costs for training the ASIC crew on PrimeTime and rewrite
the scripts for an automated timing analysis flow?
John, please keep me anonymous.
- [ Der Kaisers Kochen kann keinen Kalbskopf kochen! ]
( ESNUG 290 Item 3 ) ----------------------------------------------- [5/98]
Subject: ( ESNUG 287 #3 ) Canada, Nortel, & Cadence Spectrum Consulting
> Why should I care if it pissed off Andy Grove, the newly ex-CEO of Intel,
> if this raises what consulting engineers are paid? Why should I care if
> some Nortel managers might be trying to boot Cadence out, if Cadence's
> efforts mean that Nortel engineers get paid more to stay? In my reversal,
> I've learned that those who live in glass houses shouldn't look gift
> horses in the mouth. My error. Spectrum helped increase engineering
> wages. Cool.
> - John Cooley
> Industry Gadfly
From: "Jonathan Crone" <Jonathan.Crone.cronejp@nt.com>
Hi John...
Just read your column about 'Glass houses, Gift Horses' referring to Cadence
and their consulting engineering group... Interesting reading, but I do
have a 'nit' to pick...
In the column, you referred to "Nortel in Canada"
This probably is really silly, but Canada is a country of 30 million,
covering a bigger territory than the USA. Nortel has offices in about 20 +
cities in Canada, and in several of those cities, employs a thousand or
more engineers, technical and marketing staff... (or like in Ottawa, the
technology HQ, we have 12000+ plus technology types (engineers, CS,
researchers etc.)) Of course there are a few less now, because some of them
went to Cadence!!! :-)
Your reference is analogous to referring to "IBM in the USA"
When Cadence opened their office here in Ottawa, it certainly opened a lot
of eyes... Complete departments, from the design manager on through much of
the design team disappeared within weeks to go to Cadence.
The really nice side effect was there were also a bunch of startups, as guys
realized. "Hey if Cadence can do it, so can I!!!"
Cadence's effect was just like you said "It made engineers get paid better"
Almost enough to make me want to go be a ASIC guy... :-)
have a good one.
- Jonathan P. Crone
Nortel Broadband Networks ( "in Canada" )
( ESNUG 290 Item 4 ) ----------------------------------------------- [5/98]
Subject: (ESNUG 289 #13) Testing Embeded RAMs Via The Full SCAN Chains
> I'm curious if anyone in the chip CAD market can test the embeded RAMs
> through the full scan chain. Are there EDA products/tools that do this?
> Theoretically, you should be able to accomplish this since there are
> Flip-Flops all around the RAMs, which the scan chain has complete control
> over. Plus, I don't really care how many vectors it takes, as long as the
> process is automagic.
>
> - Victor J. Duvanenko
> Truevision
From: Andrew Maccormack <andrewm@bristol.st.com>
John,
The problem for trying to test an embedded RAM with a simple full-scan chain
is that you have side-effect when you are scanning your vector in. You need
to be able to stop your write-enable to the RAM while you are scanning the
vector, otherwise every time there is an "active" bit in the FF, you will be
writing something to the RAM. It would be a very clever bit of software
that could get around this! Basically you would need a pad in test-mode
that either directly controlled the write enable or allowed a boundary-scan
like shadow register update. This latter option might break your ATPG
software, though.
Cheers,
- Andrew R MacCormack
SGS-Thomson Microelectronics UK
( ESNUG 290 Item 5 ) ----------------------------------------------- [5/98]
Subject: ( ESNUG 289 #3) DC 98.02 Creates Bad Logic W/ Floating Inputs!
> Supposedly there is a patch that fixes this bug, but I haven't applied
> it yet. According to the readme file:
>
> "This patch will only fix the problem in dc_shell. You will not be able
> to use the workaround in Design Analyzer."
From: [A Synopsys CAE]
John,
That README file had a typo. The sentence above, "This patch will only fix
the problem in dc_shell....." is incorrect. The fix is in Design Analyzer.
There was an error in the readme file. The patch is available for all
products and not just dc_shell.
- [A Synopsys CAE]
( ESNUG 290 Item 6 ) ----------------------------------------------- [5/98]
From: [ "It Was The Best Of Lines, It Was The Worst Of Lines" ]
Subject: Synopsys Hotline No Speaky English Good & No Use Synopsys, Also!
John -
Please don't associate my name with the following comments. This may be
controversial and I still have to work in this field.
I am getting really fed up with the Synopsys hotline. Invariably I call
with a problem and talk to someone who is a poor communicator and who
seems to have little practical experience with Design Compiler (thankfully
I am using mainstream tools). I don't understand how Synopsys can accept
putting someone on the hotline who has trouble communicating verbally and
in writing. In the last ten years I have worked with engineers who were
born in India, China, Ireland, U.K., Malaysia, Israel, the former Soviet
Union, Taiwan, and the U.S. and none has had as much trouble communicating
as some of the folks on the Synopsys hotline. Once I do get through to
people they seem to be little more than grunts who need a test case to
reproduce my problem. I have not found engineers who can take a problem
description and hypothesize causes and/or solutions. Most don't even try.
Twice with the last few months I have been told by hotliners that no solution
exists only to find a solution on my own or by talking to real design
engineers at my company who helped me figure it out. I tried restricting my
interaction with the hotline to mail messages, but the initial response time
was awful and the hotliners appear to prefer to call instead of send
e-mail... I wonder why?
Perhaps if you anonymously publicize my situation you can do a poll and get
some feedback. My guess is that my situation is not isolated.
- [ "It Was The Best Of Lines, It Was The Worst Of Lines" ]
( ESNUG 290 Item 7 ) ----------------------------------------------- [5/98]
Subject: ( ESNUG 289 #11 ) Life Is HELL Because Xilinx Has No Damn SCAN FF's!
> A problem we have encountered is that we can't use insert_scan because
> there are no scan flip-flops in the Xilinx library. ... People I've
> talked to have given me some suggestions:
>
> 1. Add a scan flip-flop to the Xilinx library. How do I do this?
>
> 2. Force Synopsys to create a mux in front of a normal flip-flop instead
> of trying to use a muxed flip-flop from the library. A rumour says
> that an earlier version of Synopsys did this and that it is possible
> to force it into this "old mode". How do I do this?
>
> 3. Create a script that "manually" inserts the muxes and add appropriate
> attributes in order for insert-scan to work. What attributes are
> that and how should they be set?
>
> If someone has done this before or have any other ideas on how to do it
> I'd appreciate if you could share them on ESNUG.
>
> - Magnus Jacobsson
> Ericsson Radio Systems Kista, Sweden
From: [ Synopsys Test Compiler R&D ]
John,
I would not recommend suggestion 3. Why I don't recommend workaround 3
(add the muxes by script, and then add attributes to guide scan hookup) is
because its more complex -- more opportunity for error.
But here's how to use the set_scan_segment command to achieve what Magnus
describes in his suggestion 2:
With the capabilities introduced in v3.4b (Hierarchical Scan), it is possible
to create a scan chain using normal flip-flops with a mux in front even when
your library does not contain scan cells. However, this only works with a
scan style of multiplexed_flip_flop.
Consider the following circuit:
module sub1 ( clka,in, q ,reset);
input in,clka,reset;
wire a,b,c;
output q;
assign q = a | b;
FD2 u3 ( .D(b), .CP(clka), .Q(a),.CD(reset ));
FD2 u4 ( .D(in), .CP(clka), .Q(b),.CD(reset ));
endmodule
In order for Test Compiler not to scan replace the flip-flops, define each
flip-flop as a scan segment. The script to perform this follows:
set_scan_configuration -style multiplexed_flip_flop
set_scan_segment seg_u3 -access {test_scan_in u3/D, test_scan_out u3/Q}
-contains {u3}
set_scan_segment seg_u4 -access {test_scan_in u4/D, test_scan_out u4/Q}
-contains {u4}
check_test
preview_scan -show all
insert_scan
Hope this helps.
- [ Synopsys Test Compiler R&D ]
( ESNUG 290 Item 8 ) ----------------------------------------------- [5/98]
Subject: What Are The Differences Between RTL & Behavioral Code ?
> I am confused: what on earth the differences between RTL and behavioral
> level code. Is there any obvious instruction for RTL only or for
> behavioral only in Verilog? And there is another confusion. Whether the
> result of the synthesis written by behavioral code is worse than RTL code?
> And how do I start to write RTL code instead of behavioral ?
>
> - Wang Yueh-yi
> National Chiao-Tung University Taiwan
---- ---- ---- ---- ---- ---- ----
From: Ganapathy Subbaraman <subbu@eng.adaptec.com>
Both RTL and behavioral are the same. After u synthesise RTL or behavioral
u get the netlist in gates.
- Ganapathy Subbaraman
Adaptec
---- ---- ---- ---- ---- ---- ----
From: tcoonan@mindspring.com (Thomas A. Coonan)
I think I disagree. "Register Transfer Level" implies logic between clocked
registered/latches) stages. Implies synthesizable. Behavioral means any
model that implements any behavior - no restrictions. I use behavioral
verilog models, for example, for A/D converters. They use real numbers,
arbitrary math and programming constructs, and there's no presumption of
synthesizability (although, advanced tools push the edge of what can be
synthesized (e.g. Behavioral Compiler from Synopsys), RTL is the traditional
breakpoint).
If you modeled a car cruise control system in verilog, with a bunch of
arbitrary delays, real numbers, math, etc. it'd be behavioral. If you
modeled it with register element, boolean equations and some combination
of clocks; it'd be RTL. You can mix-n-match; an RTL or gate-level netlist
will often have a memory module within it, that is.. Behavioral!
Maybe you were looking for something more precise?
- Tom Coonan
Scientific Atlanta
---- ---- ---- ---- ---- ---- ----
From: ravelx <ravelx@ozu.ccl.itri.org.tw>
Synopsys has the new Behavior Compiler. Check it out. As Tcoonan says,
behavioral is that you just describe the behavior of the circuit or the
object, without concerning the real circuit. It may be realized or may
not. Therefore we have the term 'synthesizable'.
Behavioral Compiler synthesizes and optimizes the synthesizable subset of
behavioral code. But I'm not sure if it does do so well as they describe.
- "ravelx"
Industrial Technology Research Institute
---- ---- ---- ---- ---- ---- ----
From: Lars Rzymianowicz <lr@mufasa.informatik.uni-mannheim.de>
Hi Yueh-Yi,
Behavioral code is more abstract than RTL (Register Transfer) code. Language
constructs like loops (for), initial-blocks or events are pure behavioral
Verilog. RTL code is written with synthesis in mind, since tools like
Synopsys can map RTL code much better than behavioral (most synthesis tools
accept only a subset of an HDL).
Behavioral code compilers are on the way, but you have to know a lot of
tricks to get reasonable results.
- Lars Rzymianowicz
University of Mannheim Germany
---- ---- ---- ---- ---- ---- ----
> Both RTL and behavioral are the same. After u synthesise RTL or behavioral
> u get the netlist in gates.
>
> - Ganapathy Subbaraman
> Adaptec
From: zoltan@bendor.com.au ( Zoltan Kocsi )
Well, how do you synthesise this:
//
// When A has rising edge, 3 clocks later B changes state.
// (2-3 clocks actually, depending on the relation between A and clock)
//
always begin
@ ( posedge A );
@ ( posedge clock );
@ ( posedge clock );
@ ( posedge clock );
B = ! B;
end
It is certainly a valid behavioural statement but not RTL and RTL synthesis
tools would choke on it.
- Zoltan Kocsi
Bendor Research Pty. Ltd. Austrailia
---- ---- ---- ---- ---- ---- ----
From: "John H. E. Fiskio-Lasseter" <johnfl@cs.uoregon.edu>
Zoltan,
Is this really the behavioral equivalent? Or will all three of those
"posedge clock" guards fire in the same tic, since there is "zero time"
between each one?
- John H. E. Fiskio-Lasseter
University of Oregon
---- ---- ---- ---- ---- ---- ----
From: "Matthew Morris" <mmorris@@lace.colorado.edu>
That is equivalent to saying that
#100
#100
#100
b = !b;
will happen instantaneously since there is "zero time" between each #100..
The @ is a sequential statement.
- Matt Morris
University of Colorado at Boulder
---- ---- ---- ---- ---- ---- ----
From: "John H. E. Fiskio-Lasseter" <johnfl@cs.uoregon.edu>
Matt, that's actually the heart of my question. They aren't really the
same, because a delay control guarantees that this thread will be suspended
for an amount of time that is determined when the delay is encountered.
I can tell from a glance at this code that it will take 300 tics to reach
"b = !b".
Event controls don't have any such property, however. A statement
guarded by "@(posedge x)" executes (with zero delay) as soon as there's
a change in x from low to high (I realize you know all this). The
question is: across what time boundary must this change happen?
Between simulation tics? Or will any sequential block that sets x to 0
and then to 1 in "zero time" do the trick? And will every "posedge x"
guard in the example above see this change or just the first one?
I believe you're right, by the way. What I'm interested in is how
precise the semantics are on the matter.
- John H. E. Fiskio-Lasseter
University of Oregon
---- ---- ---- ---- ---- ---- ----
> always begin
>
> @ ( posedge A );
> @ ( posedge clock );
> @ ( posedge clock );
> @ ( posedge clock );
> B = ! B;
> end
>
> Is this really the behavioral equivalent? Or will all three of those
> "posedge clock" guards fire in the same tic, since there is "zero time"
> between each one?
>
> - John H. E. Fiskio-Lasseter
> University of Oregon
From: zoltan@bendor.com.au ( Zoltan Kocsi )
Well, according to my book (Thomas & Moorby) one @(event) eats one event
so the subsequent ones waiting for the same event will not see it, they
have to wait for the second, third ... event. You can think of @(event),
if event happens at T, letting your program run at T+0 which is
infinitesimally small time later than T. (Actually, T+epsilon and
epsilon -> 0 :-)
Fire up your simulator and test it. I did, and it works.
- Zoltan Kocsi
Bendor Research Pty. Ltd. Austrailia
---- ---- ---- ---- ---- ---- ----
From: sharp@cadence.com (Steven Sharp)
The three statements are still sequential. The first @(posedge clock)
executes after the posedge. Therefore the second @(posedge clock) does
not start waiting until after the first posedge has occurred. An event
can be treated as an atomic occurrence; it has no duration. By the time
anything wakes up on it, it is over. If there is only one posedge, the
block can only proceed past one guard.
That much is definite. The opposite situation is not. If you have
always
begin
@(posedge clk) ;
@(posedge clk) ;
@(posedge clk) ;
do_something;
end
initial
begin
clk = 0;
clk = 1;
clk = 0;
clk = 1;
clk = 0;
clk = 1;
#1 ;
end
the initial block produces 3 posedges, so it is possible we could get to
do_something. However, we probably won't. Execution of statements within
a begin-end block can be suspended in favor of other processes in the model.
However, there is no good reason for a simulator to do so, since it will
probably complicate and slow down execution. If the simulator suspended
in favor of the always block whenever it produced a posedge on clk, it
would get to do_something. However, it will probably just schedule the
always block to execute and then continue with the initial block. Only at
the #1 will it switch to execute the always block and end up waiting at
the second @.
Waiting on nets is generally better behaved than waiting on regs, since
they aren't assigned to directly by process code.
- Steve Sharp
Cadence
---- ---- ---- ---- ---- ---- ----
> #100
> #100
> #100
> b = !b;
>
> I can tell from a glance at this code that it will take 300 tics to reach
> "b = !b". Event controls don't have any such property, however. A
> statement guarded by "@(posedge x)" executes (with zero delay) as soon as
> there's a change in x from low to high (I realize you know all this).
> The question is: across what time boundary must this change happen?
>
> - John H. E. Fiskio-Lasseter
> University of Oregon
From: "Matthew Morris" <mmorris@@lace.colorado.edu>
The time boundary is up to your design. The @ and the # are the very same
section of the spec. Both just wait. # waits a fixed amount of time after
this delta. @ waits for an event *after* this delta.
Incidentally, food for thought.. This should give you some intuition.
How/why do these act differently?
repeat (5)
@posedge clk
b = ~b;
and
repeat (5)
@posedge clk ;
b = ~b;
( besides the obvious semi after clk... )
- Matt Morris
University of Colorado at Boulder
---- ---- ---- ---- ---- ---- ----
From: "John H. E. Fiskio-Lasseter" <johnfl@cs.uoregon.edu>
Forgive me for being obtuse, but I don't get your point, Matt. The first
one inverts b 5 times, once for each time the clk goes high. The second
does nothing through the next five rising edges of clk. Then it inverts
b once.
Is your point that the second statement is equivalent to "#5 b =~b"
(assuming clk is inverted every unit of simulation time)? If I have
instead in a separate thread:
repeat (5)
#0 clk = ~clk;
Is it possible that I will exhaust all five guards in one tic of the
simulation clock (since processes can, in principle, be interleaved)?
- John H. E. Fiskio-Lasseter
University of Oregon
---- ---- ---- ---- ---- ---- ----
> If you have
>
> always
> begin
> @(posedge clk) ;
> @(posedge clk) ;
> @(posedge clk) ;
> do_something;
> end
>
> initial
> begin
> clk = 0;
> clk = 1;
> clk = 0;
> clk = 1;
> clk = 0;
> clk = 1;
> #1 ;
> end
>
> the initial block produces 3 posedges, so it is possible we could get to
> do_something. However, we probably won't. Execution of statements within
> a begin-end block can be suspended in favor of other processes in the model.
> However, there is no good reason for a simulator to do so, since it will
> probably complicate and slow down execution. If the simulator suspended
> in favor of the always block whenever it produced a posedge on clk, it
> would get to do_something. However, it will probably just schedule the
> always block to execute and then continue with the initial block. Only at
> the #1 will it switch to execute the always block and end up waiting at
> the second @.
>
> - Steven Sharp
> Cadence
From: "John H. E. Fiskio-Lasseter" <johnfl@cs.uoregon.edu>
I think I'm becoming convinced of Matthew Morris's argument on this. If
I'm right, your example will only fire at most one guard, and that only
if the two processes are interleaved. When a guarded statement is
released, it is executed during the "delayed thread" stage of the
cycle. In other words "@(1) some_statement" (where the @(1) indicates a
firing guard) is equivalent to "#0 some_statement". If, however, we
modify the code to be:
always
begin
@(posedge clk) ;
@(posedge clk) ;
@(posedge clk) ;
do_something;
end
initial
begin
#0 clk = 0;
#0 clk = 1;
#0 clk = 0;
#0 clk = 1;
#0 clk = 0;
#0 clk = 1;
#1 ;
end
I believe that we can guarantee all three guards will fire, in the sense
of being able to prove some determinacy of execution order. The
execution within the always thread should unroll to:
#0#0#0 #0#0#0 #0#0#0 do_something;
I hate zero delay :-)
- John H. E. Fiskio-Lasseter
University of Oregon
---- ---- ---- ---- ---- ---- ----
> Is your point that the second statement is equivalent to "#5 b =~b"
> (assuming clk is inverted every unit of simulation time)? If I have
> instead in a separate thread:
>
> repeat (5)
> #0 clk = ~clk;
>
> Is it possible that I will exhaust all five guards in one tic of the
> simulation clock (since processes can, in principle, be interleaved)?
>
> - John H. E. Fiskio-Lasseter
> University of Oregon
From: sharp@cadence.com (Steven Sharp)
I am not sure what point he was illustrating. However, the answer to
your final question is yes. In fact, good old section 5 states that #0
forces a process to suspend and be re-queued, forcing the interleaving
you suggest. So by that rule, it is not only possible but required that
all five guards be triggered by the separate edges. Adding #0 makes the
pulses "wider", though still with a width of zero in simulation time units.
- Steven Sharp
Cadence
---- ---- ---- ---- ---- ---- ----
> Just consider if there's additional guard in the always block, how will
> b behave? My simulator shows nothing happens to b.
>
> always
> begin
> @(posedge clk) ;
> @(posedge clk) ;
> @(posedge clk) ;
> @(posedge clk);
> b = 1;
> end
>
> initial
> begin
> #0 clk = 0;
> #400 clk = 0;
> #0 clk = 1;
> #0 clk = 0;
> #0 clk = 1;
> #0 clk = 0;
> #0 clk = 1;
> #1 ;
> end
>
> - Wenzhong
> Beijing Telegraph Administration
From: "John H. E. Fiskio-Lasseter" <johnfl@cs.uoregon.edu>
Nothing should happen to b. You have four guards and only three positive
edges. With the changes scheduled in the initial block, the always-loop
unrolls to:
#0#400#0#0 ; #0#0#0 ; #0#0#0 ;
@(posedge x);
the_rest_of_the_block_which_you_cant_reach;
In other words, this is equivalent to scheduling a delayed-execution
guarded thread at time 400 (which is guaranteed to be the eighth or
later later thread to run at that time), with no other thread which can
release the guard.
- John H. E. Fiskio-Lasseter
University of Oregon
( ESNUG 290 Item 9 ) ----------------------------------------------- [5/98]
Subject: ( ESNUG 288 #2 289 #7) Yes, VCS *DOES* Wait For Licences !!
> The new rev. of now synopsys's VCS doesn't wait for a license any more,
> this ability allowed a larger number of users to use fewer licenses of VCS
> (queing theory) the runs which are started wait for a license then run.
> Now they fail saying "No license". I'm sure this increases the number of
> license needed by many eng. groups. More $$$ for Synopsys I suppose that
> they need to do this to get return on the 1/2 billion dollar cost of
> ViewLogic.
>
> - [ Neelix of the Voyager ]
From: [ VCS Technical Support ]
John,
When I first read this email I thought that we had introduced a bug in the
new VCS4.1 software. I got email messages from several places, most (I later
found) must have originated after the messages were posted to ESNUG. I
checked and we have many customers that successfully uses this feature right
now. We ourselves can't reproduce the problem and have never seen it
either. Customers that complained about this feature going away couldn't
later find any problem either.
The messages below are from two US customers:
> OK folks: I just tested the +vcs+lic+wait feature, and it works as it
> should. So, if you have a problem, let me know. Unless we can
> reproduce it, we can't very well complain to Synopsys...
> Oh, forgot to tell you. +vcs+lic+wait works fine over here. We are using
> both VCS 4.0.3 and VCS 4.1.1 simultaneously. The daemon we are using is
> the viewlogic viewlmgrd daemon that came with powerview 6.1.
I want to say that we have NOT removed this feature, and we haven't planned
to remove it in the next releases either. It's one of those free features
that VCS users have come to like. Another is the ability to free up a
license by pressing CTRL-Z.
Our plan is simple, add features/performance without charging for new
upgrades and to take market share from other simulators. This has been a
very successful strategy. Anything else simply doesn't make economic sense.
If "Abe Lincoln" and "Neelix" still have trouble with this feature, please
give us more details on ESNUG so we can help you.
- [ VCS Technical Support ]
( ESNUG 290 Item 10 ) ---------------------------------------------- [5/98]
Subject: (ESNUG 285 #6 286 #4) What About Bell Labs' "FormalCheck" Tool?
> I have used both Chrysalis and Formality to do RTL to gate comparisons
> on a 850k gate chip. Both tools had their successes and their
> failures but I think that Chrysalis has a more mature tool without
> going into technical details about algorithms. The Chrysalis tool
> was available on the market long before Formality and I did pretty
> much all work with Chrysalis.
>
> - Anders Nordstrom
> Nortel Ottawa, Ontario
John,
Is it too late to add FormalCheck, a formal verification tool from Bell
Labs, (http://www.bell-labs.com/org/blda/product_formal.html) to the
conversation? Anyone actually using this tool? Any success/horror stories?
A one-liner in a recent ISD said that SGI/Cray bought $1.5M worth of this
tool...
- [Name and Address withheld please]
|
|
