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 950

Article: 950
Subject: Transfering Viewlogic/XC4000 designs Sun->PC
From: lye@cs.sfu.ca (Bill Lye)
Date: Sat, 1 Apr 1995 22:52:15 GMT
Links: << >>  << T >>  << A >>
(not urgent...but if someone has any suggestions I would appreciate it)

In the labs here, we have WorkView (not sure which version) on a PC and
PowerView (5.3) on a set of Sun's, both liscensed for Xilinx Designs.
I'm attempting to do a design on an XC4013, and I entered most of the
schematics in on the Suns.  Unfortunately, there's an liscence
installation problem on the Sun's and I can't get it to compile the
design this weekend.  I thought no problem, I would just move all my
designs over to the PC and finish it off.

I can copy all my SYM, SCH, and WIR files over fine, but when I try to
open up either the SYM or SCH on the PC, it complains that it doesn't
have the liscence.  I can create & edit schematics on both the Sun's
and the PC's, but the PC won't open the one from the Sun.

I've done a couple experiments, where I entered the exact same
schematic on both, and then I looked at the schematic text file.  The
only difference (barring minor coordinate differences for joints and
components... I wasn't trying to get them *EXACTLY* the same) was in
the second line, the K line.  Editing this line on the PC, changing the
number or the name resulted in Workview going belly up.  Doing the same
on the Sun's didn't give any problems.  I didn't try to edit a file
created on the PC from the Sun, but I suspect that it will also work,
because PowerView seems to be more forgiving than WorkView.

I've already talked to one of the profs and he figures that we can sit
down with the system administrator on Monday or Tuesday to figure out
how to get the Sun's up and running, but I'd like to do some work
tomorrow.

Anyone have any suggestions?  If you do, could you please e-mail them
as well as post?  Our news gateway has been very slow in receiving
articles recently, but I do know that outgoing articles are sent just
fine.

Thanks in advance...


Article: 951
Subject: Re: How do I connect an external crystal to a XC4000?
From: fliptron@netcom.com (Philip Freidin)
Date: Sun, 2 Apr 1995 08:50:15 GMT
Links: << >>  << T >>  << A >>
In article <GEIRERT.95Mar31161214@villrips.idt.unit.no> geirert@idt.unit.no writes:
>
>How do I connect an external crystal to a 4000 series Xilinx.
>-----------------------
>
>Hi, I have a few simple questions. I need to connect a crystal (not an
>oscilator) to a XC4000. 
>
>The desired frequency is 8Mhz. How should I wire this internally. Can I
>take it in through any general purpose i/o pin, feed it through an inverter,
>and out through another gp i/o pin back to the crystal. Which side should I
>feed to a clock buffer, the in or out side of the inverter, does it matter?
>And finally what size resistors and capacitors should I use?
>

1) config an inverter between two pins
2) connect crystal between these pins
3) connect a 2.2 Meg Ohms resistor between these pins (parallel to crystal)
4) connect each pin via a capacitor to ground. try values arround 10 to 100
   pico farads.

5) play around with the capacitor values until you have a circuit that
   self starts reliably.

6) I would recomend using the output side of the inverter as the signal
   to distribute within your design.

7) Read the app note on pages 9-30 and 9-31

>
>According to the databook the XC3000 has special support for external
>crystals, but this is lacking in the XC4000 series. How come?
>

In a product that is almost totally digital, the device test issues
are such that it is highly desirable for the device to be totally
digital. IC testers tend to be either digital, analog, or hybrid.
It is hard to justify the expense of supporting analog test for
one minor function on an otherwise digital product. Most people
have enough trouble with self-starting oscillators that don't, that
the oscillator modules are used in new designs much more often than
sepparate crystals. The added expense is minimal compared to a design
that fails to start up reliably.

All the best
		Philip Freidin	fliptron@netcom.com



Article: 952
Subject: Re: How do I connect an external crystal to a XC4000?
From: gel101@gel.ulaval.ca (Vincent Rowley)
Date: 2 Apr 1995 19:51:19 GMT
Links: << >>  << T >>  << A >>
In article <GEIRERT.95Mar31161214@villrips.idt.unit.no>, geirert@idt.unit.no (Geir Ertzaas) writes:
>
>How do I connect an external crystal to a 4000 series Xilinx.
>-----------------------
>
>Hi, I have a few simple questions. I need to connect a crystal (not an
>oscilator) to a XC4000. 
>
>The desired frequency is 8Mhz. How should I wire this internally. Can I
>take it in through any general purpose i/o pin, feed it through an inverter,
>and out through another gp i/o pin back to the crystal. Which side should I
>feed to a clock buffer, the in or out side of the inverter, does it matter?
>And finally what size resistors and capacitors should I use?
>
>
>According to the databook the XC3000 has special support for external
>crystals, but this is lacking in the XC4000 series. How come?
>
>

