Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 3650

Article: 3650
Subject: Re: ANNOUNCE: New Model of the Month - 16 bit ADC
From: Mark Sitkowski <marks@acci.COM.AU>
Date: Tue, 09 Jul 1996 13:34:11 +1000
Links: << >>  << T >>  << A >>
Peter wrote:
> 
> >With switched current circuits you can do it on a pure digital process.
> >With switched capacitor circuits you can do it on a digital process with
> >some analog features. [Good resistors and capacitors.]
> 
> Plus a comparator.
> 
> And with "good resistors" and a comparator you could do an ADC as
> well, using just a successive approximation register as the only
> logic. A switched cap ADC is just that, instead of resistors it uses
> caps.
> 
> I think someone is pulling our leg here, unless this "model" is a
> freebie, or unless it contains the pretty complex algorithm used to
> self-calibrate the switched-cap ADCs.

I've been making SPICE models of ADC's that way for years - and teaching
others how to do it in my modelling training courses. The question of
calibration never arises, since the capacitors can have any tolerance
you care to specify. Nope, he's telling you the truth. 

Want to join my class...?

-- 
Best regards,
Mark 
                           
 ------------------------------------------------------------------------------
 Mark Sitkowski
笑比哭好!
 Australian Computing and Communications Institute
 723 Swanston Street
 Carlton Victoria 3053
 ------------------------------------------------------------------------------
 Phone: (613-9) 282-2530    E-mail: marks@acci.com.au
 Fax:   (613-9) 282-2534    WWW:
http://www.acci.com.au/People/marks.html

 Home phone: (613-9) 729-0731
给我打电话!
 Home fax:   (613-9) 720-1487
 ------------------------------------------------------------------------------
Article: 3651
Subject: Re: why? internal error in VSS when simulting
From: jcooley@world.std.com (John Cooley)
Date: Tue, 9 Jul 1996 05:50:58 GMT
Links: << >>  << T >>  << A >>
Felix K.C. CHEN <flxchen@diig.dlink.com.tw> wrote:
>** internal error: vhdlsim:
>Please Report (No attributes on signal /T_BENCH/TO_SW/ESWCLK)
>FAULT CONTEXT
>      program: 'vhdlsim'
>      release: '3.3b'
>      Architecture: 'sparc'
>      phase: 'Run-time'
>      last UI Command: run 200
>      simulation time = 0ps
>FAULT ID:
>'2304524 374576 454228 323452 324296 79012 3049100 3046720 300676 8300'
>
>Have any of you encountered similar troubles before?  I need help.


Felix, you really haven't given enough information here to enable anyone
but the Synopsys Hotline to help you.  That is, no one but them can use
just FAULT ID's to determine what a bug is.  Good luck!

                           - John Cooley
                             Part Time EDA Consumer Advocate
                             Full Time ASIC, FPGA & EDA Design Consultant

===========================================================================
 Trapped trying to figure out a Synopsys bug?  Want to hear how 4488 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."
Article: 3652
Subject: ASIC/VHDL, Graphics Chips Development, to 35k, Cambridge - ECM
From: Topjob <topjob@ecmsel.demon.co.uk>
Date: Tue, 9 Jul 1996 13:15:47 +0100
Links: << >>  << T >>  << A >>
Subject: Ref:n.5972 - ASIC/VHDL, Graphics Chips Development, to 35k,
CAMBRIDGE


This young, dynamic company is at the cutting edge of the high profile
sector of specialist semiconductor development, primarily in graphics
applications.

They seek a number of high calibre ASIC Designers to progress the next
generation of projects.

With a good degree in a relevant subject, you will have
extensive experience developing devices of 30/40K gates and upwards
and have solid VHDL skills. All the roles will involve high level
design and testing and will be extremely challenging.

These are excellent opportunities to develop your career in this
exciting development environment at the cutting edge of this high
profile sector.

-- 
For further information on ECM visit www.ecmsel.co.uk

Please contact us by Email (Cvs in plain ASCII text - not coded!)
topjob@ecmsel.co.uk  ------ Alternatively Snail, Fax or Phone:
ECM Selection Ltd, The Maltings, Burwell, Cambridge, CB5 0HB.
Tel:  01638 742244                      Fax:  01638 743066

Article: 3653
Subject: Advanced Network Products, Top UK Co., to c55k, Southern England - ECM
From: Topjob <topjob@ecmsel.demon.co.uk>
Date: Tue, 9 Jul 1996 13:23:51 +0100
Links: << >>  << T >>  << A >>
Subject: Ref:n1275 - Advanced Network Products,Top UK Co., to c55k,
SOUTHERN ENGLAND

                       ADVANCED NETWORK PRODUCTS

                        Negotiable to c55,000

PLEASE QUOTE REF: 1275.

With one of the UK's most exciting, high-growth companies engaged in
the research and product development of 'next generation' computer
communication & network technologies.

These new appointments, reporting at Board level, are created as part
of a planned development programme.

SOFTWARE DEVELOPMENT MANAGER

Responsible for all aspects of Software Product Development, from
concept to release, for both stand alone and PC based products.

You should have a sound background gained in lifestyle Software       
Development - ideally for Network Management, Switching or related    
products, coupled with excellent Project Management skills and the    
ability to manage and motivate a team of c12 software specialists.    
                                                                      
HARDWARE DESIGN MANAGER                                               
                                                                      
To take responsibility for Product Hardware Design & Innovation.      
                                                                      
Ideally you should have a strong background in the design of digital  
products for medium/high volume manufacture, coupled with excellent   
Team Leadership & Design Management skills.  Experience with ASIC/FPGA
based Network, Bridges, Switches, Graphics plug-ins or related        
products would be particularly valuable.                              
                                                                      
SOFTWARE & HARDWARE ENGINEERS                                         
20k -45k                                                    
                                                                      
Additionally we seek six top-calibre Software & Hardware Specialists -
from fresh Graduate to Technical Specialist - to work at the forefront
of high-speed networking technology.                                  
                                                                      
Ideally you should have an excellent academic track record, enjoying  
the challenge of working at the forefront of technology and have      
experience of either low-level Embedded Asynchronous Device Driver, or
similar software, or digital FPGA-based hardware design. A knowledge  
of Ethernet, Token Ring or ATM Networking; IP routing; PBX Core       
Switching; DPNSS; ITU Qxxx or Hxxx Standards; QSIG or related         
technologies would be a significant plus.                             
                                                                      
The importance placed upon Product Innovation as the key to continued 
market leadership is indicated by the Upper Echelon Salaries,         
Comprehensive Benefits Package, excellent Facilities and Career       
Development Opportunities which are offered.                          
 

--
 
For further information on ECM visit www.ecmsel.co.uk

Please contact us by Email (Cvs in plain ASCII text - not coded!)
topjob@ecmsel.co.uk  ------ Alternatively Snail, Fax or Phone:
ECM Selection Ltd, The Maltings, Burwell, Cambridge, CB5 0HB.
Tel:  01638 742244                      Fax:  01638 743066

Article: 3654
Subject: jul9-test
From: Aage Farstad <aage.farstad@ffi.no>
Date: Tue, 09 Jul 1996 15:17:06 +0200
Links: << >>  << T >>  << A >>
test
Article: 3655
Subject: Xilinx Xc4000E Questions
From: djm@yaz.crc.com (David J. Matthews)
Date: Tue, 9 Jul 1996 13:59:08 GMT
Links: << >>  << T >>  << A >>
Hi,

I am embarking on an XC4013E design and have a couple of questions...

1.  I am bringing a bidirectional 32-bit bus into the device which
essentially looks like a microprocessor bus.  It is used to load
and read back registers, read back status, etc.  

There are two ways to design this.  One is to create a single 32-bit
bus using the internal tri-states, and everything gets dumped onto
that bus.  The second is two create one 32-bit bus coming in from the
pins (writing to internal device registers) and lots of little buses
which get muxed together for the readback path.  

The question is, which of these is better?  It seems to me that the
tri-state uses less routing resources since it is only one bus, but
that the placement (and hence routing) is more critical due to the
restricted placement on the TBUFs.  The muxed approach requires more
routing resources and CLBs.  Any opinions from people who have had to
make this decision?

2.  The second question is regarding the preferred method for using
the floor planner.  Is it better to floor plan before PPR or after? 

I realize that the answer to this is design dependent, so here are
some details about the design:

It has some arithmetic elements (adders, subtracters) and many large
counters. 

It contains some logic which must run at a fairly reasonable speed (33
MHz). 

It is fairly datapath intensive.

Thanks for your responses!


-- 
############################################################################
#                                                                          #
# Dave Matthews                        djm@papillonres.com                 #
#                                                                          #
# Papillon Research Corp.              Providing Full Product Development  #
# (formerly Chrysalis Research Corp.)           including:                 #
# 52 Domino Dr., Concord, MA 01742     * System Architecture               #
# Phone - (508)371-9115                * ASIC and FPGA Design              #
# Fax -   (508)371-9175                * VHDL/Verilog Modeling & Synthesis #
#                                      * EMI - EMC Consulting Services     #
#                                                                          #
# (Chrysalis Research Corp. is not affiliated with Chrysalis Symbolic      #
#  Design, Inc.)                                                           #
############################################################################
Article: 3656
Subject: RE: Sanity check for 100K gate DSP FPGA project
From: Jack Ogawa <jacko@Altera.COM>
Date: Tue, 9 Jul 1996 17:53:03 GMT
Links: << >>  << T >>  << A >>
----------------------------
Achim Gratz writes:

>What do I have to tell our distributor here in Europe to get a kit?
>If they don't have it, what would be the non-800 number to call in 
>the U.S.?
----------------------------

Just ask your distributor for the DSP Design Kit from Altera.  Otherwise, there are two options:

Contact our main European Sales office in the UK:
44 1628488811

or, contact us here in the US:
(408) 894-7000, ask for the Literature Department.

Regards,
Jack

Article: 3657
Subject: Xilinx XC4000E Availability
From: joeyc@tornado.seas.ucla.edu (Joey Y. Chen)
Date: Tue, 9 Jul 1996 23:15:21 GMT
Links: << >>  << T >>  << A >>
Hi,

	Has anyone received their order of Xilinx XC4000E FPGA's lately?
We have ordered 5 XC4025E's, and it's been about 2 month since we placed
the order, and they keep on telling us the shipment is being delayed.

-Joey Chen
Article: 3658
Subject: FPGA capacity comparison
From: joeyc@tornado.seas.ucla.edu (Joey Y. Chen)
Date: Tue, 9 Jul 1996 23:20:06 GMT
Links: << >>  << T >>  << A >>
Hi,

	Anyone of you out there had experience using both Xilinx and Altera
FPGA's?  Since our Xilinx FPGA (XC4025E) order has been delayed yet again,
I would like to know how the Altera Flex 10K series compares with the Xilinx
XC4000E in terms of capacity.
	The Xilinx XC4025E claims capacity of 25,000 "typical" gates, and
the Altera Flex 10K-100 claims 100,000 "typical" gates.  Are they comparing
the same thing here?
	Thanks.

-Joey Chen
Article: 3659
Subject: Re: ANNOUNCE: New Model of the Month - 16 bit ADC
From: Mark Sitkowski <marks@acci.COM.AU>
Date: Wed, 10 Jul 1996 09:56:08 +1000
Links: << >>  << T >>  << A >>
> Sure, but for those of us in the US, is there a printed or web
> reference you could point me to? I am an EE, doing digital chips, but
> am very interested in broadening my horizons.
> 
> TIA
> Garfield

Hi Garfield,
I'm afraid analog modelling is a bit of a black art and, since
it's perceived as 'difficult', few people acquire the skills to
do it (in fact, there's only about 50 of us in the world get involved
in it in a major way).

If you're an EE, you're 70% of the way there, but the reading material
is a bit thin. There's only one book on macro-modelling ever been
published (its title is something original, like 'Macro-Modelling')
by Prentice-Hall, but I wouldn't use their ADC model. It's a software
implementation of the hardware.

If the method you're using permits it, try this:

First make a DAC, using weighted current sources, switched (multiplied)
by a set of digital inputs ('1' and '0', not '5' and '0'!). Run this at
a clock rate of about 3GHz, and put the analog output into a comparator,
whose other input is the analog input. Differentiate (or whatever...)
the comparator output to give you a 'CONVERSION COMPLETE' strobe, and
drive a latch with this. If you have an edge triggered latch, you don't
need to differentiate. The data inputs to the latch are the DAC outputs,
and the latch output is the ADC output.

The clock rate is equal to the inverse of the conversion time, and
the monotonicity is set by the accuracy with which you specify the
weighting of the current sources. The conversion glitches can
be introduced by bending the response times of the various latch
elements.

Hope this helps.

-- 
Best regards,
Mark 
                           
 ------------------------------------------------------------------------------
 Mark Sitkowski
笑比哭好!
 Australian Computing and Communications Institute
 723 Swanston Street
 Carlton Victoria 3053
 ------------------------------------------------------------------------------
 Phone: (613-9) 282-2530    E-mail: marks@acci.com.au
 Fax:   (613-9) 282-2534    WWW:
http://www.acci.com.au/People/marks.html

 Home phone: (613-9) 729-0731
