From: "Kevin Bush" <kevin.bush@minc.com>
Dear Mr. Cooley,
Through extensive analysis over the past five years I have discovered a
significant trend in the EDA market. I call this trend "The Cooley
Effect". It accurately predicts the success of a company based upon your
stated opinions of that company. This trend is so dramatic, that I
believe all EDA marketing managers should immediately drop their Geoffrey
Moore books and start implementing my "Crossing the Cooley" (aka "Making
Cooley Cross") strategy.
Surprisingly, a positive opinion from you does NOT imply future success.
Rather, the "Cooley Effect" predicts great success when you choose to
criticize a company. As evidence, consider your "ESDA Shootout". You
strongly criticized Mentor Graphics' performance in these tests. Now they
are, in your words, "making money hand over fist" in ESDA. Or, consider
Cadence's Spectrum services strategy. Since you compared it to sheep
droppings, their stock has nearly tripled in value. Finally, you came
down harshly on VHDL. Under the "Cooley Effect", your negative words must
cause a significant upswing for the item under fire. The Europeans must
have been listening, because VHDL is now dominating their design processes.
I could go on with many more examples of the "Cooley Effect", but I think
you can already see the pattern.
Now I am bravely prepared to implement my "Crossing the Cooley" strategy
here at MINC. After acquiring IST and Synario, we dominate programmable
logic design and are in a position to be a major EDA player.
Unfortunately, you never pay attention to us.
So, I am respectfully asking (OK, begging), that you say something terrible
about us. Call our 60,000 seats pure bull. Say our NT focus will lead us
to the slaughterhouse. We don't care what, just say anything -- but keep
it negative. We wouldn't want to risk a positive word from you. The
"Cooley Effect" model goes non-linear when you say something nice.
Thank you for your consideration. I eagerly await your insults.
Sincerely,
- Kevin M. Bush
VP Marketing
MINC Incorporated
( ESNUG 288 Item 1 ) ----------------------------------------------- [5/7/98]
Subject: ( ESNUG 287 #5 ) "Crack VMC & Win $75,000" Is A Rigged Sucker's Bet
> I noticed that you are one of the vmc contest officials. You know as well
> as I do that this is a sucker's bet. There is no way to extract the design
> from a VMC model and if anything I would be the only one that could even
> get close to extracting any sort of information that even resembled the
> design. So I guess synopsys will not be giving away that humvee.
From: landmh@taec.toshiba.com (Howard Landman)
John,
I think I agree that, if the compiled model DOES NOT CONTAIN the information
which is needed to reconstruct the source to the level required by the
contest, then this is not only a sucker bet but also a red herring. It's a
sucker bet because, it's like having a contest to decompile a C program
where you can't win unless you recreate the original variable names - and
where the binary has been stripped so that information isn't available.
The reason it's a red herring is that you don't NEED to recreate the source
to that level for the model to be insecure. Generating an equivalent RTL
or gate level netlist (the $18,000 prize) is already a SERIOUS breach of
security. It's rather disingenuous to imply that only decrypting information
which doesn't even exist constitutes "breaking" the encryption!
Synopsys should either be willing to state that they know the requirements
for winning the Humvee are mathematically possible to achieve, or else
reduce them until they are.
Then, too, if Synopsys was really serious, this contest wouldn't have a time
limit of only 6 weeks. Most serious decryption challenges have a timescale
of years.
In the real world, most security problems are human, not technical. "Social
engineering" often succeeds where computer science would fail. I'll split
whatever I win 50-50 with the first person (eligible or not) who emails me
the original source or any other form of prize-winning solution in time for
me to submit it. :-)
- Howard Landman
Toshiba America Electronic Components
( ESNUG 288 Item 2 ) ----------------------------------------------- [5/7/98]
Subject: VCS No Longer Waits For Licences? That SUCKS Big Time!
From: [ An Abe Lincoln Wannabe ]
John,
Please keep me ANONYMOUS on this posting.
QUESTION: Why is it that after Synopsys purchased ViewLogic, the latest
release of VCS doesn't appear to have the old ability to wait for license
availability? Is it possible that somebody wants to force users to buy
more licenses?
- [ An Abe Lincoln Wannabe ]
---- ---- ---- ---- ---- ---- ----
From: [ Neelix of the Voyager ]
Hi John!
I have to be Anonymous on this, but you should know that...
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 ]
( ESNUG 288 Item 3 ) ----------------------------------------------- [5/7/98]
Subject: ( ESNUG 287 #1 ) Verilog, VHDL, NT, Unix & Ron Collett's Bad Advice
> Before coming to Systems Science, I worked for Zycad over 6 years. Ron
> was contracted and, as a stipulation, would speak to the company about his
> vision of the simulation-environment-of-the-future. Ron assuredly promoted
> the demise of Verilog in favor of the upcoming contender, VHDL.
>
> After my first experience hearing Ron's presentation, I was always
> very skeptical of his market analysis. In 1996, it hit directly in my
> realm when he avoided the VHDL-versus-Verilog topic and began to harp on
> the demise of the workstation platform in favor of NT.
From: landmh@taec.toshiba.com (Howard Landman)
John,
Has Ron Collett ever been right about anything?
One of Claude Shannon's theorems is that an information channel which is
perfectly wrong transmits just as much information as one which is perfectly
right.
So, I always pay utmost attention to Ron Collett. I read his conclusions
assiduously, and them act boldly, in complete confidence that whatever
he predicted isn't going to happen. I just hope he never predicts that
the sun is going to rise tomorrow morning.
One of Ron's other great predictions was that UNIX was doomed, that shipments
would peak in 1997 and then decline. This prediction was made not long
before the World Wide Web exploded and Sun Microsystems stock increased in
value by 10X in less than 2 years. And let's not forget LINUX ...
I can't tell you how good it makes me feel to have Ron predicting that NT
will wipe out UNIX. It means I won't have to switch for a long, long time.
(Technical nit: Isn't NT Posix compliant? That means NT *is* UNIX, even
if only an unreliable form of it.)
I hope my competition switches to NT.
> the hybrid environment: A workgroup of users working on NT platforms
> with one or 2 Sun workstations acting as servers for "serious work".
All my work is serious work,
- Howard Landman
Toshiba America Electronic Components
---- ---- ---- ---- ---- ---- ----
> ... Zycad's ViP was not the victim of a Verilog vs VHDL market struggle,
> but of the following facts:
>
> 1) ViP was a very early exploration on "how to" and most importantly
> "how not to" accelerate VHDL execution.
> 2) ViP's architecture was the antithesis of the KISS principle.
> 3) ViP machines were extremely difficult to use.
> 4) ViP machines never came close to provide a return on investment
> even to die hard VHDL users.
>
> - Gabe Moretti
> Chair VHDL International
> VP Engineering, VeriBest, Inc.
From: Ramesh Narayanaswamy <nramesh@ganesh-systems.com>
John:
I take exception to some of Gabe Moretti's comments regarding the ViP.
I worked on the ViP product and worked with every prospective client and
the dozen or so paying customers.
I don't believe Gabe knows much if anything about the architecture of
the ViP or its usage.
His approach seems to be, let us rubbish this dead product and company
to defend VHDL.
In reality the ViP was a extremely simple multiprocessor built for VHDL
execution; two versions of the engine were built and both worked cleanly
the first time. The software was no more complex than the essential
complexity of VHDL.
The real issue was, the architecture was betting on parallelism in the
user designs. So performance was very design dependent; for the design
styles/designs that had reasonable parallelism the machine could deliver
10-25x speedup over the best software solution, the customers who saw
this level of performance bought the machine. One of the customers who
was getting good performance bought a bunch of boards for good money
even after the product was killed. For other designs speedup could be as
low as 2-3x and it did not make sense for the customer to spend $150K
for a hardware solution; he could just wait for the next generation
workstation and spend $30-40K instead.
Some aspects of VHDL had significant if peripheral impact on the ViP.
The complexity of the language led us to release early versions of the
product that only supported a sub-set of the language. It obviously was
difficult to use when the compiler rejected some of your code. :-)
The fact that none of the major processor design groups (Intel, AMD, MIPS,
Sun, etc.) which spend the big bucks in high end verification (emulators,
cycle simulators, gate accelerators etc.) used VHDL was an issue. This
meant the traditional early adopters who would take the effort to modify
coding style, etc., to get the performance were not available.
- Ramesh Narayanaswamy
Ganesh Systems
( ESNUG 288 Item 4 ) ----------------------------------------------- [5/7/98]
Subject: ( ESNUG 286 #11 287 #2 ) Putting Accurate Delays On Inputs
> I was wondering if anyone knows an easy way to automatically set the drive
> at each pin such that I am assured that there is, say, 0.5ns at all inputs.
> The set_drive command will work, but I need to know the capacitance at
> each input port in order to set each pin's drive correctly, e.g. set_drive
> <0.5ns/capacitance> <input_port>. The problem is knowing each input's
> capacitance. ...
From: Jon Kuppinger <Jon.Kuppinger@Symbios.Com>
John,
To add to a long list of good solutions to the setting of input drive in
Synopsys, I implemented a method for our design kit users where they can run
a script to generate a Synopsys library cell which has a set drive strength.
This is accomplished by setting the cell delay(s) to zero and setting the
transition time(s) to the desired input drive strength. An example is as
follows and is simply used as the driving cell. This cell can be added to
the users link library simply by using the update_lib command or a separate
library can be made and used separately. The following cell communicates
a 0.5ns rise and fall time to the port(s) it is connected to.
cell (INPUT.5R.5F) {
area : 0;
pin(I) {
direction : input;
capacitance : 0.00;
fanout_load : 0.00;
}
pin(Z) {
direction : output;
max_fanout : 100.00;
max_capacitance : 100.00;
max_transition : .5;
function : "I";
timing() {
timing_sense : positive_unate;
related_pin : "I";
cell_rise(scalar) {
values("0.00");
}
rise_transition(scalar) {
values(".5");
}
cell_fall(scalar) {
values("0.00");
}
fall_transition(scalar) {
values(".5");
}
}
} /* end of pin */
} /* end of cell */
Since it contains no functionality, a Library Compiler license is not needed
to compile it to db format.
- Jon Kuppinger
Symbios, Inc.
( ESNUG 288 Item 5 ) ----------------------------------------------- [5/7/98]
From: Victor_Duvanenko@truevision.com
Subject: DC 98.02 Creates Logic With Floating Inputs On Some Gates!
John,
Just a quick note on a problem that sometimes shows up when compiling with
high effort "on". (At least I believe that it only happens with high effort
being used.) Sometimes the 1998.02 synthesizer will create logic with the
inputs of some cells not connected to anything. If you follow the good
practice of always doing "check_design" after synthesis, then it will flag
it. Synopsys has a patch for the problem that seems to work (at least it
worked for one of my blocks), the patch is 1998.02-1, and my FAE was
very responsive when I flagged this problem and I had a fix within an hour
(thank you). The scary thing to me is that I always compile with
verify_effort high, and it didn't catch the problem - I'll be double checking
the man pages to see what this option is supposed to be verifying.
- Victor J. Duvanenko
Truevision
( ESNUG 288 Item 6 ) ----------------------------------------------- [5/7/98]
Subject: ( ESNUG 286 #9) A Verilog Reader for Intel HEXfiles
> Does anybody have a verilog reader for Intel hexfiles or do you have
> any idea, where I can find such a reader?
>
> - Reichert Ulrich
> Siemens AG Munich
From: Jon Connell <jon.connell@hl.siemens.de>
John,
This isn't a Verilog solution (it's C), but you should be able to translate
this into Verilog really easily. If memory serves, the 20-bit address hack
was because our compiler only spits out 20-bit addresses.
extern char* memory;
void load(const char* file_name, int crc_check)
{
char l[257]; /* Line buffer */
unsigned address, base_address;
int length, rec_type, crc, i;
FILE* f;
f = fopen(file_name,"r");
if (!f) {
char msg[256];
fprintf(stderr, "load: no such file \"%.128s\"", file_name);
return;
}
rec_type = 0;
base_address = 0;
do {
if (l != fgets(l,256,f))
goto format_error;
if (l[0] == ':') {
crc = 0;
length = byte(l+1);
crc += length;
address = base_address + 256*byte(l+3)+byte(l+5);
crc += byte(l+3);
crc += byte(l+5);
rec_type = byte(l+7);
crc += rec_type;
/* Evaluate crc */
for (i = 0; i < length; i++) {
crc += byte(l+9+2*i);
}
crc += byte(l+9+2*i);
if (crc_check && ((crc & 0xff) != 0))
goto format_error;
if (rec_type == 0) {
/* Data record */
for (i = 0; i < length; i++) {
memory[address++] = byte(l+9+2*i);
}
} else if (rec_type == 2) {
/* base_address = 16*(256*byte(l+3)+byte(l+5)); */
/* only 20 bit address, bits 19:16 on 10th char of line */
base_address = 256*(256*hexdigit(l[9]));
} else if (rec_type == 4) {
base_address = (256*byte(l+9) + byte(l+11)) << 16;
}
}
} while (rec_type != 1);
return;
format_error:
fprintf(stderr, "load: invalid Intel Hex file");
return;
}
You might also want to take a look at this:
http://www.idt-isep.ipp.pt/isep/electro/automacao/doc/micro/intelhex.tut
- Jon Connell
Siemens
( ESNUG 288 Item 7 ) ----------------------------------------------- [5/7/98]
Subject: ( ESNUG 287 #9 ) You Can't Find O-in On the Web Anywhere!
>I thought the two trip reports were very useful, and downright hysterical
>at times. It just goes to show, you should never write off someone's talent
>just because he doesn't like emacs... I especially liked the description of
>0-in. I've been meaning to look into their product for a while. I couldn't
>find it, having foolishly searched for the word "zero". They should add a
>(<META> zero ) (in proper HTML) so the search engines will pick that up.
>
> - Rachael Berman
> Mint Technology
From: Paul Estrada <pi@0-in.com>
Yes, Virginia, (er, John...) there is a 0-In Design Automation. The
company's name is pronounced "zero-in" and spelled with the number 0 (as
opposed to the capital letter "O".) While our name has some nice properties
like being memorable (once you learn it) and being listed first in many
directories (like DAC and EDAC), web search engines don't like it. Many web
search engines use "-" to indicate text that must NOT be included in the
result documents, hence searching on "0-In" can be fruitless.
With respect to Rachael's comments, our web page does use <META> tags
including "zero". You can see them yourself by viewing the document source
from your browser (assuming you can get to our home page). Unfortunately,
it seems that most web search engines got wise to the fact that web authors
were abusing <META> tags to get web site hits and, therefore, have
apparently stopped using them.
You can find most EDA companies listed at the following:
EDAC: <http://www.edac.org:80/EDAC/Companies/0-In.html>
DAC: <http://www.dac.com/35exhlist.html>
Anyway you can find us at <http://www.0-In.com>.
- Paul Estrada
VP Verification Engineering
0-In Design Automation
( ESNUG 288 Item 8 ) ----------------------------------------------- [5/7/98]
Subject: ( ESNUG 287 #13 ) Mapping From Hierarchical Paths -> Design Names
> I have a uniquified, hierarchical design. I would like to start with
> a path to a cell
>
> "h2u1/h3u4/lh_out_reg"
>
> and figure out which design it is in so I can change my current_design
> to it. Conceptually, I want to
>
> cd "h2u1/h3u4".
>
> Is there a simple way to go back and forth between paths and design
> names? I have tried the current_instance command, but I really need
> to cd between designs, not instances. I want to take the path of a
> gate or a net, cd to the design containing it, then run a script that
> adds and deletes nets and cells. I can only do these commands in the
> design itself.
>
> - Will Leavitt
> GigaNET, Inc. Concord, MASS
From: James Muha~ <jmuha@sedona.ch.intel.com>
John,
First, set the current_instance to the instance containing the cell, then
set the current_design to the current_reference. You need to append "/.."
to the path to the leaf cell in order to set the current_instance to the
instance containing the cell.
current_instance = <path_to_leaf_cell>/..
current_design = current_reference
- James Muha~
Intel
---- ---- ---- ---- ---- ---- ----
From: "Tom Harrington" <tharring@ford.com>
Hey, John,
Have you tried using current_reference? It's useful for converting an
instance name to the corresponding design name. It's not a command but
rather a variable that always contains the current instance's reference.
If the current_instance is the cell you're interested in, you can do
'current_design current_reference' to set the current design to the
corresponding cell. You could also do 'find design current_reference'
or 'list current_reference' to make sure you know where you are.
Also, keep in mind that current_instance can be used like the Unix 'cd'
command; for example, "current_instance .." will move you up a level.
So with current_reference, you can cd between instances, and then
get the design names. It's awkward, but it works.
In the example above, since h2u1/h3u4/lh_out_reg is the path to a cell,
you could set current_design to the design corresponding to h2u1/h3u4
as follows:
current_instance h2u1/h3u4/lh_out_reg/..
current_design current_reference
If lh_out_reg is a leaf cell, you can't set current_instance to it directly.
But the above will work just fine and put you at the cell containing
lh_out_reg.
Of course, if you could just start with h2u1/h3u4 as the initial path,
you could do it this way:
current_instance h2u1/h3u4
current_design current_reference
I think that current_reference will do what you need. Good luck.
- Tom Harrington
Ford Microelectronics Colorado Springs, CO
---- ---- ---- ---- ---- ---- ----
From: [ Synopsys R&D ]
John,
In response to ( ESNUG 287 Item 13 ), try the following.
execute (-s dirname h2u1/h3u4/lh_out_reg)
parent_cell = dc_shell_status
get_attribute parent_cell ref_name
foreach(des, dc_shell_status) {}
current_design des
- [ Synopsys R&D ]
---- ---- ---- ---- ---- ---- ----
From: Will Leavitt <leavitt@giga-net.com>
Well, posting to esnug motivated me to dig a little deeper. All I need to
do is get the ref_name attribute:
dc_shell> get_attribute find(cell, "h2u1/h3u4") ref_name
Performing get_attribute on cell 'h2u1/h3u4'.
{"crc_gen_2"}
dc_shell> current_design dc_shell_status
Current design is 'crc_hec_2'.
{"crc_hec_2"}
- Will Leavitt
GigaNET
---- ---- ---- ---- ---- ---- ----
From: [ Synopsys Methodology Consulting ]
John,
This may not be your idea of simple, but it works:
1) Create the following Bourne shell script (called "cdinst.sh"):
#!/bin/sh
inst_list=`echo $1 | awk -F/ '{ for (i=1;i<NF;i++) print $i " "}'`
for inst in $inst_list
do
echo get_attribute $inst ref_name
echo current_design dc_shell_status
done
NOTE: This script assumes that the argument given is a hierarchical cell or
net reference. If it's a pin reference, you'll have to modify the awk
command to strip off the last two elements instead of just one.
2) make sure it's executable and in the path, then in dc_shell:
dc_shell> sh cdinst.sh h2u1/h3u4/lh_out_reg > cdinst.dc
dc_shell> include cdinst.dc
NOTE: The "cdinst.sh" script creates the following commands:
get_attribute h2u1 ref_name
current_design dc_shell_status
get_attribute h3u4 ref_name
current_design dc_shell_status
I hope this helps.
- [ Synopsys Methodology Consulting ]
( ESNUG 288 Item 9 ) ----------------------------------------------- [5/7/98]
Subject: ( ESNUG 287 #4 ) Need 98.02 Ultra License To Replace Old Commands?
>We're attempting to run 98.02 and have found an interesting requirement of
>another license (DC Ultra) in order to use one of the new commands that
>replaces an obsolete compilier option (prioritize_min_paths).
>
>set_cost_priority gives an error message.
>
>Has anyone else run into this problem?
>
> - Mark Fox
> Advanced Micro Devices
From: tboydsto@su102s.ess.harris.com (Ted Boydston)
Yep, I ran into that problem too. Specifically, I ran into the Ultra license
issue when I tried to set up my own cost priority to something other than
default or delay. That is:
set_cost_priority \
{ max_capacitance max_delay max_fanout } => Ultra license required
set_cost_priority defualt => no Ultra license required
set_cost_priority -delay => no Ultra license required
Oh, by the way, my local apps engineer mentioned no need for a new license to
use this feature during the 98.02 orientation session, and neither does the
man page. Lost in License Land,
- Ted Boydston
Harris Government Aerospace Systems Division
---- ---- ---- ---- ---- ---- ----
From: Kelly Fromm <kellyf@packetengines.com>
Hi, John,
We have seen exactly the same results with set_cost_priority. However, 98.02
is backwards compatible with -proiritize_min_paths, so we have continued to
use it. It still works. Here is what we are seeing...
dc_shell> set_cost_priority min_delay
Error: DC ultra license is required to use feature 'set_cost_priority'.
(UIO-65)
0
dc_shell> compile -prioritize_min_paths
Warning: As a result of -prioritize_min_path, min_delay is made a
higher priority than max_delay. (UIO-58)
I thought it was a bad move for consumers when compile -scan also required
full time use of a Test Compiler license, and now instead of having lots of
DC licenses and a few TC, we need near equal numbers. Now it seems that we
will need more licen$e$ just to keep min-path fixing?
- Kelly Fromm
Packet Engines
---- ---- ---- ---- ---- ---- ----
From: Bob Wiegand <rwiegand@ensoniq.com>
John,
The prioritize_min_paths compile option is still there. As far as I can
tell it still works as expected, and the DC Ultra license is not required.
The option was removed from the documentation only.
- Bob Wiegand
Ensoniq
( ESNUG 288 Item 10 ) ---------------------------------------------- [5/7/98]
From: [ The Man With "Sensitive" Bosses ]
Subject: Escalade vs. Summit and Mentor Renoir
John,
Please keep me and my company anonymous. They are very sensitive, and
I get myself into trouble too easily, as you know.
I was wondering if anyone else is looking at Escalade's Design Book
as an alternative to Summit and Mentor's Renoir?
We have looked at both Summit and Escalade about a year ago. Escalade
seemed to be easier to use and more intuitive. It had some convenience
features in the state machine editor which Summit did not. We also had
a state diagram in Summit which produced code which would not synthesize.
On the other hand. Summit had better HDL import capability and some of
the experienced VHDL designers preferred the way Summit treated libraries.
Another thing I like about Escalade is their ModuleWare library of
parameterized functions. These are nice for datapath design and are
not restricted to LPM functions. I consider these to be especially
valuable to new HDL designers. It was actually in looking for this
capability that learned of Escalade.
We have one seat of both Summit and Escalade currently and are starting
an assessment of them along with Renoir, looking at their capabilities
against user needs.
Generally, experienced VHDL users are not very receptive to the use of
graphical tools, except perhaps for doing complex state machine design,
claiming that they are more productive with text. However, they will
usually concede that it is a lot easier to share information if it is
graphical than textual. Personally. I am for whatever one feels to be
the most effective. I advocate a mixed approach, with **overall**
productivity (which includes documentation and reuse) being the objective.
I consider HDLs as a means to an end, not an end in themselves. (This
point seems often to be lost on many people.) IMHO the ability to easily
switch between graphics and text or between languages (without having
to become a language expert in each) to achieve the best results is the
goal. The more the tools help me do this, the better.
Please keep me and my company anonymous. They are very sensitive, and
I get myself into trouble too easily, as you know.
- [ The Man With "Sensitive" Bosses ]
( ESNUG 288 Item 11 ) ---------------------------------------------- [5/7/98]
From: [ Not Done With Negotiations ]
Subject: What's The Skinny On Aspec, Leda, and Virage?
Hi John,
Please keep [ Company Name Deleted ] and myself anonymous until we finish
negotiations.
Thanks.
[ Company Name Deleted ] is in the process of switching from the standard
"full serv" ASIC design model into the black waters of a COT flow. We like
the pricing offered by IBM and Chartered, and are looking to partner with a
design services house to get us through the digital back-end and mixed-signal
integration. I noticed a few postings on purchasing digital cell libraries,
but then things got quiet. We've looked into Aspec, Cascade, Leda and
Nurlogic.
To reduce the risk involved in this project, we're leaning towards a
library provider (Standard cell, I/O and RAM/ROM) that can also provide the
design services. (No library-integration-finger-pointing, missing
views, learning curves, etc.) Unfortunately this limits the field to
just Aspec. (Aspec acquired SIS Microelectronics, Inc before they went
public.)
This particular project just became next year's bread and butter, so
risk management is extremely important. Are we being too conservative
using a single vendor?
Are there any designer references out there willing to praise [punish]
Aspec and their library and/or design service offerings?
Reasons to use libraries from Leda Systems, and RAM/ROM from Virage?
Any datapoints would be greatly appreciated.
- [ Not Done With Negotiations ]
( ESNUG 288 Item 12 ) ---------------------------------------------- [5/7/98]
From: Davide Falchieri <davide.falchieri@bo.infn.it>
Subject: Can't Obtain A Testbench That Has Both Internal & Boundry Scan
Hello,
I have just begun by now using Synopsys tools and I have found they are
more powerful than Cadence for every step of the design flow. One of the
feature I particularly appreciate is Test Compiler that gives me the
possibility of synthesizing internal scan chains and boundary scan
circuitry, compliant to 1149.1 JTAG standards. An other remarkable tool
is the ATPG tool that allows creating very effective test-benchs in few
hours: my problem is that I can't automatically obtain a test-bench that
takes into account for both internal and boundary scan. To be honest I
still haven't obtained a test-bench that gives stimuli to the TAP pins: TCK,
TMS, TRST and TDI, but only to the inputs of the scan chains. For the JTAG
output TDO the testbench asserts that the value desired is 'Z' from the
beginning to the end.
Have I to perform some manual modification of the schematic (that's
really not so simple under Synopsys) ? Or isn't it possible at all ?
If there is some Synopsys Test Compiler users I would be glad to talk
with them for exchanging opinions and ideas.
- Davide Falchieri
Bologna University Bologna, Italy
|
|