Hi,

I don't know what is the best way to connect crystal to a XC4000
because XC4000 don't have special support for external crystals.

However, in XC4000, you have internal oscillator that you can use
for your design (Page 2-25 of the Xilinx Programmable Data Book
1994). If you work with schematics editor, use the Xilinx library
OSC4 component. This component provide internal clock signals that
you can use in applications where timing is not critical. The avai-
lable frequencies (8MHz, 500kHz, 16kHz, 490Hz and 15Hz) are process
dependant so the frequencies varies from one FPGA to an other.
If you work in HDL, instanciate also the OSC4 component.

Vincent Rowley

 

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Vincent Rowley                      Laboratoire de Vision et
                                    Systemes Numeriques
                                    Universite Laval
                                    Cite Universitaire
                                    Quebec, Canada
e-mail: gel101@gel.ulaval.ca        G1K 7P4
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~




Article: 953
Subject: Help selecting PLD design software/hardware
From: Alex Luccisano <alucci@io.org>
Date: 2 Apr 1995 20:45:12 GMT
Links: << >>  << T >>  << A >>
I work as a Design Technologist at a childrens hospital and am
currently looking into purchasing a development environment for
PLD design.  The system must be able to target everything from
GAL/PAL's to higher end FPGA's and PLD's.  The host environment
is Windows (hopefully NT).

I have heard of many different packages, but Data I/O's ABEL seems
to be the most popular.  What systems are available that are truly
vendor independent?

I have just started looking into the different device families
from AMD, Altera, Lattice, and Xilinx, so I haven't really
decided on a target family.  It has taken much too long to sift
through all the strange acronyms.  

Any suggestions, praises, and horror stories are welcome and 
appreciated.  By the way, I also need a device programmer, so
recommendations on that would also be helpful.

Thanks in advance.

Alex Luccisano
Bloorview Childrens Hospital
(416) 494-2222 x.347

e-mail: alucci@io.org


Article: 954
Subject: Xilinx software upgrade problem
From: John Forrest <jf@ap.co.umist.ac.uk>
Date: 3 Apr 1995 10:02:56 GMT
Links: << >>  << T >>  << A >>
We've finally managed to upgrade from v3.0 of ppr etc to v5.1. I've tried
a few example designs on the evaluation board and these work fine.
However, the standard way we use Xilinx 4000s is to attach them to a
microprocessor system - downloading the Xilinx configuration from the
microprocessor. We've been doing this for about two years now, and the
code has proved reliable. We extract an C array from the lca file using
makebits, makeprom and a few tools of our own. 

When we do this with the new software, I get the following two problems:

1) We have always had to write an extra byte at the end of the array to
kick off the Xilinx.  Under the old software if we did not do this, DONE
remains inactive. Under the new software, DONE goes active before this
byte is written.

2) If I comment out this final byte, the system comes up but does not
seem to initialise in the same way - I have yet to look at the system
using an analyser, but the first or second time the microprocessor
accesses the Xilinx we get a timeout on the handshaking protocol.
However, if I continue the remaining accesses are fine.

I am most curious about (1). It is possibly (even probably) related to
our C array extraction. However, I wondered if anyone else had
experienced similar problems when upgrading.

Any responses via mail please - I probably won't be able to read news for
a week or so.

_____________________________________________________________
Dr John Forrest           Tel: +44-161-200-3315
Dept of Computation       Fax: +44-161-200-3321
UMIST                  E-mail: jf@ap.co.umist.ac.uk
MANCHESTER M60 1QD
UK


Article: 955
Subject: Re: Excuse me while I vent about Data I/O & Abel...
From: kgold@watson.ibm.com (Ken Goldman)
Date: 3 Apr 1995 13:02:37 GMT
Links: << >>  << T >>  << A >>
jkubicky@cco.caltech.edu (Joseph J. Kubicky) writes:
> 
> Now I've only been using the software for a few days, so maybe I
> just haven't figured everything out yet, but I think I've been
> badly ripped off and I would strongly urge anyone else considering
> Abel to exhaust all other options first.
> 
> My first problem has been with the hardware lock.  

I've never had a problem with the hardware lock.  I thought they
recently went to a software lock anyway.  I doubt this is a
widespread problem.