给我打电话!
 Home fax:   (613-9) 720-1487
 ------------------------------------------------------------------------------
Article: 3660
Subject: Re: Using MAX+plusII under UNIX
From: pfile@flanker.eng.sun.com (Rob Pfile)
Date: 10 Jul 1996 01:35:45 GMT
Links: << >>  << T >>  << A >>
In article <31DA0270.41C67EA6@eede.ericsson.se> Andreas Hofmann <eedanho@eede.ericsson.se> writes:

> There seems to be some problems with the implementation of their user
> interface. I couldn't see the problem you described, but I have a nice
> oddity, too. If I try to get the online help from the menu HELP the 
> message appears:

[help won't come up]

I get the same message occasionally. IMHO the new user interface
sucks. I think it's actually from another company so we can't really
blame Altera too much. I'm sure it makes their job easier, and it
makes it easier for them to keep the PC version in line with the UNIX
version (which at 5.1 was missing a whole lot of stuff that was in the
PC version).

If the people that write the "Windows-Under-X" code would get their
act together it would be OK. As it is you have to run another program
to reserve enough colors for the app (i guess they never heard of
private colormaps) and of course it doesnt understand my virtual
windowmanager (FVWM), so it's always stuck to the glass, which is
pretty annoying. And when iconified it doesnt follow the rules either.

However, I love MaxPlus2 6.x.

rob
not speaking for Sun

Article: 3661
Subject: Re: Using MAX+plusII under UNIX
From: Andreas Hofmann <eedanho@eede.ericsson.se>
Date: Wed, 10 Jul 1996 07:07:38 +0200
Links: << >>  << T >>  << A >>
> If the people that write the "Windows-Under-X" code would get their
> act together it would be OK. As it is you have to run another program
> to reserve enough colors for the app (i guess they never heard of
> private colormaps) and of course it doesnt understand my virtual
> windowmanager (FVWM), so it's always stuck to the glass, which is
> pretty annoying. And when iconified it doesnt follow the rules either.
> 
> However, I love MaxPlus2 6.x.


You're speaking from the bottom of one's heard! Even if I've accepted
lot's of this oddities now, I expect them to improve their user interface
soon. It would make the live of a designer much less boring if you don't
have to fight against a strange behaving application on your desktop
(speaking from the X point of view). Let's see! This morning I've found
the Rev. 6.2 on my desk. I'll be back with comments when I've installed
it. Otherwise let's wait until Rev. 7.x?
-- 
   _/ _/ _/  EED/E/X/A/ Andreas Hofmann    Phone :+49-5121-707-378
  _/ _/ _/   Ericsson Eurolab Deutschland  FAX   :+49-5121-707-333
 _/ _/ _/    Daimlerring 9                 Memo	 :EED.EEDANHO
_/ _/ _/     31135 Hildesheim - Germany    mailto:eedanho@eede.ericsson.se
Article: 3662
Subject: Q:Veribest and Xilinx netlist.
From: Per Bjureus <pebj@celsiustech.se>
Date: 10 Jul 1996 12:19:16 GMT
Links: << >>  << T >>  << A >>
Hi there!

I've got a problem generating a
Xilinx netlist (.xnf) with physical pin assignments from my
Veribest design capture (.sbk) schematic using
Veribest synthesis capture.

What I want:
Is a .xnf-file with the LOC property on the EXT signals, e.g.
EXT,IN,I,,LOC=P46

What I've tried:
In the top level design, I have assigned a hierarchical pin the
"hier pin name" property, e.g. "IN". Connected to each pin is a wire
which has the "Net name" property set to exactly the same name i.e. "IN".
In addition to this the wire has the "LOC" property set to a pin number
e.g. "P46".
Next I synthesize the design using the Veribest synthesis capture and
then I try to export the project to Xilinx format using the 3164APC84-3
device.

What I get:
Is a .xnf-file where everything seems right except that the LOC parameter
is missing on the EXT signals e.g.
EXT,IN,I

What now?
I've read all the manuals I've got, I've talked to all my friends, I've
called the Veribest hot-line, I try very hard not to go berserk.

Please, if you have any suggestions, mail me.

/Per


Article: 3663
Subject: Re: ANNOUNCE: New Model of the Month - 16 bit ADC
From: ft63@dial.pipex.com (Peter)
Date: Wed, 10 Jul 1996 13:28:50 GMT
Links: << >>  << T >>  << A >>

>I've been making SPICE models of ADC's that way for years - and teaching
>others how to do it in my modelling training courses. The question of
>calibration never arises, since the capacitors can have any tolerance
>you care to specify. Nope, he's telling you the truth. 

Mark,

I would certainly like to know how to make a 16-bit ADC using
non-precise caps, with no calibration required. I am probably too far
away geographically to join your class :)

Peter.
Article: 3664
Subject: FPGA'97: Call for Papers
From: hauck@eecs.nwu.edu (Scott A. Hauck)
Date: Wed, 10 Jul 1996 10:07:25 -0500
Links: << >>  << T >>  << A >>
1997 ACM/SIGDA Fifth International Symposium on
Field-Programmable Gate Arrays

Sponsored by ACM SIGDA, with support from Altera, Xilinx, and Actel