> Ok, so I start using it on my laptop.  Equation and state-machine
> entry is adequate.  Hierarchy support is ok.  Note all steps are
> slow, although this might improve dramatically with more memory.
> Simulation is the 'base' $3000 version is limitted to what they
> call Equation and JEDEC simulation.  Basically you give it test
> vectors and it simulates the design to tell you if there's a match.
> As near as I can tell, though, there's no ability to do looping or
> any conditional stuff in the test vector section which would 
> greatly simplify testing things like video waveform generators that
> have long (around 1000) clock periods.  Even the ability to start 
> the thing somewhere and just let it go for a while and view the output
> would be great, but I think that is considered 'Functional Simulation'
> and is thus only available via the very expensive Verilog simulator
> option.  It looks like I could probably do something equivalent if
> I enter in a zillion vectors with lots of 'don't cares' on the outputs
> (although I haven't tried this yet), but I don't relish the thought
> of generating files of 1000 test vectors.  If I'm way off base here,
> please let me know and I might take some of this back.
> 

1 - There are examples of looping and other constructs in their
(IMHO) excellent documentation.

2 - To generate don't cares in the outputs, just don't include the output
in the test vectors.

3 - Here's why I think you're a bit off base.  Simulating a PLD is different
from simulating an ASIC.  You don't need to get it right the first time,
so there's no need to exhausively simulate everything.  In my experience,
about 100-200 vectors is enough for a simple device and 500-1000 for
a complex device.  That'll find most gross errors and typos.  Then debug
the rest in the circuit.  I know people who don't bother at all with
PLD simulation, and they still get their job done.

4 - Remember that the same test vectors are used by the programmer to test
the physical part.  That affects the simulation philosophy.  Physical
parts are never in a "don't care" state.

> In closing:  STAY AWAY FROM DATA I/O, ESPECIALLY ABEL!!!
> 
> 

I'm using a competitor's part now.  I would say from a flexibility,
performance, usability, documentation, and support perspective that
ABEL is all around superior.  It is more expensive, but when you
spread out a site-wide license on a workstation over tens of engineers
and several projects, the cost is down in the noise.



Article: 956
Subject: Test
From: adam@druid (Adam Sedziwy)
Date: Mon, 3 Apr 1995 16:56:14 GMT
Links: << >>  << T >>  << A >>

 Test


Article: 957
Subject: Re: Excuse me while I vent about Data I/O & Abel...
From: trev@ss11.wg.icl.co.uk (Trevor Hall)
Date: Tue, 4 Apr 1995 06:05:48 GMT
Links: << >>  << T >>  << A >>
kgold@watson.ibm.com (Ken Goldman) writes:-

>3 - Here's why I think you're a bit off base.  Simulating a PLD is different
>from simulating an ASIC.  
>You don't need to get it right the first time,

I disagree. If you don't get it right first time you are likely to end up with PCB
modifications.
The approach I take is to perform a 'does it look OK' simulation with the PLD tool
and then run extensive worst-case PCB level simulation.
Maybe your approach is different because you are only making one-offs, but there are
a lot of systems out there that have not been worst-cased.

>4 - Remember that the same test vectors are used by the programmer to test
>the physical part.  That affects the simulation philosophy.  Physical
>parts are never in a "don't care" state.

For production I would strongly recommend automatic test vector generation. We are not
happy until we have greater then 98% test cover.

T.H. 






Article: 958
Subject: Re: Neocad merges with Xilinx
From: thomrscott@aol.com (ThomRScott)
Date: 4 Apr 1995 09:35:10 -0400
Links: << >>  << T >>  << A >>
Okay folks I guess someone should address this. I am now a Manufacturer's
Rep representing AT&T Microelectronics in Oregon. I used to be an FAE
representing one of Neocad's resellers, and I know and respect highly many
of the people at Neocad. Before that I was a digital designer for 12
years.

This is not an April Fool's Joke. Xilinx HAS indeed purchased Neocad.
While I cannot speak for the other FPGA vendors who had been aligned with
Neocad; and while my statements are not necessarily AT&T party line, allow
me to take my official hat off and state some personal opinions:

IMHO: Xilinx has finally admitted what I've been claiming for some time,
that Neocad had developed by far the best FPGA place and route tools in
the industry. After taking a hard line for years that they wouldn't work
with Neocad (the bright folks at Neocad reverse engineered the support for
Xilinx with no help from Xilinx, and have been cleaning Xact's clock
almost from day one) Xilinx couldn't afford to be handicapped any longer.
Xilinx has finally acknowledged that their architectures -- more than
anyone else's -- desparately need the superb placement and routing of
Neocad. I think this is not even a controversial statement. Have you heard
how "good" the 4025 is?

AT&T some time ago recognized how good Neocad's stuff was and entered into
a series of agreements with Neocad that ultimately secured full source
code ownership rights. AT&T has been developing this code with Neocad for
some time now, and will be releasing updates on a regular schedule, with
some very exciting enhancements to come. In terms of interfering with
AT&T's support, Xilinx bought the barn after we'd already taken the horses
home.

Its too bad that the market will lose the vendor-independent tool that
Neocad has been. Many of our customers first discovered how good ORCA was
when using Neocad to run benchmarks. Neocad's vendor independence enabled
them to compare their designs on other FPGA architectures with AT&T ORCA
and as result discovered the strengths of the AT&T ORCA. I'm not aware of
a benchmark that ORCA has lost. When you're in that position, comparisons
are good!

In summary, this is certainly a major change in our market, but AT&T users
should have no fear that they will lose this great technology. AT&T has
the foundries, the architectures, the tools, the people, and the market
momentum to continue to be very succesful in the high-speed, medium to
high-density, super routable, low-power FPGA market for some time to come.

I hope this answers some questions. For more information contact your
local rep.
(Okay, maybe my hat did slip back on a little at the end there.  ;-)  )


Article: 959
Subject: Aptix (Field Programmable Interconnect) ??
From: louca@remus.rutgers.edu (Loucas Louca)
Date: 4 Apr 1995 12:54:49 -0400
Links: << >>  << T >>  << A >>
Hi:

I hope that this posting is in the right group...

I am designing a prototype board using Altera's Flex  81188 FPGAs and I-Cube's
IQ160 FPID (Field Programmable Interconnect Devices).  The problem is that 
these devices do not have a socket to be used with them, thus I have to solder
them on the board and this is something I want to avoid at this point of the 
design.  I was told that another company (called Aptix) is also marketting 
programmable interconnect chips so any information on how to contact them or 
anything else I should know on programmable interconnect chips would be 
really appreciated.

Thanks, 

Loucas



Article: 960
Subject: pinout changes
From: pngai@mv.us.adobe.com (Phil Ngai)
Date: Tue, 4 Apr 1995 17:48:31 GMT
Links: << >>  << T >>  << A >>
In article <D6Hy9p.EB1@oasis.icl.co.uk> trev@ss11.wg.icl.co.uk writes:
>I disagree. If you don't get it right first time you are likely to end
>up with PCB modifications.

I wonder if anyone has stories about pinout changes they would care to
share. In my personal experience, I used an Altera 5192 and made some
very minor changes (for example, went from 4 2to1 muxes to a quad 2to1
mux) and had serious pinout changes.

To their credit, Altera has come to recognize this problem and tout
their new 9000 series as being more flexible with regard to pinout
changes. I'm not sure exactly what architectural changes they made to
accomplish this besides their so called fast track routing scheme.
As I will discuss a little later on, routing is not the solution for
pinout changes.

Has anyone tried the Xilinx 5000 series? The versa ring idea sounds at
first like a good idea but the details seem a little less flexible than
one might expect.

Xilinx makes a big deal about how routable their 7000 series is but I
wonder if they are on the right track. Routing is only one part of the
picture. These days all CPLDs have a statistically reasonable number of
product terms per macrocell with various kinds of product term sharing
arrangements. This means that a signal's placement in a particular
macrocell is strongly dependent on the number of product terms it and
its neighbors use, EVEN IF YOU HAVE 100% ROUTABILITY. If a macrocell
is tied to one particular pin, then you've got posible pinout changes
when product term usage changes.

I am starting to believe that input and output switch matrixes are the
best solution to pinout changes. Lattice has this to a limited extent
but I have no personal experience with their parts.

I have had a fair amount of experience with AMD's Mach4 series and am
truly impressed with their flexibility. Lately I have been pre
assigning pinouts for PCB layout convenience and fitting is still as
easy as pushing the button. Another engineer I know put a very complex
design into 3 of the 445 parts and was delighted at how well the parts
worked.

Disclaimer: this may sound like an ad for Mach4 but I'm simply excited
about a part that seems to be in general very well thought out. I used
to work at AMD but had nothing to do with the PAL division (aside from
using their parts) and have absolutely zero financial interest in the
company now.

One thing I do find missing in the Mach4 is how to do a programmable
address comparator. The Intel Flex/Altera Flash logic series has
a very nice address comparator mode.

(speaking of Altera, isn't it amazing how of the three parts in their
Flash logic series, two of them AREN'T flash logic? I also like
the way they can't decide if their Flex8000 logic is FPGA or CPLD.)

-- 
 Question Authority, but never shoot back.


Article: 961
Subject: Re: Neocad merges with Xilinx
From: dh@fncrd7.fnal.gov (don husby)
Date: 4 Apr 1995 18:29:23 GMT
Links: << >>  << T >>  << A >>
thomrscott@aol.com (ThomRScott) writes:
> ...
> In summary, this is certainly a major change in our market, but AT&T users
> should have no fear that they will lose this great technology. AT&T has
> the foundries, the architectures, the tools, the people, and the market
> momentum to continue to be very succesful in the high-speed, medium to
> high-density, super routable, low-power FPGA market for some time to come.

I have several random thoughts on the subject:

1) How will AT&T support current NeoCad customers?  Since we've
already bought into Neocad to the tune of $8000 and it's eating a 100
Megabyte hole in my hard disk, will we have to buy another $5000
package from AT&T or will they support our current investment?