Monterey Beach Hotel, Monterey, California
February 9-11, 1997
(Web page: http://www.ece.nwu.edu/~hauck/fpga97)

The annual ACM/SIGDA International Symposium on Field-Programmable Gate Arrays
is the premier conference for presentation of advances in all areas
related to the FPGA technology.  The topics of interest of this symposium
include, but are not limited to:

o Advances in FPGA architectures, including design of programmable logic blocks,
    programmable interconnects, programmable I/Os, and development of new
    FPGAs and field-configurable memories.

o New CAD algorithms and tools for FPGAs,  including new algorithms for
    sequential and combinational logic optimization, technology mapping,
    partitioning, placement, routing, and development of new FPGA synthesis or
    layout systems.

o Novel applications of FPGAs, including rapid prototyping, logic emulation,
    reconfigurable custom computing, and dynamically reconfigurable
    applications.

o Advances in field-programmable technology, including new process
    and fabrication technologies, and field-programmable analog arrays.

Authors should submit 20 copies of their original work by September 27, 1996.
Each submission should include an 100-250 words abstract, and is limited
in length to 12 pages (including figures and tables, minimum point size 10).
Notification of acceptance will be sent by November 18, 1996.
A proceedings of accepted paper will be published by ACM.
Authors must assign copyright of their accepted papers to ACM as a condition
of publication. Final versions of accepted papers will be limited
to seven pages, and must be submitted by December 6, 1996.
All submissions should include the e.mail addresses of the authors, as all
correspondence with authors will be done via e.mail.

Submissions should be sent to:

Prof. Jason Cong
FPGA'97 Program Chair
UCLA Computer Science Department
4711 Boelter Hall
Los Angeles, CA 90095
Phone: (310) 206-2775,  Fax: (310) 825-2273, E.mail:  fpga97@cs.ucla.edu

Organizing Committee:

General Chair:    Carl Ebeling, University of Washington
Program Chair:    Jason Cong, UCLA
Publicity Chair:  Scott Hauck, Northwestern University
Finance Chair:    Jonathan Rose, University of Toronto
Local Chair:      Pak Chan, UC Santa Cruz

Program Committee:

Michael Butts           Quickturn
Pak Chan                UCSC
Jason Cong              UCLA
Carl Ebeling            U. Washington
Masahiro Fujita         Fujitsu Labs
Scott Hauck             Northwestern Univ.
Dwight Hill             Synopsys
Brad Hutchings          BYU
Sinan Kaptanoglu        Actel
David Lewis             U. Toronto
Jonathan Rose           U. Toronto
Richard Rudell          Synopsys
Rob Rutenbar            CMU
Gabriele Saucier        Imag
Martine Schlag          UCSC
Tim Southgate           Altera
Steve Trimberger        Xilinx
Martin Wong             UT Austin
Nam-Sung Woo            Lucent Technologies
+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
|               Scott A. Hauck, Assistant Professor                         |
|  Dept. of ECE                        Voice: (847) 467-1849                |
|  Northwestern University             FAX: (847) 467-4144                  |
|  2145 Sheridan Road                  Email: hauck@ece.nwu.edu             |
|  Evanston, IL  60208                 WWW: http://www.ece.nwu.edu/~hauck   |
+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
Article: 3665
Subject: FPGA - RAM interfacing
From: sjba@ukc.ac.uk (S.J.B.Acock)
Date: Wed, 10 Jul 96 16:13:38 GMT
Links: << >>  << T >>  << A >>

I would be interested to hear from anyone who has interfaced a Xilinx 4000
FPGA with a static RAM chip. My problem lies with creating bidirectional
tri-state buffers in the FPGA to access the RAM data bus. I am creating 
designs using behavioural VHDL and the Synopsys Design Analyzer to create
a Xilinx netlist.

Many thanks for any advice !

Regards,

Steven Acock

Department of Electronic Engineering,
University of Kent,
Canterbury,
Kent,
United Kingdom

sjba@ukc.ac.uk


Article: 3666
Subject: Re: emulation software
From: Oliver Paray <scrhacfuji@aol.com>
Date: Wed, 10 Jul 1996 17:49:25 +0100
Links: << >>  << T >>  << A >>
If you are using a mac, a good freeware logic emulator (circuit design 
software is called "DigSim"). The program has the ability to use 
circuits which you have already designed as sub-circuits for your new 
designs. It comes complete with all the usual gates (AND,NAND,OR,XOR) 
plus it even has flip flops and adders/subtracters. 

You can find the program in the following ftp sites:

ftp.umich.edu
ftp.info.apple.com
Article: 3667
Subject: Re: FPGA - RAM interfacing
From: acher@informatik.tu-muenchen.de (Georg Acher)
Date: 10 Jul 1996 17:20:26 GMT
Links: << >>  << T >>  << A >>

In article <13472@eagle.ukc.ac.uk>, sjba@ukc.ac.uk (S.J.B.Acock) writes:
|> 
|> I would be interested to hear from anyone who has interfaced a Xilinx 4000
|> FPGA with a static RAM chip. My problem lies with creating bidirectional
|> tri-state buffers in the FPGA to access the RAM data bus. I am creating 
|> designs using behavioural VHDL and the Synopsys Design Analyzer to create
|> a Xilinx netlist.

I've done that, in theory, it's simple. Declare the data-bus as inout:
...
	data	: inout STD_LOGIC_VECTOR(7 downto 0);

Then you can get the data from the RAM via 'data'. To put internal values on the
data-bus, use something like

	data<= internal_data when output_enable='0' else "ZZZZZZZZ";

This infers 8 OBUFTs with lowactive enable (that's a primitive).
That's how it should work... But there seems to be bug in Synopsys (3.3b), that
frequently causes crashes at 'insert_pads' at inout-pins. That doesn't happen,
if you instantiate the IBUF/OBUFT/OFD etc. manually and exclude them from the
port_is_pad-attribute.
-- 
	Bye
	Georg Acher
+--------------------------------------------------------------+
|         Georg Acher, acher@informatik.tu-muenchen.de         |
|           "Oh no, not again !" The bowl of petunias          |
+--------------------------------------------------------------+
Article: 3668
Subject: Their Own Words: Cadence vs. Avant! (Avant!'s Court Filings 1/3)
From: jcooley@world.std.com (John Cooley)
Date: Wed, 10 Jul 1996 18:25:22 GMT
Links: << >>  << T >>  << A >>
     A number of users have asked me to seek out the Avant! court filing
     (instead of just the Avant! press release) so they could judge for
     themselves what was going on.  Here it is in its gory detail!

                                             - John Cooley

  Avant!'s Court Filing (part 1 of 3)

--------------------------



	INTRODUCTION
	Cadence asks this Court to enjoin Avant!'s sale of highly 
sophisticated, break-through technology that is used by every major 
computer chip manufacturer in the world and which is clearly superior 
to Cadence's products.  The motion should be denied because no Avant! 
product infringes any Cadence copyright or contains any Cadence trade 
secret.
	Cadence's copyright claims are based on allegations that Avant! 
has copied certain low level code from old database, graphic 
utilities and related software.  Cadence's experts can identify only 
a handful of the alleged similarities, and they admit they have not 
made the findings necessary to support a claim of copyright 
infringement.  This low level code, moreover, is covered by a 1994 
settlement agreement that released all claims against Avant!.  
Nevertheless, to avoid any challenge to the code containing these 
similarities, Avant! has removed it from its products and replaced it 
with code developed in a clean room.
	Aware that the similarities were found in low level code covered 
by the release, Cadence has tried to make it appear to the Court, 
customers and investors that Avant!'s products contain place and 
route code allegedly stolen by former Cadence employee Mitsuru Igusa. 
 This is absolutely untrue.  No Avant! product uses code that is 
linked in any way to Mitsuru Igusa.  Cadence's reliance on cloak-and-
dagger melodrama cannot change this essential fact.
	Unable to support its copyright case, Cadence is relegated to 
charging that Avant!'s place and route software is "derived" from 
Cadence trade secrets.  This, too, is untrue.  Cadence's analysis and 
conclusions are contradicted by nationally recognized experts.  In 
scattergun fashion, Cadence claims as trade secrets various 
algorithms, techniques and methods that are the subject of hundreds 
of published papers and books -- a vast literature that Cadence's 
experts never examined.  Cadence's experts instead base their 
opinions on demonstrably false assumptions about the structure and 
content of Avant!'s code, claiming similarities that simply do not 
exist.  Cadence, moreover, ignores completely the overwhelming 
evidence of Avant!'s independent development of its place and route 
software, a detailed record of hard work and creativity.  Incredibly, 
Cadence's experts reached their conclusions without even reviewing 
the overwhelming evidence of independent development by Avant! 
engineers.  
	Finally, Cadence impermissibly delayed in bringing this lawsuit. 
 Such a delay vitiates Cadence's claim of irreparable harm and 
sharply tips the balance of hardships in Avant!'s favor.  	Cadence 
argues that this case is like no other in Silicon Valley history.  
Just the opposite is true; this case is like many others where a 
large company grows complacent and finds its technology surpassed by 
a new, smaller company staffed in part by former employees.  Unable 
to win in the marketplace, the larger company resorts to litigation 
and smear tactics.  When the Court cuts through Cadence's 
misdirection and innuendo, it will conclude that the preliminary 
injunction motion must be denied.
	STATEMENT OF FACTS

I. 	AVANT!'S ENGINEERS AND PRODUCTS 
	Avant!'s two main product lines are place and route software and 
verification software.  Place and route software is crucial to 
manufacturers of integrated circuits ("ICs" or "chips").  This 
software enables designers to place and connect (or "route") millions 
of microscopic circuit elements on a chip.   Verification programs 
test whether the design works as planned.  
	With the advent of submicron and deep submicron technology, IC 
manufacturers are designing increasingly smaller, faster and more 
complex chips.   Traditional physical design software, based on 
technology developed 7 to 12 years ago, cannot meet these new 
challenges.  Manufacturers are demanding more sophisticated tools to 
survive in extremely competitive markets.  Avant!'s products were 
designed to meet these demands.
	Cadence's depiction of Avant! as a group of conspirators selling 
stolen technology could not be further from the truth.  Avant!, which 
has 215 employees, dedicates a large portion of its annual budget to 
R&D and employs some of the world's most talented place and route 
specialists.  Almost three-quarters of the 48 engineers and 
scientists working on its place and route tools have Ph.D.s.  In all, 
Avant!'s research teams include 37 Ph.D.s, and Avant!'s engineers and 
scientists have published more than 200 technical papers.

II. 	THE UNDISPUTED SUPERIORITY OF AVANT!'S PRODUCTS.
	Cadence is Avant!'s main competitor in place and route and 
verification software.  Cadence is older and much larger, with 1995 
annual revenue of over $540 million, compared to Avant!'s revenue of 
$38 million.  Avant!'s place and route products are known as ArcGate, 
ArcCell and ArcCell-XO.  ArcCell enables the design of deep submicron 
cell-based ICs.  ArcCell-XO is an upgrade, extending ArcCell to the 
most complex, high performance IC designs.  Cadence's place and route 
products include Cell Ensemble, Cell3 Ensemble and Gate Ensemble.  
ArcCell and ArcCell-XO compete directly with Cadence's Cell Ensemble 
and Cell3 Ensemble, while ArcGate competes directly with Cadence's 
Gate Ensemble.
	Avant!'s place and route software frequently competes head-to-
head with Cadence's products (principally Cell3 Ensemble).  
Typically, a customer finds that the Cadence product cannot produce a 
layout from a certain design or that the resulting layout will make 
the chip's size (known as the "die size") too large.  The customer 
then asks Avant! to run its software with the same design to see if 
it will produce an efficient layout and smaller die size. 
	Avant! has identified 86 such head-to-head competitions in the 
past few years.  Avant!'s software produced a smaller die size in 74 
of the 83 instances where the customer could obtain results from the 
Cadence product.  On average, the Avant! tool produced die about 13% 
smaller than the Cadence package.  These results are significant:  a 
10% reduction in die size can produce a 20% or greater reduction in 
per-die production costs.
	The outcomes of these competitions have translated into sales.  
 Industry analyst Wessels, Arnold & Henderson reports that Avant!'s 
share of the 1995 deep submicron market exceeded Cadence's share by 
23.3% to 18%.  Wessels confirms that the deep submicron market is the 
future for IC physical design products, projecting 36% annual growth 
rates.  Wessels predicts that Avant!'s share of this market in the 
year 2000 will exceed Cadence's share by 33% to 12%.
	ARGUMENT



III. CADENCE'S CLAIMS CAN BE DIVIDED INTO CLAIMS REGARDING CODE 
CREATED BEFORE AND AFTER THE RELEASE.


	The Avant! products that Cadence asks this Court to enjoin are 
massive, extraordinarily complex computer programs.  ArcCell consists 
of 1,454,338 lines of code organized into 2,260 files.  (C. H. Chang 
Decl. & 14.)  ArcCell-XO comprises 1,241,357 lines organized into 
2,048 files.  (Id. & 13.)  Cadence's motion is devoid of any effort 
to specify what claims apply to which parts of this immense body of 
code.   
	On February 21, 1996, Magistrate Judge Trumbull ordered Cadence 
to identify the Avant! code that represents trade secret 
misappropriation or copyright infringement.  (Snyder Decl. & 4; Exh. 
C.)  Cadence ultimately produced a list of 117 files.  Attached 
hereto as Exhibit A is a chart listing the 117 Avant! files with the 
corresponding Cadence files.  For the Court's convenience, the chart 
is color coded.  Files created before the May 6, 1994 Confidential 
Settlement Agreement ("Release") are designated in blue.  This code 
("Pre-Release Code") is used in ArcCell and ArcCell-XO.  Files 
created after the Release date are designated in green.  These files 
("Post-Release Code") are used only in ArcCell-XO.  Files that are 
not used in any Avant! product have no color designation.  The chart 
also designates which Avant! expert will testify on each file.
	The chart serves as an outline of Avant!'s defenses to Cadence's 
claims.  With regard to Pre-Release Code, the Release bars all 
claims, including claims for equitable relief, based on Avant!'s 
continued use of any Cadence code or trade secrets found in those 
files.  All Pre-Release Code containing questionable similarities, 
moreover, has been removed from Avant!'s products and the functions 
replaced with code written in a clean room.
	With regard to Post-Release Code, Cadence's claims relate to 
trade secret misappropriation.  As detailed below, the alleged trade 
secrets are either in the public domain or they are not found in 
Avant!'s products.  Moreover, overwhelming evidence shows that all of 
these Avant! files were independently developed.
IV. CADENCE IS NOT ENTITLED TO A PRELIMINARY INJUNCTION BASED ON 
CODE CREATED BEFORE THE RELEASE.

A. Cadence Released All Claims To Enjoin Avant!'s Continued 
Use Of Cadence Source Code And Trade Secrets Allegedly 
Acquired Before The Release.

1. The 1994 Release Of Injunction Claims.
	
	In early 1994, Cadence threatened to sue Avant! and its current 
president, Gerry Hsu, for trade secret theft after Hsu announced his 
intention to leave Cadence to join Avant!.  After weeks of intensive 
negotiations, the parties entered into a Confidential Settlement 
Agreement ("Release") on June 6, 1994.  (Brill Decl. && 2, 21.)   By 
the terms of the Release, the parties agreed to forever release and 
discharge each other from any claim 

		which they may have against each other at the 
time of the execution of this Agreement, known or 
unknown, including but not limited to any claims 
arising out of, or in connection with, or 
relating directly or indirectly to . . . any 
anticompetitive activity or unfair competition or 
trade secret misappropriation by Cadence, Hsu or 
ArcSys with respect to Cadence, Hsu or ArcSys . . 
. ."


(Release at 8, & H(1) (emphasis added).)   As the circumstances 
surrounding the settlement demonstrate, the Release discharged all of 
Cadence's claims to enjoin Avant!'s continued use in its products of 
any Cadence source code and trade secrets acquired before the 
Release.
	In the negotiations leading up to the Release, Cadence 
threatened to enjoin the sale of Avant! products that Cadence 
believed contained stolen intellectual property.  (Brill Dep. 137:2-
21, 138:6-24, 150:24-151:17; Brill Decl. && 7-15; Kagle Decl. & 5.)   
Cadence threatened to sue if an acceptable settlement could not be 
reached and provided Avant! the complaint it intended to file.  
(Brill Decl. && 7-9, 16; Kagle Decl. & 5; Healy Dep. 52:10-54:21, 
69:6-15; Sherwood Dep. 52:3-17, 53:11-24.)  
	Cadence's complaint alleged that Avant! was formed by Cadence 
employees who "had access to and had assisted in developing Cadence 
Software Products."  (Complaint & 7.)   These individuals allegedly 
used Cadence's trade secrets -- broadly defined to include "Cadence 
software systems and all related confidential materials" -- to 
"develop ArcCell and other products. . . ."  (Id. && 29-32; Brill 
Dep. 116:10-117:1; Salmon Dep. 15:12-16:17, 19:16-21:2, 24:15-26:13.) 
 The complaint sought an injunction to prevent Avant! from "using, 
reproducing or disseminating" Cadence intellectual property in these 
products.  (Id. Prayer for Relief & 1, & 34; Brill Decl. && 14-15.)  
In a clear reference to the incorporation of misappropriated source 
code into Avant! products, Cadence requested a constructive trust 
requiring Avant! to hold in trust "all Cadence's trade secrets and 
confidential information and all resulting products and technologies 
containing same in whole or in part . . . ." (Complaint & 55) 
(emphasis added).
	Faced with threats to enjoin the sale of its products, Avant! 
entered into a settlement.  (Brill Decl. && 16-21; Kagle Decl. && 6-
7.)  In exchange, Cadence forever released its threatened claims to 
enjoin the continued sale of Avant!'s products containing or using 
Cadence software or other confidential materials allegedly acquired 
before the date of the Release.    
2. The Law Governing The Release.

	Ignoring the fact that it had specifically asserted and then 
released its claims to enjoin continued use of its software and 
confidential information, Cadence now insists that the Release only 
protected Avant!'s use of such material prior to the date of the 
Release.  (Br. 31-32.)  Under this view, Cadence was free to sue 
Avant! to enjoin the sale of its products the day after the Release 
was executed.  The law does not permit such an interpretation.
	Construing the Release to extinguish claims based on continuing 
use is the only reasonable interpretation.  See Kennewick Irrigation 
Dist. v. U.S., 880 F.2d 1018, 1032 (9th Cir. 1989).  At a minimum, 
Avant! bargained for an agreement to settle the claims framed by 
Cadence's 1994 complaint.  (Brill Dep. 73:15-76:2, 114:2-8, 118:3-
119:8, 123:19-124:14, 137:2-21, 138:6-24, 143:14-144:7; Kagle Dep. 
68:4-69:10; Healy Dep. 69:6-15; Brill Decl. & 19.)  The parties 
entered the agreement expressly to "avoid future disputes and 
disagreements" and accordingly discharged all "known and unknown" 
claims.  (Release at 8, & H(1).)  Thus, the Release was intended to 
permit Avant! to market its products free from injunction threats 
based on any pre-Release acquisition of confidential material.  
(Brill Dep. 137:2-21, 138:6-24; Kagle Decl. & 6; Brill Decl. && 26-
27; Salmon Dep. 75:3-17; Coxe Dep. 76:2-15.)  Interpreting the 
agreement to allow Cadence to reassert its injunction claims -- 
either the day after the Release was signed or today -- would 
eliminate the repose for which Avant! had bargained.  See Henning v. 
Kitchen Art Foods, Inc., 127 F. Supp 699, 702 (S.D. Ill. 1954) 
(holding that release precluded claim based on post-release use of 
the alleged trade secret).
	California law provides that a trade secret misappropriation 
claim arises only once, at the time of the initial misappropriation; 
successive uses of the information -- in this case the Pre-Release 
Code -- are part of that single claim.  See Cal. Civ. Code $ 3426.6; 
Whittaker Corp. v. Execuair Corp., 736 F.2d 1341, 1345 (9th Cir. 
1984) (quoting Monolith Portland Midwest Co. v. Kaiser Aluminum & 
Chem. Corp., 407 F.2d 288, 293 (9th Cir. 1969)) (holding that trade 
secret misappropriation "is not a continuing tort and that `[t]he 
cause of action arises but once'"); Ashton-Tate Corp. v. Ross, 916 
F.2d 516, 524 (9th Cir. 1990); Intermedics, Inc. v. Ventritex, Inc. 
("Intermedics II"), 822 F. Supp. 634, 657 (N.D. Cal. 1993).  Courts 
reason that successive uses constitute a single claim because the 
tort of misappropriation occurs only with the initial breach of 
confidence.  See Monolith, 407 F.2d at 293 (holding that "[t]he 
fabric of the relationship once rent is not torn anew with each added 
use or disclosure, although the damage suffered may thereby be 
aggravated") (emphasis added).  Once a trade secret owner releases a 
party from liability, any claim of continuing misappropriation is 
extinguished.
	The cases Cadence cites are irrelevant to both the plain meaning 
and interpretation of the Release under California law.  In Remington 
Rand Corp. v. Amsterdam-Rotterdam Bank, N.V., 68 F.3d 1478, 1483-85 
(2d Cir. 1995), the court determined the meaning of the disputed 
release pursuant to New York law.  New York courts endorse a 
"continuing tort" theory of trade secret misappropriation whereby 
each use of a trade secret creates a separate cause of action -- just 
the opposite of California law.  See Lemelson v. Carolina 
Enterprises, Inc., 541 F. Supp. 645, 659 (S.D.N.Y. 1982). 
	The result mandated by California law is also supported by the 
absence of any reservation of rights in the Release to enjoin future 
use of the allegedly acquired trade secrets.  Despite claiming at the 
time that Avant!'s trade secret use would continue unless enjoined, 
Cadence did not reserve the right to prosecute such future claims 
based on Avant!'s continuing use of Cadence software and confidential 
information.  See NTN Communications, Inc. v.
Interactive Network, Inc., 1993 WL 266663, at *4 (N.D. Cal. July 7, 
1993) (discussing comparable release in which patent holder declared 
"except that IGP reserves its prospective claims of infringement"), 
aff'd, 41 F.3d 1520 (Fed. Cir. 1994), cert. denied, 115 S.Ct. 2000 
(1995) ; Realex Chem. Corp. v. S.C. Johnson & Son, Inc., 849 F.2d 
299, 302 (8th Cir. 1988) (holding that party could have easily 
reserved copyright claim asserted); Monon Corp. v. Wabash Nat'l 
Corp., 780 F. Supp. 577, 583 (N.D. Ind. 1991) (ruling that party 
could have easily reserved patent claim asserted).
 	Until now, Cadence's conduct has been completely consistent with 
the interpretation that Avant! was released from all claims based on 
continued use of code and other confidential information acquired 
before the Release.   Despite the allegations in Cadence's 1994 
complaint, no one from Cadence asked Avant! to pull its products off 
the market after the Release was signed.  Nor did Cadence ever 
request Avant! to rewrite its source code to remove any Cadence 
confidential materials.  (Sherwood Dep. 173:13-175:1; Healy Dep. 
61:22-62:9; Brill Decl. & 26.)  The reason Cadence took no such 
actions is clear:  the Release discharged Cadence's claims against 
Avant!'s continued use in its products of the information allegedly 
acquired before the Release date.
Article: 3669
Subject: Their Own Words: Cadence vs. Avant! (Avant!'s Court Filings 2/3)
From: jcooley@world.std.com (John Cooley)
Date: Wed, 10 Jul 1996 18:27:11 GMT
Links: << >>  << T >>  << A >>
     A number of users have asked me to seek out the Avant! court filing
     (instead of just the Avant! press release) so they could judge for
     themselves what was going on.  Here it is in its gory detail!

                                             - John Cooley

  Avant!'s Court Filing (part 2 of 3)

--------------------------


	Cadence's attempt to revive its released claims by alleging 
copyright infringement is unavailing.  The Release bars all claims -- 
however styled -- to enjoin continued use of code and other 
confidential information acquired before the Release date.  Courts 
consistently resist efforts by plaintiffs to circumvent releases by 
reformulation of claims.  In Press Mach. Corp. v. Smith R.P.M. Corp., 
727 F.2d 781 (8th Cir. 1984), the court found that an agreement 
releasing a trade secret claim also barred patent claims based on 
subsequent use of the trade secrets, even though the release did not 
mention patent claims.  The court reasoned that permitting the patent 
claims would deny the defendant "the right to use the trade secrets 
and confidential information for which it had paid [and] would strip 
the agreement of much of its meaning."  Id. at 785; see also Realex, 
849 F.2d at 302 (interpreting settlement agreement to bar future 
copyright claims); Gallowhur Chem. v. Schwerdle, 37 N.J. Super. 385, 
117 A.2d 416 (1955).   
	In a decision barring a continuing use claim, Magistrate Judge 
Brazil emphasized the importance of repose as a matter of public 
policy and the danger of a plaintiff manipulating the definition of 
its trade secrets in an attempt to assert fresh claims.  Intermedics 
II, 822 F. Supp. at 654-57.  The court explained:
		[The] facts of cutting edge technological life, to say 
nothing of the limitations of language generally, have 
the effect of giving the person asserting trade secret 
claims . . . very wide definitional latitude [and] 
considerable power to manipulate the articulation of 
claims for tactical purposes . . .

		[S]uch an approach would make it extremely 
difficult for persons who might be targets of 
trade secret litigation ever to achieve . . . 
repose . . .  [Repose is] characterized as a kind 
of confidence about legal circumstances that 
permits and encourages people to move forward 
energetically and boldly with new economic 
development, free from fear that the fruits of 
their labor will be stripped from them as a 
result of trade secret litigation.  The law's 
ability to provide people with that kind of 
confidence would be badly compromised if parties 
could escape [preclusion] by artful manipulation 
of the definitions of related trade secrets.  


Id. at 656.  Although the court was referring to the repose secured 
by the statute of limitations, the same policy applies here.  Avant! 
and Cadence executed the Release specifically to permit Avant! to 
move forward free of claims based on Avant!'s use in its business of 
Cadence trade secrets, which Cadence defined to include software and 
related confidential information.  Cadence cannot be allowed to 
escape the natural, foreseeable consequence of the Release through an 
"artful manipulation" of its claims or by an untenable distinction 
between Avant!'s use of the same material in products before and 
after the Release date.

B. Cadence's Experts Have Not Made The Findings Necessary To 
Support Claims Of Copyright Infringement Against Pre-
Release Code.
	Cadence experts Randall Davis and Margaret Johnson were assigned 
to review the files that make up the Pre-Release Code.  They did not 
analyze these files for evidence of trade secret misappropriation.  
(Kelly Decl. && 26-27.)  Instead, they limited their review to 
identifying "similarities" or "correspondences" between the Avant! 
and Cadence code.  (Davis Dep. 40:1-41:24; 139:2-14; Johnson Dep. 
126:24-127:19.)  To prevail in this motion on copyright grounds, 
Cadence must show a high likelihood that it will prove infringement. 
 The methodology and findings of Cadence's experts are flawed and 
cannot satisfy the standards imposed by law.
	As Cadence acknowledges, to establish infringement it must show 
that Avant! had access to its programs and that Avant!'s code is 
substantially similar to Cadence's copyrighted programs.  (Br. 27:14-
16.)  Cadence experts, however, did not perform the required 
analysis.  When asked: "Were you asked [by Cadence's lawyers] to do 
an analysis of substantial similarity as to any Avant! and Cadence 
Code?", Professor Davis replied:  "I don't recall that question being 
put to me."  (Davis Dep. 168:8-12.)  Dr. Johnson admitted that she 
did not analyze the significance of any similarities:  "I was merely 
asked to provide files where correspondences existed.  That's what I 
did."  (Johnson Dep. 127:2-6.)  Other than an 85 line "[  ]" file in 
Post-Release code that she incorrectly believed was copied (see 
footnote 11, infra), Dr. Johnson had no opinion about whether Avant! 
had copied any Cadence code.  (Johnson Dep. 133:12-15.)
	The actual work performed by these experts starkly contrasts 
with the sweeping conclusions Cadence attributes to them.  Cadence 
identified some 89 files in the database, graphics editor, human 
interface and related areas as allegedly containing copied code.  
(Exhibit B hereto lists these Pre-Release files and indicates which 
files were examined by Cadence's experts.)  Professor Davis and Dr. 
Johnson think they looked at about 54 of these files.  (Kelly Decl. & 
14.)  It is impossible to reconstruct their analysis; they did not 
even record what files were examined much less the results of their 
examination.  (Kelly Decl. & 15.)  Ultimately, they could only 
discuss similarities in 10 files.  (Kelly Decl. & 14.)
	Neither expert examined public domain or third party sources to 
determine if they accounted for the alleged similarities.  (Kelly 
Decl. && 19-24.)  Although he maintained that he eliminated the 
possibility that some similarities were the result of common 
programming practices or ideas, Professor Davis admitted that he did 
not understand even the rudimentary functionality of the code.  
(Davis Dep. 143:16-24.)  Dr. Johnson admitted that she did not 
consider the impact of common programming constraints.  (Johnson Dep. 
26:21-25.)  When provided with the source code from several Avant! 
files referred to in his declaration as containing "code copied from 
Cadence," Professor Davis could not identify evidence of copying.  
(Kelly Decl. && 16-17.)
	In short, Cadence has not provided this Court with the expert 
findings necessary to support an injunction on the ground that 
Avant!'s Pre-Release Code infringes Cadence code.

C. Any Code Containing Questionable Similarities Has Been 
Removed And Replaced With Code Written In A Clean Room. 

	Not only are Cadence's claims barred by the Release and 
unsupported by expert analysis, they are moot.  Any code on Cadence's 
target list containing questionable similarities has been eliminated 
from Avant!'s products.
	After Cadence produced its list of Avant! files, Avant!'s 
experts began a meticulous, line-by-line comparison of the Avant! 
code and the corresponding Cadence code.  Avant!'s expert, Professor 
John Kelly, was conservative in his approach.  Professor Kelly did 
not try to link similarities to third party or public domain sources. 
 If there was any doubt about code containing a questionable 
similarity, it was designated to be deleted or replaced with new 
code.  (Kelly Decl. && 28-32.)
	New code was written under exacting conditions in a clean room 
by engineers who had no access to Cadence or Avant! source code.  
(Case Decl. && 11-16; Tsou Decl. && 14-16; Liu Decl. && 12-14; Yang 
Decl. && 6-8; Liao Decl. && 6-8; Lo Decl. && 82-85.)  All information 
provided to the clean room engineers was rigorously screened and 
recorded by an independent engineer who acted as the "filter."  (Case 
Decl. && 12-19.)  The clean room engineers wrote the new code based 
entirely on their own knowledge and experience, certain designated 
public domain materials provided by the filter and specifications 
giving "only a basic English description of the higher level ideas 
that needed to be embodied in the new code."  (Case Decl. && 13-16.) 
 Professor Kelly has reviewed and approved the clean room protocol 
and the procedures by which the new code was integrated into Avant!'s 
existing programs.  (Kelly Decl. & 45-46.)  His declaration includes 
an exhibit detailing his analysis and designating which files have 
been deleted or replaced and which files were not changed because 
there was no evidence of questionable similarities. (For the Court's 
convenience, Exhibit C, attached hereto, is a chart summarizing these 
findings and describing the status of all 117 files on Cadence's 
list.)   
	Because Avant! has removed any questionable code, Cadence is not 
entitled to a preliminary injunction unless the resulting code is 
substantially similar to the Cadence code.  Computer Assoc. Int'l 
Inc. v. Altai, Inc., 775 F. Supp. 544, 561-62 (E.D.N.Y. 1991), aff'd 
in pertinent part, 982 F.2d 693 (2d Cir. 1992).  Professor Kelly has 
carefully reviewed the Avant! code that is the result of the deletion 
of old code and the integration of clean room code.  Professor 
Kelly's opinion is that the resulting code is not substantially 
similar to the corresponding Cadence code.  (Kelly Decl. & 47.)  
Thus, the clean room is yet another reason no injunction should issue 
based on Cadence's claims of similarities between its code and 
Avant!'s code.  Alexander & Alexander Consulting Group, Inc. v. W.F. 
Corroon Corp., 1995 WL 46373, at *7 (N.D.Cal. Jan. 23, 1995); 
Computer Assoc., 775 F. Supp. at 561-62.

V. CADENCE IS NOT ENTITLED TO A PRELIMINARY INJUNCTION BASED ON THE 
   POST-RELEASE CODE.

	Based on the alleged presence of Cadence trade secrets in the 
Post-Release Code, Cadence seeks to enjoin the sale of Avant!'s two 
premier place and route products.   To obtain an injunction, Cadence 
must show that Avant!'s current products use Cadence trade secrets.  
California Civil Code $ 3426.2.  As Cadence's experts discovered, 
ArcCell does not use any of the Post-Release Code.  (C. H. Chang 
Decl. && 16-20; Smith Decl. & 13, Exh. 12 (Navas Dep. 205:4-18, Exh. 
19).)  ArcCell-XO, as demonstrated below, contains no Cadence trade 
secrets.
	The Post-Release Code (designated in green on the chart in 
Exhibit A) covers three parts of Avant!'s ArcCell-XO place and route 
tool: global routing, detail routing and the Design Size Optimization 
program.   (C. H. Chang Decl. && 16-18.)  None of these Post-Release 
Files contains a Cadence trade secret.  A trade secret, by 
definition, must not be "generally known to the public or to other 
persons who can obtain economic value from its disclosure or use."  
California Civil Code $ 3426.1.  In contrast, "[i]nformation that is 
public knowledge or that is generally known in an industry cannot be 
a trade secret."  Ruckelshaus v. Monsanto Co., 467 U.S. 986, 104 
S.Ct. 2862, 2872 (1984).  Every "trade secret" claimed by Cadence is 
either not used in the Post-Release Files or is described in the 
public literature, and frequently both.
	The presence of Cadence's so-called "trade secrets" is so 
pervasive in public literature that Avant!'s experts have cited, 
merely as examples, hundreds of books and articles discussing in 
detail the allegedly misappropriated techniques.  Many of the 
features that Cadence claims as proprietary, moreover, were used by 
Avant! engineers while they were students.  Many of the techniques 
also appear in Avant!'s ArcGate product that Cadence has not 
challenged.  The routing code in ArcGate was written by engineers who 
never worked at Cadence and who never had access to Cadence code.  
(S. C. Chang Decl. && 1, 7, 10.)  These engineers employed techniques 
they learned in school, at previous employment, or developed at 
Avant!.
	The following discussion summarizes the independent sources for 
the claimed trade secrets and some of the major differences between 
the Avant! and Cadence programs.  For the Court's convenience the 
declarations of Professors Sarrafzadeh and Robins, Dr. Paul Lo, and 
Dr. Ping-San Tzeng address the issues in the same order presented 
below.  

A. Avant!'s Global Router Was Independently Developed And 
Contains No Cadence Trade Secrets.

	The global router in ArcCell-XO, known by its directory name 
[A], is the product of intense effort by an experienced and talented 
place and route engineer, Dr. Sheng Chung ("Paul") Lo.  It is not the 
result of software theft or trade secret misappropriation.  (Lo Decl. 
& 23.)  Dr. Lo contemporaneously documented his development of [A] in 
his lab notebook, weekly reports, thousands of pages of test results, 
archived copies of unused versions, and the line by line computer 
record of changes made to [A] after it had been checked in to 
Avant!'s software version control system.  This material confirms Dr. 
Lo's testimony regarding his independent development of [A].  (Lo 
Decl. && 14-47, Exhs. A-C.)  Incredibly, Cadence withheld this 
information from Steven Teig, the only Cadence expert to review this 
source code.  (Teig Dep. 352:14-353:10.)  Mr. Teig's failure to 
review the immense evidence of independent development is fatal to 
his conclusions.
	Avoiding the evidence confirming the code's independent 
creation, Cadence purports to identify certain "trade secrets" used 
by [A].  (Br. 24:7-18.) Yet Cadence and its experts do not present a 
clear or consistent statement of the trade secrets at issue.  To 
assist the Court's analysis of these issues and to insure that each 
of Cadence's baseless allegations receives a response, Avant! 
prepared the following comprehensive list of issues raised by 
Cadence:
		a	Using the [#1] algorithm
		a 	Using the [#1] algorithm in a [#2]               
		a	The " [#3]     algorithm"
		a	Using [#4]       global router
		a	[#5] 
		a	[#6]   in global routing
		a	An array of [#7]
		a	[#8]
		a	A certain [#9]                    function
		a	Nomenclature
		a	Net ordering
		a	[#10] 
		a	Removing violations

Each of these issues is separately addressed below.  In every 
instance, Cadence's experts are either mistaken about [A] or are 
describing a well-known technique.
	Using the [#1] Algorithm.  Even Cadence's Professor Sechen admits 
that both the [#1] algorithm and its use in global routing are in the 
public domain.  (Sechen Decl. & 37.)  Avant!'s experts agree.  
(Sarrafzadeh Decl. & 49; Robins Decl. && 21-34.)
	Using the [#1] Algorithm in a [#2] Maze.  Cadence claims that the use 
of [#2]           global routing is a trade secret, even while 
admitting that it is "common" in the related context of detailed 
routing.  (Sechen Decl. & 36.)  The logical use of [#2]             
routing in multi-layer designs, for both global and detailed routing, 
has been described in the literature and has been used for several 
years by Avant! in its ArcGate place and route tool (detailed 
routing).  (Sarrafzadeh Decl. && 53-54; Robins Decl. && 26-29; S. C. 
Chang Decl. & 17.)  Six years ago, Cadence touted its own Cell3 
Ensemble global router as including [#2]           global routing.  
(Robins Decl. & 28; Smith Decl. & 14, Exh. 13 (Nequist Dep. 78:25-
79:14, 90:19-91:25, Exh. 3).)  If it were ever a trade secret, it 
certainly is not one now.
	The [#3]       Algorithm".  Cadence claims great advantages to having 
[#3] 
aspects of its use of the [#1] algorithm.  (Teig Decl. & 35; Sechen 
Decl. & 39.)  This technique has been published.  (Robins Decl. & 
30.)  Although Cadence claims that Avant! uses this technique, 
Cadence's experts could not find it in the code.  (Teig Dep. 340:5-
341:23, 360:7-24; Sechen Dep. 188:17-20.)  The reason is simple: 
ArcCell-XO's global router does not use the alleged [#3]         .  
(Lo Decl. & 51; Sarrafzadeh Decl. && 56-58.)  The absence of 
[#3]         actually reflects a difference in the two global 
routers.
	Using an [#4]          Global Router.  Cadence also apparently claims 
that the combination of global routing approaches is unique to 
Cadence and constitutes a trade secret.  (Teig Decl. & 25; Sechen 
Decl. & 45.)  Dr. Lo decided on this combination of publicly 
documented approaches only after conducting numerous experiments and 
implementing what he believed would create the best program.  (Lo 
Decl. && 56-57.)  Cadence's experts, moreover, are apparently unaware 
that every aspect of the approach they describe has been published, 
separately and in combination.  (Sarrafzadeh Decl. && 59-60; Robins 
Decl. && 31-34.)
	[#5]        .  Cadence's Professor Sechen claims that storing wiring 
information in the form of a [#5] is unusual and assumes that, like 
Cadence, [A] uses the same approach. (Sechen Decl. & 42; Sechen Dep. 
193:13-194:7; Robins Decl. & 35.) Sechen is wrong:  [A] stores wiring 
information in the form of a [    ], the admittedly more common 
approach.  (Lo Decl.
& 58; Sarrafzadeh Decl. && 61-63.)  This differs entirely from the 
form used by Cadence.  (Teig Dep. 322:4-7; Vuong Dep. 47:6-12.)  
According to Cadence's corporate designee on the subject and Avant!'s 
experts, this difference affects every aspect of the companies' 
global routers.  (Vuong Dep. 86:10-14; Sarrafzadeh Decl. && 61-63; Lo 
Decl. && 28-29.)
	[#6]  in Global Routing.  Although Professor Sechen claims that 
"[t]he notion of using the so-called `[#6]   ' in global routing [is] 
not found in the published literature," (Sechen Decl. & 49), this 
standard approach has been published in several books and papers.  
(Sarrafzadeh Decl. & 65; Robins Decl. & 36.)  Dr. Lo, who wrote [A], 
and Dr. Tzeng, who wrote the ArcCell-XO detailed router, both learned 
this technique before working at Cadence.  (Lo Decl. & 59; Tzeng 
Decl. & 44.)  Avant! has also used this technique in its ArcGate 
product since 1992.  (Sarrafzadeh Decl. & 64; S. C. Chang Decl. 
& 20.)  Dr. Tzeng even published a paper using the idea in 1988.  
(Tzeng Decl. & 44, Exh. B.)
	Using an Array of [#7]                   .  Cadence claims that this 
basic method of storing data is a "proprietary technique."  (Teig 
Decl. & 39.)  This method, however, has been repeatedly published in 
the place and route field, as Cadence's Steven Teig ultimately 
admitted.  (Sarrafzadeh Decl. && 68-70; Robins Decl. & 38; Teig Dep. 
349:1-4.)  Dr. Lo learned this technique as an undergraduate (Lo 
Decl. & 61), and Avant! first used it in its ArcGate product long 
before the misappropriation alleged by Cadence.  (Lo Decl. & 61; S. 
C. Chang Decl. & 23.)
	Cadence also avoids disclosing that Cadence and Avant! implement the 
basic idea of a [#7]        differently.  Cadence uses an array of [ 
           ].  (Teig Dep. 350:2-25.)  Avant! uses a different data 
structure, an array of [            ], as Cadence's Steven Teig 
eventually realized.  (Teig Dep. 350:20-351:2; Lo Decl. & 62.)  
Again, Cadence's claim of similarity actually reveals a difference.
	[#8].  Cadence falsely claims that using "[#8]" "was invented by and 
is proprietary to Cadence."  (Teig Decl. & 43; Sechen Decl. & 41.)  
The author of [A], Dr. Lo, learned this technique as an 
undergraduate. (Lo Decl. & 65.)  Dr. Tzeng, who wrote the ArcCell-XO 
detail router, also learned this technique as a computer science 
student and incorporated it in precisely this context in the routing 
program written for his Ph.D. dissertation. (Tzeng Decl. & 71.)  This 
technique is so basic and obvious that it was "invented" by one-third 
of the students on a recent exam.  (Robins Decl. && 39-41; 
Sarrafzadeh Decl. && 72-73.)
	A Certain [#9]                            Function.  Cadence claims 
to use a "unique" method for estimating the distance to multiple 
targets in its application of the [#1] algorithm.       (Teig Decl. & 
46; Sechen Decl. & 46.)  This technique has been published.  
(Sarrafzadeh Decl.
&& 74-76; Robins Decl. && 42-44.)  Dr. Lo adopted it based on his 
non-Cadence experience and his recognition that a more accurate, but 
more complicated, approach would merely slow down the program.  (Lo 
Decl. && 66-68; Sechen Dep. 179:24-180:3.)  Confirming Dr. Lo's 
assessment, Avant!'s ArcGate tool has used this technique for years. 
 (S. C. Chang Decl. & 25.)

	Nomenclature.  The terms identified by Cadence as evidence of 
misappropriation are common in the literature and are used by Avant! 
in files unchallenged by Cadence.  (Robins Decl. && 46-50; 
Sarrafzadeh Decl. & 77; S. C. Chang Decl. && 26-27.)  Even Cadence's 
experts admitted that the terms "[    ]," "[  ]," "[  ]," "[   ]", "[ 
 ]" and "[      ]" are common in the literature. 
 (Teig Dep. 334:22-335; Sechen Dep. 206:19-207:6.) 
 The only terms which Cadence's experts consider to be an indicia of 
copying, "[         ]" and "[          ]," 
are not found in [A] or [B].(Sarrafzadeh Decl. & 77; Robins Decl. && 
51-52; Lo Decl. & 71.)
	Net Ordering.  Cadence's Professor Sechen and Avant!'s experts agree 
that ordering the nets for initial routing by some estimate of the [ 
                              ] is a standard technique.  (Sechen 
Dep. 202:6-16; Robins Decl. && 54-55.)  Cadence claims only that the 
formula it uses to estimate the [                         ] is a 
trade secret.  (Teig Decl. && 51-
52; Sechen Decl. & 48.)  Cadence is apparently unaware that its 
"secret" formula was published in Mathematics for Elementary School 
Teachers, and several papers on the subject of maze routing.  (Robins 
Decl. && 57-58; Sarrafzadeh Decl. & 80.)  Cadence is also incorrect 
that Avant! uses this formula.  In fact, Avant! uses a completely 
different formula.  (Sarrafzadeh Decl. && 80-82; Lo Decl. & 73.)  
Once again, examination of the so-called "similarity" reveals another 
difference.
	[#10]                         Routing.  [#10]                    
routing has been described 
in the literature for more than 20 years, including by Cadence.  
(Sarrafzadeh Decl. & 83; Robins Decl. && 59-63; Smith Decl. & 14, 
Exh. 13 (Nequist Dep. 78:25-79:14, Exh. 3 at 68).)  Professor Sechen 
admits that this technique is quite common in detailed routers; 
indeed, the detailed router for ArcCell-XO allows [#10]              
         routing, and ArcGate's detailed router has used this 
technique for several years.  (Sechen Dep. 189:22-190:7; Tzeng Decl. 
& 72; S. C. Chang Decl. & 28.)  Cadence apparently claims that this 
technique is a trade secret only in global routing.  (Teig Decl. & 
55; Sechen Dep. 190:8-19.)  Yet, the ArcCell-XO global router [A] 
does not allow [#10]                        routing.  (Sarrafzadeh 
Decl. & 85; Lo Decl. & 75.)  Again, the Cadence and Avant! products 
do not share this alleged similarity.
	Removing Violations.  According to Cadence, improving the results of 
global routing by using [                 ]  to remove violations is 
a trade secret.  (Sechen Decl. & 44.)  This is surprising, because 
the extensive literature on [                 ]  includes a book by 
one of Cadence's experts, Prof. Sechen, entitled "VLSI Placement and 
Global Routing Using Simulated



Annealing."  (Robins Decl. && 65-67; Sarrafzadeh Decl. & 86.)  In any 
event, Avant! does not 
use [                 ]  in global routing.  (Lo Decl. & 80; 
Sarrafzadeh Decl. & 90.)
	Of the dozen Cadence purported "trade secrets" allegedly found in 
[A], every one has been published.  At least half are not even found 
in [A].  Cadence's claims of similarity in these areas actually 
reveal fundamental differences in the structure and approach of the 
two programs.  (Sarrafzadeh Decl. && 91-96.)  Cadence has 
demonstrated no likelihood of proving that the ArcCell-XO global 
router contains any Cadence trade secrets.

B. Avant!'s Detailed Router Was Independently Developed And 
Contains No Cadence Trade Secrets.

	The ArcCell-XO detailed router, known by its directory name [B], is 
not the result of software or trade secret theft.  This code is the 
product of nearly a year of dedicated work by an engineer with a 
decade of experience in routing technologies, Dr. Ping-San Tzeng.  
Before receiving his Ph.D. in electrical engineering, Dr. Tzeng 
developed two place and route tools as part of his academic work.The 
code in [B] includes many of the techniques he developed while he was 
a student. Like his colleague Dr. Lo, Dr. Tzeng recorded his 
development of [B] in an original abstract description of the future 
router, a proposed schedule, weekly reports, archived copies of 
unused versions, and the line by line computer record of changes made 
to [B] after it had been checked in to Avant!'s version control 
system.  This material confirms Dr. Tzeng's independent development 
of [B].  (Tzeng Decl. && 17-40; Exhs. C-E.)
	Perhaps because of this compelling evidence, Cadence did not deign 
its claims regarding [B] to be worthy of more than one sentence in 
its brief.  (Br. 24:19-20.) Instead, Avant! and the Court are left to 
glean from the declarations of Steve Teig and Carl Sechen what 
supposed "trade secrets" are allegedly found in [B].  The following 
is a complete list of issues relating to [B]:
		a	[#6/ #11]
		a	[#12]
		a	[#13]
		a	[#14]
		a	[#15]
		a	[#16]
		a	[#17]
		a	[#8]
		a	[#10]

As in the case of the ArcCell-XO global router, each of these alleged 
similarities rests on either an incorrect description of Avant!'s [B] 
or on the common use of public domain programming techniques, many of 
which Dr. Tzeng had used in his own programs while still a student.
	[#6/#11]                .  Cadence claims that using a collection of 
[#6]                  to define the area (called a [#11]             
    ) in which detailed routing will be performed is a trade secret. 
 (Teig Decl. & 59-60; Sechen Decl. & 49.)  Not only has this 
technique been published (Robins Decl. && 70-71), Avant!'s ArcGate 
has used it since January 1993.
(S. C. Chang Decl. && 31-33; Sarrafzadeh & 101.)  Even earlier, Dr. 
Tzeng used this technique as a student and published a paper using 
the term "[#11]      ."  (Tzeng Decl. & 45, Exh. B.)
	[#12]                .  Cadence claims as trade secrets the process 
of searching for violations and defining a new region of [#6]    in 
which to correct them, as well as the term "[#12]            " to 
describe this process.  (Teig Decl. & 62; Sechen Decl. & 49.)  
Apparently unknown to Cadence's experts, a 1990 article describing 
Cell3 Ensemble referred to this technique by the name "[#12]         
   ."  (Smith Decl. & 14, Exh. 13 (Nequist Dep. 78:25-79:14, Exh. 3 
at 68); Robins Decl. && 73-75.)  Prior to 1990, Dr. Tzeng used this 
technique as a student, and Avant!'s ArcGate has used both this 
technique and the term "[#12]            " since 1993, well before 
the alleged misappropriation.  (Tzeng Decl. && 51-54; S. C. Chang 
Decl. & 34; Sarrafzadeh Decl. && 102-103.)
	[#13]                            .  Although Cadence claims that 
[#13]
                        was a Cadence trade secret (Teig Decl. & 63; 
Sechen & 43), an original author of Cadence's Gate Ensemble global 
and detailed routers admits that the idea was originally taken from 
the literature.  (Nequist Dep. 153:18-154:23.)  In 1990, Cadence 
described this feature in the public literature.  (Smith Decl. & 14, 
Exh. 13 (Nequist Dep. 78:25-79:14, Exh. 3 at 68).)  Several other 
papers address this subject, including a 1988 paper by Dr. Tzeng.  
(Sarrafzadeh Decl. & 104; Robins Decl. & 77; Tzeng Decl. & 55, Exh. A 
at 32.)  This concept is used by other routers, including ArcGate's 
detail router and programs written and studied by Dr. Tzeng in 
graduate school.  (Tzeng Decl. & 55; S. C. Chang Decl. & 35.)
	[#14]                 .  According to Cadence, allowing [#11]     to 
[#14]     is a proprietary technique.  (Teig Decl. & 66; Sechen & 
49.)  This trivial detail has appeared in the literature.  (Robins 
Decl. & 79.)  The idea has also been used for several years in the 
ArcGate detail router.  (Sarrafzadeh Decl. && 106-107; S. C. Chang 
Decl. && 36-40.)
	[#15]                                                      .  
Cadence's experts claim that the use of [ ]              in modern IC 
designs makes Avant!'s decision to use a [ ]             unusual.  
(Teig Decl. && 67-69; Sechen Decl. & 50.)  Most routers, however, use 
a [ ]      approach, including ArcGate.  (Sarrafzadeh Decl. & 109; 
Robins Decl. & 80; S. C. Chang Decl. && 41-44.)  Dr. Tzeng considered 
[ ]          in his Ph.D. dissertation and concluded that [ ]        
                        were superior.  (Tzeng Decl. & 60, Exh. B at 
55-57.)  All of the routers he has developed in his career have been 
[ ]       .  (Tzeng Decl. & 60.)  Dr. Tzeng, however, has created new 
techniques in [B] for handling [ ]          , techniques apparently 
unknown to Cadence.  (Tzeng Decl. & 62.)
	[#16]              .  Mr. Teig claims that Cadence and Avant! share a 
common bug as a result of using the [#1] algorithm and attempting to 
handle [#16]          .  (Teig Decl. && 70-72.)  Mr. Teig admits that 
this "bug" exists only if a router uses [#1].  (Teig Dep. 408:9-22.) 
 Significantly, [B] does not use [#1].  (Tzeng Decl. & 69; 
Sarrafzadeh Decl. & 113.)  Moreover, Dr. Tzeng invented a new 
approach for handling [#16]       for [B].  (Tzeng Decl. & 68.)  
Cadence has identified a bug in its own program that ArcCell-XO does 
not have.
	[#17]                .  Cadence's Mr. Teig also claims that Cadence 
and Avant! share a common bug related to the use of [#17]            
                                          to avoid violating certain 
design rules.  (Teig Decl. & 74-75.)  Avoiding such violations is a 
common problem in place and route generally and has been discussed 
repeatedly in the literature.  (Sarrafzadeh Decl. && 117-118; Robins 
Decl. & 85.)  Once again, however, Dr. Tzeng adopted a novel approach 
that avoids the most significant aspect of this problem.  (Tzeng 
Decl. & 70.)  The so-called "bug" is only in Cadence's code.
	[#8] and [#10]                                    .These issues as 
they relate to both global and detailed routing were discussed in the 
previous section on global routing.  Again, these are common 
programming techniques widely used in the field.  (Sarrafzadeh Decl. 
&& 119-120; Robins Decl. && 86-87.)
	As in the case of the global router, every one of the claimed "trade 
secrets" allegedly found in [B] has been published.  In asserting 
certain similarities, Cadence has repeatedly mischaracterized [B].  
Cadence's claims, when corrected, reveal differences in the programs. 
 Cadence has also ignored that [B] differs fundamentally from the 
Cadence detailed routers.  (Sarrafzadeh Decl. && 121-129.)  Cadence 
has demonstrated no likelihood of proving that the ArcCell-XO 
detailed router contains any Cadence trade secrets.

Article: 3670
Subject: Their Own Words: Cadence vs. Avant! (Avant!'s Court Filing 3/3)
From: jcooley@world.std.com (John Cooley)
Date: Wed, 10 Jul 1996 18:28:34 GMT
Links: << >>  << T >>  << A >>
     A number of users have asked me to seek out the Avant! court filing
     (instead of just the Avant! press release) so they could judge for
     themselves what was going on.  Here it is in its gory detail!

                                             - John Cooley

  Avant!'s Court Filing (part 3 of 3)

--------------------------


C. Avant!'s Design Size Optimization Program Was 
Independently Developed And Contains No Cadence Trade 
Secrets.

	The Design Size Optimization ("DSO") programs in ArcCell-XO and 
Cadence's VSize automate the process of establishing and adjusting 
die size.  VSize was written by Eric Cheng.  DSO (which includes the 
directory [  ]) was written by Eric Cheng and Dr. Venky Ramachandran. 
 (Ramachandran Decl. & 6.)  Before writing any source code, both Mr. 
Cheng and Dr. Ramachandran wrote proposals that were presented to the 
Avant! technical staff.  (Ramachandran Decl. && 11-14, Exhs. B-D.)  
After incorporating the comments of the Avant! technical staff, Mr. 
Cheng and Dr. Ramachandran began writing code.  (Ramachandran Decl. 
& 18.)  Over the next months they communicated regularly to improve 
the quality and features of DSO.  (Ramachandran Decl. && 19-25.)  As 
finally released to customers, DSO represents the collaboration over 
several months by its authors Mr. Cheng and Dr. Ramachandran.
	Cadence's trade secret claims with respect to DSO rest on the 
analysis of Dr. Johnson, who concludes that Avant! misappropriated 
"unique, proprietary trade secret algorithms and methods." (Johnson 
Decl. & 2.)  Professor Sechen offers some views on the alleged 
novelty of certain aspects of DSO, but he conceded that he relied on 
Dr. Johnson's examination of the code.  (Sechen Dep. 130:9-131:8.)  
This reliance was entirely misplaced.  Dr. Johnson admitted that she 
is not an expert in computer aided design, that she had never read a 
paper in the field, and that she had no familiarity at all with DSO's 
functionality, the data it used, or even the most basic concepts in 
place and route technology.  (Johnson Dep. 11:19-12:9, 20:22-21:4, 
22:14-23:2, 58:6-60:3, 59:1-4; 80:4-8; 119:2-8.)  Not surprisingly, 
Cadence's allegations of trade secret misappropriation with respect 
to DSO are entirely wrong.  All of Cadence's claims and Avant!'s 
expert rebuttals are summarized below.
	Implementing a [#18A] By [#18B]                                      
                                                    .  Dr. Johnson 
calls this a "very unusual approach in the field in general, and 
finding it in both systems is even more unusual."  (Johnson Decl. & 
15.)  When asked, however, Dr. Johnson could not explain the concept 
of a [#18A]                     and admitted that she had no 
knowledge of what approaches were usual or unusual in the field.  
(Johnson Dep. 20:19-23:2.)  As Professors Sarrafzadeh and Robins 
explain, the concept of an "inherently [#18B]                " is 
nonsensical:  all routers use a [ ]                                  
   during the routing process.  (Robins Decl. && 90-94; Sarrafzadeh 
Decl. && 133-136.)
	The common function of VSize and DSO is to automate the otherwise 
manual process of adjusting the size of the die in a fixed-die place 
and route tool.  (Robins Decl. && 97-98; Sechen Dep. 158:11-159:10.) 
 Cadence was not even the first to introduce this approach 
commercially.  (Robins Decl. & 99.)  This is not a novel approach for 
place and route tools and certainly does not constitute a trade 
secret.  (Robins Decl. & 99.)
	Although the authors and the general purpose overlap, VSize and DSO 
accomplish their tasks in different ways.  In the earliest stages of 
development, fundamental aspects of DSO were specified that would 
improve its utility to users and allow it to be used with more types 
of designs.  (Robins Decl. && 138-141; Ramachandran Decl. && 26-30.) 
 VSize shares none of these characteristics.  (Robins Decl. && 138-
141.)
	Use of [#19]          .  In her declaration, Dr. Johnson asserts that 
the use of [#19]                in the programs is "unique."  Under 
questioning, however, she admitted that she had no personal knowledge 
to support her conclusion.  (Johnson Dep. 27:1-9.)  In fact, [#19]   
       are common in computer science and particularly in place and 
route tools.  (Sechen Dep. 163:6-165:2; Robins Decl. && 101-107; 
Sarrafzadeh Decl. & 137.)  In both VSize and DSO, they are used to [ 
]                                                                 for 
the purpose of estimating the proper chip size.  Cadence's Professor 
Sechen and Avant!'s experts agree that this is a "standard use of 
[#19]         ."  (Sechen Dep. 166:25-167:2; Robins Decl. & 107.)  
Years before Cadence even began the VSize project, source code 
written at Avant! by Dr. Yang Cai, who never worked at Cadence, used 
[#19] in this very context.  (Cai Decl.
&& 7-8.)
	[#19]          Data Structures.  Dr. Johnson concludes that the 
similarity in the terms used in [#19]     data structures in VSize 
and [ ] is "beyond coincidence."  (Johnson Decl.
& 28.)  Dr. Johnson admitted, however, that she looked only for 
similarity, not its significance, and that she has no familiarity 
with the field and cannot say whether these terms reflect common 
usage.  (Johnson Dep. 58:20-25, 59:18-23.)  Indeed, the terms that 
she identified, such as        "[ ]," "[ ]," and "[ ]," are all 
common in this field.  (Robins Decl. & 110.)  Rather than "evidence 
of derivation," these similarities result from the same author 
writing code for a similar purpose at a different time without access 
to the original code.  (Robins Decl. && 109-111.)  Dr. Johnson 
admitted that this would explain all of the similarity she found.  
(Johnson Dep. 65:8-15, 66:3-14, 61:9-14, 81:11-20.)  Cadence withheld 
this information from Professor Sechen, who never even considered the 
possibility.  (Sechen Dep. 146:11-147:25; 168:9-169:5.)
	[#19]        Construction.  Again ignoring that the same author wrote 
both programs, Dr. Johnson questions the [ ]           way that VSize 
and DSO build [#19].           (Johnson Decl. && 33-34.)  Admitting 
that she did not even try to search the relevant literature, 
Dr. Johnson was unable to say whether or not this is the standard 
approach.  (Johnson Dep. 76:24-78:5.)  In fact, this is a standard 
way of building [ ], and a similarity that one would expect to find 
in code independently written by the same person at different times, 
as Dr. Johnson ultimately admitted.  (Robins Decl. && 113-114; 
Johnson Dep. 81:11-20.)
	The [#20]                    .  At her deposition, Dr. Johnson was 
asked to describe the [#20]                           .  Her reply 
was: "No, I can't."  She was asked whether she knew if any other 
commercial products used [#20].  Her answer was "No." When she was 
asked whether she made "any effort to find out," she again answered 
"No."  (Johnson Dep. 10:16-11:24.)  Nevertheless, in her declaration 
she confidently asserts that "the Cadence VSize and Avant! [ ] 
systems are unique in their use of the [#20]          ." (Johnson 
Decl. & 36.)    
	Professor Sechen and Avant!'s experts agree that [#20] has been 
widely discussed in the literature.  (Sechen Dep. 167:17-21; Robins 
Decl. & 116; Sarrafzadeh Decl. & 138.)  Cadence itself concluded that 
[#20] was in the public domain after Dr. Johnson inquired, but 
withheld this information from its own expert.  (Rogoyski Dep. 113:1-
11, 117:21-119:21.)
       Admitting that [#20] has been generally discussed, Professor 
Sechen questions its use in the context of [ ]                  in an 
integrated circuit design.  (Sechen Decl. & 32.)  As Professor Robins 
explains in detail, and Professor Sarrafzadeh confirms, [#20] has 
been frequently used in this context.  (Robins Decl. && 125-137; 
Sarrafzadeh Decl. & 138.)  Many of these implementations use [#19]   
       , as do both VSize and DSO.  (Robins Decl. && 127-132.)
	The foregoing demonstrates that many of the supposed "trade secrets" 
common to VSize and DSO have been published.  The remaining 
similarities merely result from the same engineer approaching a 
similar programming task at a different time.  None of these is 
evidence of misappropriation.  Cadence has demonstrated no likelihood 
that it will succeed in proving that the DSO program in ArcCell-XO 
contains any Cadence trade secrets.

VI. CADENCE'S INNUENDO REGARDING IGUSA DOES NOT SUPPORT ITS CLAIM 
FOR INJUNCTIVE RELIEF.  
A. The Code Related To Igusa Does Not Support Injunctive 
Relief.  
	In discovery, Avant! produced a diskette with a limited amount of 
code related to Igusa.  (Snyder Decl. & 2.)  These files, as 
identified on Cadence's list of 117, begin with the letters      "[ 
]" or "[ ]" and have no color designation on the chart in Exhibit A. 
 This code in no way supports Cadence's preliminary injunction 
motion.  First, neither this code nor any other code related to Igusa 
is, or ever has been, used in any Avant! product.  (C. H. Chang Decl. 
&& 19-20; Tsou Decl. & 18.)  Cadence's experts independently reached 
this conclusion, although Cadence did not disclose this fact to the 
Court.  (Smith Decl. & 13, Exh. 12 (Navas Dep. 199:12-23, 204:9-20, 
Exh. 16 ([ ]/ files), Exh. 18 ([ ]/ file)).)  Second, as Cadence's 
expert has now conceded, Cadence's assertion that the [ ]            
    code on the diskette contains Cadence code is simply wrong, as is 
Cadence's assertion that Igusa's trash contained "a printout of 
source code taken from Cadence's QplaceT product." (Br. 11:11-12, 
25:18-19.)  (Sechen Decl. & 69; Robins Decl. && 151-152.)  Third, the 
code demonstrates that Igusa was doing legitimate work unrelated to 
the code he allegedly took from Cadence.  (Robins Decl. && 151-152.) 
 When questioned, Professor Sechen admitted that every similarity he 
found would be explained by Igusa being the author of both sets of 
files.  (Sechen Dep. 226:8-13, 230:22-231:1, 234:15-23.)
B. Cadence Is Using Igusa To Divert Attention From The Fact 
That Avant!'s Products Contain No Infringing Code Or 
Misappropriated Trade Secrets.  


	To divert attention from the absence of evidence showing infringement 
or trade secret misappropriation by any Avant! product, Cadence 
attempts to construct an elaborate conspiracy among Avant! employees 
and Mitsuru Igusa.  Nothing Cadence alleges about Igusa can justify 
an injunction of Avant! products that do not infringe or 
misappropriate Cadence intellectual property.  More than that, 
Cadence's conspiracy theory is groundless.  
	One of the few things on which the parties in this case agree is that 
Mitsuru Igusa is a brilliant engineer.  Cadence CEO Joseph Costello 
describes Igusa as the best place and route engineer at Cadence.  
(Costello Dep. 67:6-18.)  Costello "made several extraordinary 
offers" to try to convince Igusa to stay at Cadence, including the 
opportunity for Igusa to define his own compensation package.  
(Costello Decl. & 5; Snyder Decl. & 3, Exh. B.)  Allegations of 
stolen code aside, any place and route company would jump at the 
chance to employ Igusa purely for his skills.   Igusa also is a 
friend of a number of Avant! employees.  (Hsu Decl. & 10.)  There is 
nothing surprising or improper about the fact that Avant! hoped that 
Igusa would come work at Avant! in 1995.  (Hsu Decl. & 10.)  Nor was 
there anything wrong with Avant! employees having contact with Igusa. 
 (Snyder Decl. & 3.)
	After the search of Igusa's home, members of Avant!'s Board of 
Directors concluded that it would not look right for Avant! to hire 
Igusa before the allegations against him were resolved.  The 
directors also believed (correctly, as this suit demonstrates) that 
Cadence would use any association between Igusa and Avant! as an 
excuse to sue Avant!.  (Kagle Decl. & 8.)  One of the issues 
discussed by Avant!'s board members in connection with hiring Igusa 
was the fact that Igusa faced financial pressures.  The directors 
concluded that, while Avant! should not hire Igusa, Igusa's friends 
at Avant! could assist him personally with their own funds if they 
wished.  Also present was Avant!'s corporate attorney from Brobeck, 
Phleger & Harrison.  (Kagle Decl. & 9; Hsu Decl. & 10; Spurlock Decl. 
& 3.)  
	Avant! employees Hsu, Cho, Wuu, Liao, and Huang discussed the 
possibility of investing in a venture with Igusa that would not 
involve Avant!.  Such an investment would both assist Igusa and carry 
through on earlier discussions among these Avant! employees about 
investing in a start-up company.  Avant!'s initial public offering in 
June 1995 generated hundreds of thousands of dollars of income for 
Cho, Wuu, and Liao, who each agreed with Hsu to contribute $50,000 as 
seed money for a start-up company.   In the meantime, they also 
agreed that some of this personal money could be used to assist Igusa 
and his family.  Shiao-Li ("Leigh") Huang agreed to collect and 
maintain the funds until something more formal was established.  (Hsu 
Decl. & 11; Cho Decl. && 10-11.)  On June 23, 1995, Leigh Huang spoke 
with a corporate attorney about funding a start-up company involving 
Mitsuru Igusa, with $50,000 initial investments from Hsu and Avant!'s 
founders.  (Brill Decl. & 32.)
	The Avant! employees did not set up a formal company, but there is 
nothing illicit about that.  To describe 1995 as frenetic for 
Avant!'s principals would be a vast understatement.  The company went 
public, went through a merger, and dramatically increased its sales 
and customer base.  Then the District Attorney's search, this 
lawsuit, and Cadence's smear campaign caused Avant!'s stock to lose 
half a billion dollars in value in a matter of days and compelled 
Avant!'s customers to reconsider their relationships.  Avant!'s 
principals have been working night and day, first to build and then 
to save their company.  Formalizing the structure of a possible 
start-up company was hardly a priority.  Nor did these four friends 
and close business associates feel any urgency to document their 
agreement.  (Hsu Decl. & 11; Cho Decl. & 11.)
	All of Cadence's "evidence" of a grand Igusa conspiracy is completely 
consistent with the explanation that the Avant! employees were doing 
no more than attempting to follow the board's decision that Avant! 
should not be associated with Igusa.  This simple explanation sharply 
contrasts with Cadence's convoluted conspiracy theory.   
VII. CADENCE CANNOT MEET THE REQUIREMENTS FOR PRELIMINARY INJUNCTIVE 
RELIEF.

A. Cadence Cannot Meet Its Burden Of Establishing Its 
Likelihood Of Success On The Merits. 

	A plaintiff's likelihood of success on the merits is the most 
important element of the Ninth Circuit's test for preliminary 
injunction.  RasterOps v. Radius, Inc., 861 F. Supp. 1479, 1482 (N.D. 
Cal. 1994).  As demonstrated above, Cadence will not succeed on the 
merits of its claims.  Moreover, any doubt regarding Cadence's 
likelihood of prevailing must result in the denial of its motion:
		"Probability of success" implies that the plaintiff 
must have a very clear and strong case.  Some 
courts have stated this in terms by the maxim 
that in considering preliminary injunction 
relief "to doubt is to deny."  That is, if there 
is doubt as to the probability of plaintiff's 
ultimate success on the merits, the preliminary 
injunction must be denied.


Direx Israel, Ltd. v. Breakthrough Medical Corp., 952 F.2d 802, 813 
(4th Cir. 1991) (citation omitted).
B. Cadence Cannot Establish Irreparable Harm.
	To obtain a preliminary injunction, regardless of the Ninth Circuit 
formulation applied, Cadence "must demonstrate that there exists a 
significant threat of irreparable injury."  Oakland Tribune, Inc. v. 
Chronicle Pub. Co., 762 F.2d 1374, 1376 (9th Cir. 1985).  Cadence 
cannot demonstrate irreparable harm.  First, the Pre-Release Code in 
dispute has been removed from Avant!'s products.  Second, Cadence's 
long delay in bringing this action belies its claim of irreparable 
harm relating to any post-Release misappropriation.  Finally, any 
harm resulting from such misappropriation is readily quantifiable and 
can be remedied through money damages.
1. Cadence Cannot Demonstrate Irreparable Harm From Any 
Pre-Release Misappropriation Because Avant! Has 
Removed All Such Code Through A Clean Room Process.
	Avant! has replaced the Pre-Release Code through a clean room 
process.  As a result, there can be no irreparable injury and an 
injunction is not appropriate.  Alexander & Alexander Consulting 
Group, Inc. v. W.F. Corroon Corp., 1995 WL 46373, at *7 (N.D. Cal. 
Jan. 23, 1995); accord, Kepner-Tregoe, Inc. v. Leadership Software, 
Inc., 12 F.3d 527, 538 (5th Cir.), cert. denied, 115 S.Ct. 82 (1994); 
Speech Technology Assocs. v. Adaptive Communication Systems, Inc., 
1994 U.S. Dist. LEXIS 11660, at *29 (N.D. Cal. Aug. 16, 1994) 
(quoting Cal. Civ. Code $ 3426.2); Computer Assoc., 775 F. Supp. at 
561-62; aff'd in pertinent part, 982 F.2d 693, 701 (2d Cir. 1992).

2. Cadence's Assertion Of Irreparable Harm Is 
Contradicted By Its Own Delay In Bringing Suit.
	A "[p]laintiff's long delay before seeking a preliminary injunction 
implies a lack of urgency and irreparable harm," and thereby negates 
the whole basis for injunctive relief -- the need for speedy action 
to protect the plaintiff's rights.  Oakland Tribune, 762 F.2d at 
1377; accord Ampex Corp. v. Abekas Video Sys., Inc., 1990 U.S. Dist. 
LEXIS 11309, at *14-*15, 15 U.S.P.Q.2d 1219 (BNA) (N.D. Cal. Feb. 7, 
1990).   
	Cadence knew that Eric Cheng moved from Cadence to Avant! in February 
1995 to work on a competing product.  (Given Dep. 112:14-117:1.)  
Cadence also knew in February 1995 that Cheng had made a copy of some 
of the source code at issue in this case.  (Woo Decl. && 2, 4-6, 8-
12.)  Cadence concedes that it learned no new facts about Cheng's 
alleged misappropriation prior to filing this lawsuit.  (Given Dep. 
120:21-121:11.)  Despite having in February 1995 the same evidence it 
now cites to establish misappropriation of its trade secrets, Cadence 
took no action.
	Courts routinely reject injunctive relief when faced with similar, 
and often shorter, delays.  Citibank, N.A. v. Citytrust, 756 F.2d 
273, 276 (2d Cir. 1985) (reversing injunction in trademark 
infringement action where plaintiff delayed ten weeks after it 
learned directly of defendant's plan to begin using allegedly 
infringing mark and more than nine months after it indirectly learned 
of such plans); Cuddle Wit, Inc. v. Chan, 1989 U.S. Dist. LEXIS 
14412, at *2, 14 U.S.P.Q.2d (BNA) 1572, Copyright L. Rep. (CCH) & 
26,507 (S.D.N.Y. Dec. 1, 1989) (seven-month delay in instituting 
copyright infringement action warranted denial of preliminary 
injunction); Business Trends Analysts v. Freedonia Group, Inc., 650 
F. Supp. 1452, 1459 (S.D.N.Y. 1987) (plaintiff's delay of at least 
six months before commencing action vitiated presumption of 
irreparable harm). 
3. 	The Harms Cadence Asserts Are Not Irreparable.
	Cadence concedes that its direct injuries resulting from lost sales 
of other products and services are quantifiable.  (Teece Decl. & 10-
11.)  It argues, however, that those lost revenues will produce more 
subtle impacts that are "less tangible" and "more difficult to 
monetize."  (Id. & 11).  Not only are the additional harms claimed by 
Cadence readily quantifiable, (Silverman Decl. && 20-34), they cannot 
constitute irreparable injury as a matter of law.  
	Cadence's argument that its lost sales inhibit its ability to 
reposition itself as a service-oriented company is speculative and 
does not constitute irreparable harm.  (Br. 34; Teece Decl. & 9(o)). 
 Goldie's Bookstore v. Superior Court of State of Cal., 739 F.2d 466, 
472 (9th Cir. 1984) (loss of "untold" customers too speculative); 
Bell Atl. Business Sys., Inc. v. Storage Technology Corp., 1994 U.S. 
Dist. LEXIS 4471, at *7-*9 (N.D. Cal. Mar. 31, 1994) (finding 
assertions that the moving party will have greater difficulty 
obtaining contracts in the future to be speculative); Brooktree Corp. 
v. Advanced Micro Devices, Inc., 705 F. Supp. 491, 493-96 (S.D. Cal. 
1988) (refusing to grant injunction based on "lost ability to expand 
or go public due to lost profits").  Cadence's own witness admits 
that it is too early to say whether there will be any effect on that 
aspect of its business.  (Douglas Dep. 104:9-105:4.)
	Cadence's assertion that loss of reputation due to lost sales is 
grounds for an injunction is erroneous.  (Teece Decl. & 9(h)).  See 
Los Angeles Memorial Coliseum Comm'n v. National Football League, 634 
F.2d 1197, 1202 (9th Cir. 1980); accord Virginia Carolina Tools, Inc. 
v. International Tool Supply, Inc., 984 F.2d 113, 120 (4th Cir. 
1992), cert. denied, 508 U.S. 960 (1993).  Nor, as Cadence's expert 
maintains (Teece Decl. & 9(g) and (l)), is diminished research and 
development due to lost profits an irreparable injury.  Eli Lilly and 
Co. v. American Cyanamid Co., 82 F.3d 1568, 1578 (Fed. Cir. 1996).  
Characterizing such collateral impacts as irreparable harm would 
improperly "convert the 'extraordinary' relief of a preliminary 
injunction into a standard remedy."  Id.
C. The Balance Of Hardships Overwhelmingly Favors Avant!.

	A critical consideration in granting an injunction is the relative 
hardship to the parties.  International Molders' and Allied Workers' 
Local Union No. 164 v. Nelson, 799 F.2d 547, 551 n.2 (9th Cir. 1986). 
 "Traditional standards for granting a preliminary injunction impose 
a duty on the court to balance the interests of all parties and weigh 
the damage to each."  
Los Angeles Memorial Coliseum Comm'n, 634 F.2d at 1203.
	In 1995, Cadence had revenues of over $540 million.  (Silverman Decl. 
& 10.)  Any harm to Cadence prior to a permanent injunction hearing 
can be compensated by monetary damages.  (Silverman Decl. && 18-34; 
Huyett Decl. & 2.)  On the other hand, a preliminary injunction would 
seriously harm Avant!, whose place and route products account for 
more than 60% of its income.  (Huyett Decl. & 3.)  Thus, the balance 
of hardships tips sharply in Avant!'s favor.  See Apple Barrel 
Productions, Inc. v. Beard, 730 F.2d 384, 390 (5th Cir. 1984); 
Farmers Indep. Tel. Co. v. Thorman, 648 F. Supp. 457, 459 (W.D. Wis. 
1986).  
	Injunctive relief is particularly inappropriate in this case because 
of the harm to Avant! caused by Cadence's delay.  Cadence filed its 
complaint as Avant! was about to release its next generation product, 
ArcCell-XO, on which Cheng had been working for most of 1995.  
(Jeong-Tyng Li Decl. & 22.)  Avant! invested tremendous time and 
resources in the development of ArcCell-XO while Cadence waited to 
sue, including eight man years of work from its most talented 
engineers.  (Hsu Decl. & 13.)
	Under similar circumstances, where the plaintiff had delayed until 
after defendant had printed 12,000 copies of a book, the court 
rejected injunctive relief stating "plaintiff must bear the 
consequences of its [strategic] delay."  New Era Publications Int'l, 
ApS v. Henry Holt & Co., 684 F. Supp. 808, 811 (S.D.N.Y. 1988), 
aff'd, 873 F.2d 576 (2d Cir. 1989).  This Court also has rejected 
preliminary injunctive relief where the defendant has invested 
substantial resources and developed a significant client base during 
the plaintiff's delay.
Integral Systems, Inc. v. PeopleSoft, Inc., 1991 U.S. Dist. LEXIS 
20878, at *53 (N.D. Cal. July 19, 1991). 

D. An Injunction Would Severely Harm Avant!'s Customers And 
The General Public.
	This Court also must consider the harmful effect that an injunction 
would have on third persons and on the general public.  Caribbean 
Marine Services Co. v. Baldrige, 844 F.2d 668, 674 (9th Cir. 1988).  
Enjoining Avant!'s ArcCell-XO -- indisputably the most advanced 
product in the field -- would seriously harm Avant! customers, which 
include every major chip maker in the world, and the public.  
(Eastman Decl. && 4, 8, 11, 15 & 19.)
	Avant!'s place and route products are essential to chip makers' 
producing better, more powerful ICs, faster and more efficiently.  
(Id.)  Place and route tools have fallen behind the technology curve, 
creating a bottleneck for many IC designers.  (Silverman Decl. & 16.) 
 The injunction Cadence seeks would seriously exacerbate this 
bottleneck.  An injunction also would extend Cadence's monopoly to 
upward of 80% of the place and route market and leave chip makers 
dependent on Cadence's outdated technology.  (Douglas Decl. & 19.)  
Given that applications employing ICs have expanded dramatically from 
their traditional uses in computers to telecommunications, 
multimedia, automotive, industrial automation, and consumer 
electronics industries, the public would suffer greatly if Avant!'s 
products are enjoined.  (Silverman Decl. & 16; Eastman Decl. & 6.) 
	 Courts are not hesitant to deny injunctive relief under such 
circumstances.  See Abend v. MCA, Inc., 863 F.2d 1465, 1479 (9th Cir. 
1988), cert. granted, 493 U.S. 807 (1989), aff'd 495 U.S. 207 (1990); 
Intel Corp. v. Advance Micro Devices, Inc., 1994 WL 621665, at *2 
(N.D. Cal. Oct. 31, 1990).  As Judge Lynch observed in denying a 
preliminary injunction, intellectual property law "must strike a 
balance between the broad monopoly power to exclude
. . . and the invariable need for competition in our free market 
economic system."  Ampex Corp. v. Abekas Video Systems, Inc., 1990 
U.S. Dist. LEXIS 11309, at *16-*17, 15 U.S.P.Q.2d 1219 (BNA) (N.D. 
Cal. Feb. 7, 1990).  Here, an injunction's harm to chip makers and 
the public can be avoided entirely given the adequacy of money 
damages.  
	CONCLUSION
	For the foregoing reasons, Avant! respectfully requests that the 
Court deny Cadence's Motion for Preliminary Injunction.  
Article: 3671
Subject: Re: FPGA capacity comparison
From: "J. Scott Dickson" <jsdickson@anet.rockwell.com>
Date: Wed, 10 Jul 1996 20:14:54 GMT
Links: << >>  << T >>  << A >>
Joey Y. Chen wrote:
> 
> Hi,
> 
>         Anyone of you out there had experience using both Xilinx and Altera
> FPGA's?  Since our Xilinx FPGA (XC4025E) order has been delayed yet again,
> I would like to know how the Altera Flex 10K series compares with the Xilinx
> XC4000E in terms of capacity.
>         The Xilinx XC4025E claims capacity of 25,000 "typical" gates, and
> the Altera Flex 10K-100 claims 100,000 "typical" gates.  Are they comparing
> the same thing here?
>         Thanks.
> 
> -Joey Chen

Basically, No.

We are currently doing a comparison of the XILINX 4025e vs. ALTERA 10K50.   
Altera computes the gate count as a function of the logic cells and the 
memory cells that are available in the 10K parts.  Altera publishes an 
app-note that describes how they compute gate count.  XILINX uses the 
standard gate count they have had for all of the XC4000 parts.

    - Scott
Article: 3672
Subject: Re: Xilinx Xc4000E Questions
From: Tom Burgess <tburgess@drao.nrc.ca>
Date: Wed, 10 Jul 1996 14:50:24 -0700
Links: << >>  << T >>  << A >>
David J. Matthews wrote:
> 
> Hi,
> 
> I am embarking on an XC4013E design and have a couple of questions...
> 
> 1.  I am bringing a bidirectional 32-bit bus into the device which
> essentially looks like a microprocessor bus.  It is used to load
> and read back registers, read back status, etc.<snip>

As you point out, there are tradeoffs. My larger 4000 designs
have all had a single wide read path(32 bit results) and a narrow write 
path(config & control), so I used a unidirectional internal tristate bus 
for the wide read data path, and muxes on the lower bits for register
readback. It is helpful not to need bus alignment for non-critical
control registers. I sometimes use a RAM block as a "register shadow RAM" 
to eliminate the need for a readback data path from non-volatile control 
registers.

> 
> 2.  The second question is regarding the preferred method for using
> the floor planner.  Is it better to floor plan before PPR or after?
> 

My experience with the XACT floorplanner is nonexistent, other than
running it once to look at the results of an unconstrained PPR run (not
pretty), but I would say floorplanning on a big, high-performance, 
high-utilization design should come very early, in fact during the
design feasibility stage.

Efficiently designing, placing, packing and aligning blocks on the CLB 
grid is not an easy problem. I prefer to do it myself with handmade RPMs 
and RLOC_ORIGINs at the schematic level, while I am designing the blocks, 
with occasional PPR runs to make sure things are still copacetic.
Not exactly a pushbutton design flow, but it gets the job done, with
fewer layers of design translation going on to confuse things, and
fewer pages in the "Known Issues" release document to search when
things go wrong. (grin)
	
		Best wishes - Tom
Article: 3673
Subject: WANTED:: Altera second source
From: GABBY SHPIRER <gabby@isv.dec.com>
Date: Thu, 11 Jul 1996 11:29:27 +0000
Links: << >>  << T >>  << A >>
Hello.
I'm not quite suttisfied from the israeli EastRonics Altera vendor
services and availiability, and since they are the only one in israel,
i'm searching for a second source of altera's chips e.g AT&T for Xilinx.

So please, if you know about it anything please remail me to:
mailto:gabby@isv.dec.com


-- 
[#]---[#]---[#]---[#]-<*>-<*>-<*>-<*>-<*>-[#]---[#]---[#]---[#]
                `\     /'
    0             \ 0 /                           Gabby Shpirer
  /[ ]\            [ ]        VLSI DEC site at Jerusalem Israel                    
 / [ ] \           [ ]                  email:gabby@isv.dec.com
   ---             ---                                         
 _/   \_         _/   \_            Opinions expressed are mine.

[#]---[#]---[#]---[#]-<*>-<*>-<*>-<*>-<*>-[#]---[#]---[#]---[#]
Article: 3674
Subject: What about the XC6200 ?
From: cgamrat@gaap.saclay.cea.fr (GAMRAT Christian)
Date: 11 Jul 1996 12:19:29 GMT
Links: << >>  << T >>  << A >>
Is There anybody out there who knows anything new about the Xilinx XC6200 
partially reconfigurable fpga ?
The data available from Xilinx has not changed for months and it looks like if they
are not pushing the device ahead anymore. 
I hope I'm wrong because this FPGA is a must in the field of reconfigurable 
computing. It will be really Dommage !
Thanks for any info on that .
Cheers,

Christian.


                                     (((((  
                                    (     )
                                   ( 0   0 )
                                    (  !  )
                                    | \_/ | 
 |------------------------------ooO---------Ooo-------------------------------|
 |   De/From Christian Gamrat (MIND-1024)                                     | 
 |   Commisariat a l'Energie Atomique / Atomic Energy Commission              |
 |   Groupe Architectures Paralleles  / Parallel Computing Group              |
 |   DTA/LETI/DEIN/SLA/GAP                                                    |
O|   CE-SACLAY  91191 Gif-sur-Yvette Cedex -  FRANCE                          |O
 |   e-mail : cgamrat@gaap.saclay.cea.fr                                      |
 |   phone  : +33 1 69 08 71 94                                               |
 |   fax    : +33 1 69 08 83 95                                               | 
 |----------------------------------------------------------------------------|





Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search