2) The market is now open for another multi-vendor FPGA tool.  If any 
company was thinking of entering the market, this would be an 
excellent time.  It also seems like AT&T would want to support that 
effort, since it keeps the door open for Xilinx cutomers to migrate to
the ORCA product.  (AT&T is probably prohibited from offering
multi-vendor Neocad.  If it isn't, then Xilinx shot itself in the 
foot.)

3) I don't know much about anti-trust laws, but it seems like this is 
the sort of situation where you would want one:  Xilinx eliminates a 
competitor (Neocad), deals strong blows to three others, and sets the 
market back by eliminating useful tool (chip-independent design 
capabiliy).

4) This is the second time this has happened to the folks at NeoCad:  
The company was founded by the remnants of Cadnetix, which was, 
arguably, the best PC-board CAD/CAE system available back around 1987.
It's competitor, Daizy, was losing market share and tried a hostile 
takeover of Cadnetix.  The companies eventually merged, their products
took on the worst features of both companies, and they eventually
went down the tubes together.  At the time we had about $400K invested
in Cadnetix tools.  


Article: 962
Subject: Re: Neocad merges with Xilinx
From: coffin@microlab.Colorado.EDU (Eric Coffin)
Date: 4 Apr 1995 13:12:27 -0600
Links: << >>  << T >>  << A >>
In article <3lrhue$sf6@newsbf02.news.aol.com>,
ThomRScott <thomrscott@aol.com> wrote:

*Snip!*

>code ownership rights. AT&T has been developing this code with Neocad for
>some time now, and will be releasing updates on a regular schedule, with
>some very exciting enhancements to come. In terms of interfering with
>AT&T's support, Xilinx bought the barn after we'd already taken the horses
>home.
>

*Snip!*
 
Only time will tell.....

So far from what I've read about this in the April 3rd edition of the
Electronic Engineering Times is that AT&T only has the source code, not
necessarily the expertise associated with the source.
 
Eric


Article: 963
Subject: Re: Aptix (Field Programmable Interconnect) ??
From: mjodalfr <mjodalfr@nmia.com>
Date: 5 Apr 1995 05:33:35 GMT
Links: << >>  << T >>  << A >>
louca@remus.rutgers.edu (Loucas Louca) wrote:
>
> Hi:
> 
> I hope that this posting is in the right group...
> 
> I am designing a prototype board using Altera's Flex  81188 FPGAs and I-Cube's
> IQ160 FPID (Field Programmable Interconnect Devices).  The problem is that 
> these devices do not have a socket to be used with them, thus I have to solder
> them on the board and this is something I want to avoid at this point of the 
> design.  I was told that another company (called Aptix) is also marketting 
> programmable interconnect chips so any information on how to contact them or 
> anything else I should know on programmable interconnect chips would be 
> really appreciated.
> 
> Thanks, 
> 
> Loucas
> 

    For an alternative, try Ironwood.... they make a plethora
of sockets for various devices, or look in the back of the flex
data book, it lists various manufacturer's of sockets....

    Don't use the Altera sockets though.... I nearly lost my hair
using the damn thing.

    Wassail,
    MjodalfR


Article: 964
Subject: new group
From: "Baykov Vladimir" <BAYKOV@cslab.felk.cvut.cz>
Date: Wed, 5 Apr 1995 12:51:48 GMT
Links: << >>  << T >>  << A >>
  from: baykov@cslab.felk.cvut.cz
  creating the new group: comp.arch.arithmetic. CORDIC



 Dear Colleagues in COMPUTER ARITHMETIC area,


 More than thirty five years ago a well-known paper of
                  JACK VOLDER
 "The CORDIC trigonometric computing technique" was published
 in IRE Transactions on Computers. Now about 1000 publications
 related to this problem were issued.
 The research on this subject is being performed in many coun-
 tries: Australia, Canada, China, England, Germany, India, Is-
 rael, Italy, Japan, Netherland, Romania, the former USSR, Taiwan,
 France, Switzerland. Only in the USA similar research is made
 in about 15 universities.
 Everybody knows that, for instance all the coprocessors INTEL:
 8087, 80287, 80387 etc., are based on CORDIC algorithm.
 Taking into consideration large domain of Volder's algorithms
 and their efficiency for VLSI implementation and for bringing
 together researcher's activity in the indicated fields I offer
 the creation of the new group: 

               comp.arch.arithmetic.CORDIC

 This new group  could coordinate researches in this area, exchange
of new results around the world.



Article: 965
Subject: AT&T Statement ref Neocad
From: ipacker@bloggs.win-uk.net (Ian Packer)
Date: Wed, 05 Apr 1995 13:07:06 GMT
Links: << >>  << T >>  << A >>
Here is a statement I was given by AT&T ME with regard to the
Xilinx acquisition of Neocad:
(In brief; looks like no problem for ORCA support)


April 4, 1995

Dear Customers:

You may be aware of the recent announcement by Xilinx regarding their
acquisition of NeoCAD.  In the fourth quarter of last year AT&T
Microelectronics and NeoCAD entered into a licensing agreement for
development of software to support our ORCA family of FPGAs.  In order to be
prepared for any possible scenario, AT&T acquired access to the NeoCAD source
code as part of that agreement.  Our CAD development team has been working
with that code, adding new features and enhancements.  Under the terms of our
agreement with NeoCAD, AT&T is granted a full license to that source code in
the event NeoCAD is acquired by an AT&T competitor.

We have the source code, the people resources, and the financial commitment
to move forward with ORCA CAD development.  For this reason, we feel this
acquisition should be transparent to our customers.  AT&T will continue to
provide the highest density, highest-performance FPGAs in the industry.  For
example, we'll be moving our ORCA product line to 0.35-micron technology
later this year, providing even higher-density and higher-speed devices.

We ask our customers to please work with us for the next few weeks as we work
through this transition.

Sincerely,


John T. Dickson
Vice President
Integrated Circuits

                             Background Statement

When AT&T Microelectronics decided not to second source the Xilinx 4000 family
of FPGAs, we accelerated the introduction of the ORCA family.  That effort
involved accelerating the time to market for both the hardware and software
solutions.

Our plans required that we develop a CAD tool for the ORCA family within 18
months.  At the point of introduction of ORCA, we realized that the NeoCAD
tools would allow us to further accelerate our CAD solution to the market.
In the fourth quarter of last year AT&T licensed the NeoCAD technology, and
has had access to the NeoCAD source code since that time.

The AT&T CAD development team is properly staffed and has been working with
the NeoCAD source code and is prepared to continue to develop the ORCA CAD
solution.  AT&T will be providing a Version 7.0 release to its customers which
features support for the 2C04 through 2C26, with a beta patch for the 2C40,
along with other enhancements.
                            
                        Questions and Answers

1.  Can I call AT&T with questions regarding NeoCAD software support?

    AT&T has been providing front-line support to our customers and will
    continue to do so.

2.  Who do I call to report software bugs, and who is responsible for
    fixing them?

    Our customers can call the AT&T Hotline at 1-800-327-9374 and we will be
    fixing all bugs in future releases.

3.  Can I still purchase NeoCAD software from AT&T?

    Yes, AT&T will be offering all of the ORCA software solutions, including
    evaluation copies.  The comcodes remain the same but the new name for the
    place and route tools is "ORCA Foundry".

4.  I purchased the ORCA family module from NeoCAD and have a maintenance
    agreement with NeoCAD.  Will AT&T support me?

    Yes, AT&T will support all customers designing with ORCA regardless of
    who they licensed it from.

5.  Does AT&T plan to continue to do new product introductions based on the
    existing CAD environment?

    Yes, as a result of the modular fashion in which NeoCAD has developed
    their device-independent software, only 10% of the code is devoted to
    any one family module; therefore, it's very easy for AT&T to develop and
    introduce a new family module to support future AT&T products and
    architectures.

6.  How will this acquisition affect the schedules for future ORCA devices
    from AT&T?

    The NeoCAD tools allow for new devices to be added very quickly because
    of the modular approach.  Like the 2C ORCA family, AT&T defined the
    architecture using AT&T proprietary development tools.  The architectural
    information was merged into the NeoCAD tool set.  The development
    methodology will allow for AT&T to quickly bring new products to
    market in the same fashion.  We will remain on schedule.


7.  Why do you think Xilinx pursued this acquisition?

    In our opinion Xilinx recognized the superiority of the NeoCAD solution,
    much in the same way AT&T did a year earlier.

8.  Will NeoCAD continue to offer their device-independent product to the
    marketplace?

    Contact NeoCAD.


Regards,
Ian Packer.
Bytech Electronics Ltd.


Article: 966
Subject: Re: Excuse me while I vent about Data I/O & Abel...
From: kgold@watson.ibm.com (Ken Goldman)
Date: 5 Apr 1995 13:17:43 GMT
Links: << >>  << T >>  << A >>
trev@ss11.wg.icl.co.uk (Trevor Hall) writes:
> kgold@watson.ibm.com (Ken Goldman) writes:-
> 
> >3 - Here's why I think you're a bit off base.  Simulating a PLD is 
> >different from simulating an ASIC.  
> >You don't need to get it right the first time,
> 
> I disagree. If you don't get it right first time you are likely to end up 
> with PCB modifications. The approach I take is to perform a 'does it 
> look OK' simulation with the PLD tool and then run extensive worst-case 
> PCB level simulation.
> Maybe your approach is different because you are only making one-offs, 
> but there are a lot of systems out there that have not been worst-cased.
> 

I agree that one might occasionally forget an input, but it's been rare
for me.  And despite my division name, I am designing products.  Since
time to market is the key, I've found that it's faster to build a
board than to spend months developing simulation models.  Again. this
is for boards with PLD's, not ASICs.  

Any other opinions.  Are others doing full PCB simulation for cards
without ASICs?  Does it really result in a PCB with _zero_ errors,
meaning you go straight to volume production with the first PCB?


> >4 - Remember that the same test vectors are used by the programmer to test
> >the physical part.  That affects the simulation philosophy.  Physical
> >parts are never in a "don't care" state.
> 
> For production I would strongly recommend automatic test vector 
> generation. We are not happy until we have greater then 98% test cover.
> 

I agree with the 98% coverage (or better).  But I usually try for that
at the PCB level, not at PLD programming time.

Other opinions.  Is it common to use automatic test vector generation
for PLD's?  Does it find errors that a few hundred hand crafted vectors
plus board level test would not find?


Article: 967
Subject: Vendor Info
From: wolf@aur.alcatel.com (William J. Wolf)
Date: 5 Apr 1995 13:51:41 GMT
Links: << >>  << T >>  << A >>
IMHO vendors should post *pointers* to www sites, ftp sites, etc 
that have info such as that contained in:

> AT&T FPGA #6 - Application Notes

Take this for example - instead of just dumping today's 
special into comp.arch.fpga, post a pointer to a maintained 
list of FPGA app notes (along with net pointers to other 
FPGA info).

If users *want* dumps of today's special, I suggest AT&T 
support a list server for FPGAs (like Altera & Xilinx) 
and post directions on how to sign up.

Is there a vendor out there who could take the time to 
compile a list of net pointers to your FPGA info?  If 
one of you will go first, I suspect others will also follow.
This would also help greatly with the newbie questions.

---
- Bill Wolf, Raleigh NC
- My opinions, NOT my employer's




Article: 968
Subject: Re: Opinions on IBM PowerPC for Electronics CAD lab
From: fateh@springer.watson.ibm.com (Fateh A. Tipu)
Date: 5 Apr 1995 16:01:46 GMT
Links: << >>  << T >>  << A >>
In article <D6A8wK.D49@pts.mot.com>, ep520mi@pts.mot.com (MARK INDOVINA Xxxxx Ppppp) writes:
|> Does Viewlogic and Xilinx support AIX? I would assume you could easily

We have been using Viewlogic's Powerview on RS6k's running AIX for some
time. Our machines are not PowerPC based though.

-- Tipu
-------------------------------------------------------------------------------
Name  : Fateh Tipu		Tie-Line: 862-1988	Tel: (914) 945-1988
Email : fateh@watson.ibm.com
Post  : IBM TJ Watson Research Center, P.O. Box 218, Yorktown Heights, NY-10598


Article: 969
Subject: Xilinx simulation models for synopsys..
From: jshah@cs.iastate.edu (Jatan Shah)
Date: 5 Apr 95 19:15:00 GMT
Links: << >>  << T >>  << A >>
Hi,

	Could anyone help me out in simulating designs synthesized
using Xilinx Xc4000 target libraries in synopsys?


-Jatan




Article: 970
Subject: Re: Xilinx simulation models for synopsys..
From: walton@emc.com (John Walton)
Date: 5 Apr 1995 19:46:04 GMT
Links: << >>  << T >>  << A >>
In article <jshah.797109300@shazam.cs.iastate.edu>, jshah@cs.iastate.edu (Jatan Shah) writes:
|> Hi,
|> 
|> 	Could anyone help me out in simulating designs synthesized
|> using Xilinx Xc4000 target libraries in synopsys?
|> 
|> 
|> -Jatan
|> 
|> 
You have any simulation platform in mind? It makes a difference.


Article: 971
Subject: Re: Aptix (Field Programmable Interconnect) ??
From: kutlu@ix.netcom.com (Kutlu Aricanli)
Date: 5 Apr 1995 21:51:01 GMT
Links: << >>  << T >>  << A >>
In <3lrtkp$626@remus.rutgers.edu> louca@remus.rutgers.edu (Loucas Louca) 
writes: 

>
>Hi:
>
>I hope that this posting is in the right group...
>
>I am designing a prototype board using Altera's Flex  81188 FPGAs and I-Cube's
>IQ160 FPID (Field Programmable Interconnect Devices).  The problem is that 
>these devices do not have a socket to be used with them, thus I have to solder
>them on the board and this is something I want to avoid at this point of the 
>design.  I was told that another company (called Aptix) is also marketting 
>programmable interconnect chips so any information on how to contact them or 
>anything else I should know on programmable interconnect chips would be 
>really appreciated.
>
>Thanks, 
>
>Loucas
>
>

Aptix is located in San Jose, CA. They make programmable interconnect
chips, as well as programmable system prototype boards, for which they
support the 81188. They mount the 81188s on small boards which you can
plug onto the board. You can also add other functionality to the board
(memory, I/O ports, etc).

Their phone # is: (408) 428-6200
Their address is: 2890 N. 1st St., SJ, CA 95134

I only know their western region sales manager, Robert Bicsek, and he
should be able to tell you who to talk to for the Eastern region.

I hope this helps,

Kutlu Aricanli
FAE
Arrow/Schweber, San Jose
kutlu@ix.netcom.com
(408) 441-9700



Article: 972
Subject: Re: Excuse me while I vent about Data I/O & Abel...
From: pngai@mv.us.adobe.com (Phil Ngai)
Date: Wed, 5 Apr 1995 22:29:09 GMT
Links: << >>  << T >>  << A >>
In article <3lu59n$13hf@watnews1.watson.ibm.com> kgold@watson.ibm.com (Ken Goldman) writes:
>Other opinions.  Is it common to use automatic test vector generation
>for PLD's?  Does it find errors that a few hundred hand crafted vectors
>plus board level test would not find?

I'm not sure what the purpose of test vectors for PLDs is anymore.
Back when fuses were one-time things and the chip companies couldn't
100% test them, I suppose the chance of a defective chip was non-zero.
With eraseable chips, is this still a problem?

Or are we talking about design verification vs manufacturing test?

-- 
 Question Authority, but never shoot back.


Article: 973
Subject: Re: Neocad merges with Xilinx
From: ep520mi@pts.mot.com (MARK INDOVINA Xxxxx Ppppp)
Date: Wed, 5 Apr 1995 22:37:09 GMT
Links: << >>  << T >>  << A >>
In article <3ldf7p$4cg@hustle.rahul.net>, ASM  <someone@somewhere.com> wrote:
>
>It is now confirmed from reliable sources that Xilinx has taken
>over Neocad this week to put an end to the competition for Xilinx
>P&R tools.
>
>-ASM.

Hmm, did they merge or did Xilinx eat ( buy ) Neocad???

...inquiring minds want to know...

-- 
/* Mark A. Indovina, Principal Staff Engineer   mark_indovina@pts.mot.com */
/* MOTOROLA   Strategic Semiconductor Operation, IC Technology Laboratory */
/* Mail Stop 63, 1500 Gateway Boulevard, Boynton Beach, FL 33436-8292 USA */
/* phone: 1-407-739-2379, fax: 1-407-739-3904    ...just speaking for me! */


Article: 974
Subject: Call for Papers
From: john@vcc.com (John Schewel)
Date: Wed, 5 Apr 1995 23:51:31 GMT
Links: << >>  << T >>  << A >>



A note to all......

This is an opportunity for our community to introduce Reconfigurable 
Computing to an audience which is diverse and has never heard of 
using reconfigurable logic for applications, other than traditional
EDA use. We are looking for a half dozen or so qualified papers to round
out the session. Please contact me with abstract submissions.

_____________________________________________________________________________

CONFERENCE ON

                     "Using Reconfigurable Technology for Solving 
                  the Computational and Signal Processing Bottlenecks"
               

This conference is part of SPIE's International Symposium on

             		INFORMATION, COMMUNICATIONS, COMPUTER &
                         TECHNOLOGIES, APPLICATIONS, & SYSTEMS
    
       Symposium Chair: Arun Netravalli, VP Research, Bell Labs, AT&T

To be held as part of Photonics East '95
                      Philadelphia, Pennsylvania USA
                      22-27 October 1995
                      (over 5000+ attendees at Boston, Photonics94)

Conference Chair: John Schewel, Virtual Computer Corp., 
Program Committee: Peter Athanas, Virginia Polytechnic Institute
                                   & State Univ., athanas@vt.edu;
                   Brad Fawcett, Xilinx Corp., brad.fawcett@xilinx.com; 
                   Dave Kolmier, Data I/O Corp., davek@data-io.com;
                   John Watson, Viatek Corp., jlwatson@aol.com 


Reconfigurable technologies are new and valuable tools for the
development and rapid prototyping of future products. With the
ever-changing standards in the marketplace and growing worldwide
competition, one must continually search for methods which
accelerate the time to market. Current reconfigurable hardware
platforms enable the use of this technology for electronic design
in rapid product development and performance acceleration.

This conference will present papers that illustrate applications
and techniques for solving computational and signal processing
bottlenecks using reconfigurable technology in product design
and software acceleration.

Papers are solicited in the following and related areas:

-   reconfigurable digital components, and their use in
communications and image processing

-   reconfigurable analog components, and their use in
communications and image processing

-   applications and platforms utilizing reconfigurable
technology for rapid product development in communications and
image processing

-   applications and platforms utilizing reconfigurable
technology for high-speed computing.

John Schewel
E-mail: jas@vcc.com 
Fax: 818/342-0240    
Phone: 818/342-8294 

PHOTONICS EAST DEADLINES
Abstracts - as soon as possible
Manuscripts Due from Authors:
     August 1, 1995 (on-site books)
     September 25, 1995 (post-meeting books) 






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