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 2200

Article: 2200
Subject: xilinx flor planner
From: maya@asp.co.il (Maya Reuveni)
Date: Tue, 31 Oct 1995 09:15:10 GMT
Links: << >>  << T >>  << A >>
hi ,
I have the xilinx package for sun.
I did not have the flor planner but i heard i can have it free as
a sun user.
does anybody know from where i can take the flor planner files
and how i use it ?
thanks  

-- 

    Maya Reuveni                                  Tel: 972-9-986976
    Manager of Hardware Department                Fax: 972-9-986980
    HaTaasiya 9, Raanana 43100, Israel.           E-mail: maya@asp.co.il




Article: 2201
Subject: Re: Where to find more info on PCI
From: torela@idt.unit.no (Tore H.Larsen)
Date: Tue, 31 Oct 95 12:35:01 GMT
Links: << >>  << T >>  << A >>
In article <465mt8$igu@neptune.myri.com>,
   wen-king@myri.com (Wen-King Su) wrote:
>In my current project I need to design a PCI interface using FPGA.  I
>have the official PCI spec book, but I need more information on the actual
>implementations that are out there.  For example, what is the maximum
>"cache line size" that people actually use in their machine.  It will
>have an effect on how complicated the FPGA code will be.  Do I need a
>cache line size computation circuit on the whole 8 bits for the write
>line and invalide operation?  Also what is the maximum DMA throughput
>between device and memory I can expect on a real system under each transfer
>type.  Any info or pointers to info will be appreciated.  Thanks. 

You might be interested in xilinx own PCI-complient interface. The link is

http://www.xilinx.com/products/appsweb.htm#PCI

Sincerely,
Tore
torela@idt.unit.no


Article: 2202
Subject: Re: AMCC pci kit- problems
From: jma@b117d.super.org (Jeffrey M. Arnold)
Date: Tue, 31 Oct 1995 14:43:41 GMT
Links: << >>  << T >>  << A >>
In article <DH2nzv.6Kt@emr1.emr.ca> methot@ccrs.emr.ca (Simon Méthot) writes:
> second. Presently having a hard time writing and reading the flash memory 
> 29C512.  This morning I could read the first 64 byte no problem.  Then I 
> went to write mode,  was never successful in writng a location and 
> reading back the proper info.   By afternoon I got deeper in the hole now 
> cannot read back successfully a lot of the bytes being read are FF.  Any 
> help would be appreciated.  Even AMCC nvbuild program is not successful 
> in writing to the flash memory everytime.  

We also had some problems with the AMCC development board.  The
documentation is simply wrong in several places, most notably the C
code fragment to access the NVRAM (page A-13 in the Spring 1995
manual).  I *was* eventually able to program the serial device by
using 16-bit accesses to the high half of the MCSR to set both the
command bits and the NVRAM data simultaneously.

Unfortunately, first you must dig yourself out of the hole created by
the corrupted NVRAM.  The way to do that is to remove the device from
the board and reprogram it on a standard PROM burner (e.g. DataIO)
using the data file from the AMCC installation disk.

-jeff

------
Jeffrey Arnold
IDA Center for Computing Sciences (formerly the Supercomputing Research Center)
17100 Science Dr.
Bowie, MD 20715
email: jma@super.org


Article: 2203
Subject: Re: small superscalar design ?
From: jsgray@ix.netcom.com (Jan Gray)
Date: 1 Nov 1995 08:07:00 GMT
Links: << >>  << T >>  << A >>
In <HAMMAMI.95Oct29205005@pross113.u-aizu.ac.jp> hammami@u-aizu.ac.jp (Omar
Hammami) writes: 

>Dear Netters:
>
>Does anyone have ever tried to implement a small superscalar
>processor design using FPGAs ? I would like to have an idea of
>the gate complexity level for say a 16 bits superscalar with
>roughly 3 FP units and 2 Int units and a limited number of
>instructions.

Great question!  It is surely possible, but it might not be the best fit of
architecture to implementation technology...

First, let's talk functional units.  Integer ALUs are easy to implement, you
simply need an adder, logic unit, and multiplexor of some sort.  Ripple
carry adders will do, given vendors' dedicated carry chain hardware.  Decent
performance FPUs would be more difficult.  An FP add/sub will require
renormalization which requires a barrel shifter (bad: lots of wires!) or
several iterative cycles of fewer bit shifts.  A multiplier of managable
size will also take several cycles, although at 16-bit FP (1 bit sign + 5
bit exp + 10 bit mantissa?) you might only need at 10x10->20 bit multiplier.

(This is an invitation for you FP in FPGA veterans to chime in with your
experiences.)

Moving on, the register file could well be your critical path.  If you hope
to sustain an average of even one and a half integer instructions per clock
you will have to fetch three or four operands per clock and retire two.  A
3-read-2-write register file in which the two write back values are retired
before you read the three new operands will take at least 2 SRAM write
cycles on embedded dual ported SRAMs and up to 4 cycles on embedded non-dual
ported synchronous SRAMs, depending upon how many copies of the register
file you keep.  (See Xilinx 4000E, Altera Max10K, Actel 3200DX?.)  For
instance, on the new Xilinx 40xxE-3 parts, you are talking at least 2-, 3-,
or 4- ~15 ns sync-SRAM cycles best case.  This design would hardly be
competitive with a single-issue one which could sustain one instruction per
clock at twice the clock rate.

Once again the "speed demons" whip the "brainiacs"!

And if you hope to retire 3 or 4 results (peak) per clock, your basic cycle
time is even worse.  Your only hope might be to lobby the FPGA architects
for multi-multi-ported SRAMs (2-write, 2-read quad ported synchronous SRAMs,
anyone? :-)


A VLIW like architecture could be a better architectural choice because much
of the register file, and its multiple write back liability, could be spread
about the functional units with limited degrees of communication between
units, achieving only one register file write back operation each clock per
unit.  (I have some "paper" VLIW datapath floorplans that satisfactorily fit
in large existing FPGAs.)  For instance, you could easily distribute 64
16-bit registers and four ALUs about as 4 units each of 16x16-bit register
file+ALU, assuming instruction operand constraints that a given instruction
segment for one unit could only read operands from that unit or (in a
limited way) from adjacent units, and could only write back results to that
unit.  Then you could keep the register file result write back cycle time
down to one or two sync-SRAM or dual port SRAM write and readback cycles no
matter how wide your machine grows.

But, I'd hate to have to write your compiler's code generator.

Another comment.  Superscalar microarchitectures typically demand many
operand busses to route lots of operands and results to lots of
functional units.  Unfortunately, wires are relatively much more
expensive in FPGAs than in custom designs (where they are already
plenty expensive).  The datapath of my (now working!) 32-bit pipelined
RISC (half an XC4010) has just barely enough wiring resources to
implement a single issue microarchitecture.  Unless you are a wizard at
time multiplexing different operands and results on the same wires, say
at 10 ns intervals, without incurring killer delays, I think you would
find today's FPGAs unacceptably wire limiting.

But by all means give it a try!  Sounds like a great push-the-envelope
project.

 
>Any pointers on books, TRs and projects descriptions for 
>undergraduates and graduates will be appreciated.

Very highly recommended reference: Mike Johnson's book, Superscalar
Microprocessor Design, Prentice Hall, 1991, ISBN 0-13-875634-1.


"Tired: superscalar; Wired: VLIW and multithread,"
Jan Gray
Redmond, WA




Article: 2204
Subject: Re: small superscalar design ?
From: jsgray@ix.netcom.com (Jan Gray)
Date: 1 Nov 1995 19:01:14 GMT
Links: << >>  << T >>  << A >>
(Reposted: Netcom brilliantly expired the first copy of this message
the very same night it was posted.  Apologies if duplicated.)

In <HAMMAMI.95Oct29205005@pross113.u-aizu.ac.jp> hammami@u-aizu.ac.jp
(Omar
Hammami) writes: 

>Dear Netters:
>
>Does anyone have ever tried to implement a small superscalar
>processor design using FPGAs ? I would like to have an idea of
>the gate complexity level for say a 16 bits superscalar with
>roughly 3 FP units and 2 Int units and a limited number of
>instructions.

Great question!  It is surely possible, but it might not be the best
fit of
architecture to implementation technology...

First, let's talk functional units.  Integer ALUs are easy to
implement, you
simply need an adder, logic unit, and multiplexor of some sort.  Ripple
carry adders will do, given vendors' dedicated carry chain hardware. 
Decent
performance FPUs would be more difficult.  An FP add/sub will require
renormalization which requires a barrel shifter (bad: lots of wires!)
or
several iterative cycles of fewer bit shifts.  A multiplier of
managable
size will also take several cycles, although at 16-bit FP (1 bit sign +
5
bit exp + 10 bit mantissa?) you might only need at 10x10->20 bit
multiplier.

(This is an invitation for you FP in FPGA veterans to chime in with
your
experiences.)

Moving on, the register file could well be your critical path.  If you
hope
to sustain an average of even one and a half integer instructions per
clock
you will have to fetch three or four operands per clock and retire two.
 A
3-read-2-write register file in which the two write back values are
retired
before you read the three new operands will take at least 2 SRAM write
cycles on embedded dual ported SRAMs and up to 4 cycles on embedded
non-dual
ported synchronous SRAMs, depending upon how many copies of the
register
file you keep.  (See Xilinx 4000E, Altera Max10K, Actel 3200DX?.)  For
instance, on the new Xilinx 40xxE-3 parts, you are talking at least 2-,
3-,
or 4- ~15 ns sync-SRAM cycles best case.  This design would hardly be
competitive with a single-issue one which could sustain one instruction
per
clock at twice the clock rate.

Once again the "speed demons" whip the "brainiacs"!

And if you hope to retire 3 or 4 results (peak) per clock, your basic cycle
time is even worse.  Your only hope might be to lobby the FPGA architects
for multi-multi-ported SRAMs (2-write, 2-read quad ported synchronous SRAMs,
anyone? :-)


A VLIW like architecture could be a better architectural choice because much
of the register file, and its multiple write back liability, could be spread
about the functional units with limited degrees of communication
between
units, achieving only one register file write back operation each clock
per
unit.  (I have some "paper" VLIW datapath floorplans that
satisfactorily fit
in large existing FPGAs.)  For instance, you could easily distribute 64
16-bit registers and four ALUs about as 4 units each of 16x16-bit
register
file+ALU, assuming instruction operand constraints that a given
instruction
segment for one unit could only read operands from that unit or (in a
limited way) from adjacent units, and could only write back results to
that
unit.  Then you could keep the register file result write back cycle
time
down to one or two sync-SRAM or dual port SRAM write and readback
cycles no
matter how wide your machine grows.

But, I'd hate to have to write your compiler's code generator.

Another comment.  Superscalar microarchitectures typically demand many
operand busses to route lots of operands and results to lots of
functional units.  Unfortunately, wires are relatively much more
expensive in FPGAs than in custom designs (where they are already
plenty expensive).  The datapath of my (now working!) 32-bit pipelined
RISC (half an XC4010) has just barely enough wiring resources to
implement a single issue microarchitecture.  Unless you are a wizard at
time multiplexing different operands and results on the same wires, say
at 10 ns intervals, without incurring killer delays, I think you would
find today's FPGAs unacceptably wire limiting.

But by all means give it a try!  Sounds like a great push-the-envelope
project.

 
>Any pointers on books, TRs and projects descriptions for 
>undergraduates and graduates will be appreciated.

Very highly recommended reference: Mike Johnson's book, Superscalar
Microprocessor Design, Prentice Hall, 1991, ISBN 0-13-875634-1.


"Tired: superscalar; Wired: VLIW and multithread,"
Jan Gray
Redmond, WA




Article: 2205
Subject: Re: AT&T vs. Xilinx
From: Patrick Drolet <pdrolet@cybersecure.com>
Date: Wed, 01 Nov 1995 12:54:53 -0800
Links: << >>  << T >>  << A >>
Christian Grebe wrote:
> being a Xilinx user I experienced routing problems with the 4025 while using
> the part in a rapid prototyping project. Having a very high connectivity in my
> design there was an upper bound of about 50% utilization, which is quite
> realistic with this part. The design needed intensive manual floorplanning.

If you have massive production or need extra CLB's, try to place some of the CLB manually.

> When timing is too tight the router will run forever while building subnets on
> large and slow nets to speed up signals, making the routing problem worse.

This is why some CLB need to be placed manually.  NeoCad (better) or XACT are no
expert system and there is nothing like a human being to solve common sense problems.

> It is no secret that Xilinx is aware of this problems. They claim that the new
> XC4000E series will overcome this problem, having more routing ressources while
> being pin compatible.

I'm not sure, but according to the 4000E specs, there is nothing more in the 4000E series than dual 
port RAM or synchronous RAM.  They don't talk about more ressources.  Bitstream & pin compatibles 
yes, but no extra routing ressources.


Article: 2206
Subject: Re: FREE $$$ MAKING SOFTWARE !!!
From: "Kurt R. Zaske" <kzaske@nando.net>
Date: Wed, 01 Nov 1995 13:59:46 -0800
Links: << >>  << T >>  << A >>
Get the hell off this page.  It's for programmable logic users.


Article: 2207
Subject: **ANNOUNCEMENT: VHDL to Verilog Translator**
From: obiliset@ASCinc.com(Sashi Obilisetty)
Date: Wed, 1 Nov 1995 22:40:47 GMT
Links: << >>  << T >>  << A >>
ANNOUNCING THE RELEASE OF ASC's VHDL to Verilog TRANSLATOR, VHDL2verilog(TM)
----------------------------------------------------------------------------

VHDL2verilog translates hierarchical VHDL to functionally equivalent Verilog
HDL. All structural VHDL constructs, as well as a large subset of RTL VHDL
constructs are supported by VHDL2verilog. Both IEEE Standard 1076-1987 and
1076-1993 compliant VHDL are processed by the tool. Output Verilog follows
the proposed IEEE-1364 standard, and is easy to understand.  Product
description can be found at http://www.ascinc.com/vhdl2v.                    

VHDL2verilog can also be obtained with an object-oriented Software Procedural
Interface (SPI) to access the output HDL and is currently available for SunOS
4.1.x platform.

An immediate demo is available at http://www.ascinc.com/vhdl2v.

All enquiries to: 
----------------

Jon Clancy
Alternative System Concepts, Inc.  PO Box 128 Windham NH 03087 
Ph:(603)437-2234 Fax: (603)437-2722 
email: info@ASCinc.com

-- 
*	Sashi Obilisetty							*
*	Alternative System Concepts, Inc.					*
*	PO Box 128 Windham NH 03087						*
*	tel (603) 437-2234 fax (603) 437-ASC2	URL http://www.ascinc.com	*


Article: 2208
Subject: XC4025 routing
From: sc@vcc.com (Steve Casselman)
Date: Thu, 2 Nov 1995 01:55:41 GMT
Links: << >>  << T >>  << A >>
> being a Xilinx user I experienced routing problems with the 4025 while using
> the part in a rapid prototyping project. Having a very high connectivity in my
> design there was an upper bound of about 50% utilization, which is quite
> realistic with this part. The design needed intensive manual floorplanning.

You might want to try and place logic AWAY from the center. Placement
algorithms tend to place logic as close together as possible and this
causes congestion. When there used to be channeled gate arrays and they
started to get large many vendors made the channels larger near the center.
To do this with a FPGA try and place logic near the edges to free up
the center which can then be used for routing.

Steve Casselman


Article: 2209
Subject: Xilinx XSI FPGA User Guide
From: sjba@ukc.ac.uk (S.J.B.Acock)
Date: Thu, 02 Nov 95 13:55:06 GMT
Links: << >>  << T >>  << A >>


I am currently using version 5.0.0 XACT software which runs on
a UNIX based operating system. As far as I am aware I have a full
set of manuals for XACT but Xilinx have recently refered me to
a manual entitled The XSI FPGA User Guide. This I do not have,
has anyone else used this manual, is it a new manual that comes
with the latest release of XACT ?

Thanks,

Steven Acock

-----------------
Electronic Labs,
University of Kent,
Canterbury,
Kent, 
United Kingdom.
-----------------





Article: 2210
Subject: Re: Xilinx Configuration Memory Hacking
From: dpl@dansnext (Daniel Lopresti)
Date: Thu, 2 Nov 1995 16:18:06 GMT
Links: << >>  << T >>  << A >>
In article <DGn77M.F9s@tumlis.lis.e-technik.tu-muenchen.de>  
news@tumlis.lis.e-technik.tu-muenchen.de writes:
> Hi all,
> 
> is there anyone, who has tried to hack the internal configuration memory
> structure of Xilinx FPGA's?
> 
> 
> 
> Thanks
> 

I tried this once a number of years ago - back in the Xilinx 3090 era.  There  
was a specific pattern matching application I had in mind, where the pattern  
was encoded in the logic and the database streamed by it.  To encode the  
pattern required changing the logic.

In truth, though, all I really wanted to change was the truth tables - the  
routing remained exactly the same each time.  As others have noted, it's silly  
to keep paying the price for placement and routing when none of this is  
changing.  (In my case, each place & route cycle was taking about 40 minutes.)

It was pretty easy to figure out which bits in the bit stream file corresponded  
to which bits in the truth tables.  None of this required a NDA from Xilinx.   
(The routing resources are much more complicated, though - I wouldn't have  
tried to figure those out.)

I was actually able to "twiddle" various bits directly in the bit stream file  
and change the programming of the FPGA.  I didn't take this particular  
application beyond the exploratory phase, though - just confirmed that it could  
be done.

Again, this was back in the 3090 days - things may have changed since then.

    Dan


Article: 2211
Subject: Re: Xilinx Configuration Memory Hacking
From: henry@zoo.toronto.edu (Henry Spencer)
Date: Thu, 2 Nov 1995 16:23:41 GMT
Links: << >>  << T >>  << A >>
In article <472r2v$amu@aurns1.aur.alcatel.com> wolf@aur.alcatel.com writes:
>1. An open-architecture FPGA.  I am all for this.  While I am not 
>surprised Xilinx chooses to protect their architecture, I am a 
>little surprised that some other vendor hasn't pushed an open 
>architecture with partners to get a foothold in the business...

In fairness, there is one tricky problem:  customers who want to make
their products reverse-engineering-proof.  This is hard to do with the
Xilinx approach, in which the bit stream to program the FPGA *must* come
from an external source and hence is easily tapped.  To handle this in the
context of an open architecture, the chip needs to have either encryption
hardware or on-chip nonvolatile memory, neither of which is trivial.
-- 
The problem is, every time something goes wrong,   |       Henry Spencer
the paperwork is found in order... -Walker on NASA |   henry@zoo.toronto.edu


Article: 2212
Subject: altera problems
From: dne_tech@ix.netcom.com (Wayne Addy )
Date: 2 Nov 1995 17:49:08 GMT
Links: << >>  << T >>  << A >>
 I am using Altera EPS448 (WSI 5AM 448) in a horizontal (parallel) mode
of operation. The two chip tend to lose synchronization with each
other. Anybody ever have this problem? Any solutions? Altera claims
this isn't a problem. Note nReset pin as a resync is not an option in
this design Thanks!


Article: 2213
Subject: request for RTL netlists
From: tessier@curry.lcs.mit.edu (Russ Tessier)
Date: 2 Nov 1995 20:54:57 GMT
Links: << >>  << T >>  << A >>

I am in need of RTL circuit descriptions in Verilog or VHDL that may be 
synthesized by Synopsys for use in a multi-FPGA synthesis study.
Any datapath circuits or FPGA compute applications would be especially 
welcome. The larger the circuit the better.

I have several RTL Verilog circuit descriptions to offer in trade.

Thank you

Russ Tessier
MIT Lab for Computer Science




Article: 2214
Subject: Re: Xilinx XSI FPGA User Guide
From: peter@xilinx.com (Peter Alfke)
Date: 2 Nov 1995 21:46:41 GMT
Links: << >>  << T >>  << A >>
In article <12915@eagle.ukc.ac.uk>, sjba@ukc.ac.uk (S.J.B.Acock) wrote:

>Xilinx have recently refered me to
> a manual entitled The XSI FPGA User Guide. This I do not have,
>
Steven, the XSI ( Synopsys ) FPGA User Guide should have been shipped to you 
with any XSI update received after Dec. '94. Since you are still
using 5.0.0, you may not have the latest revision of the software.
Contact your distributor who supplies your updates, or if you are 
on the University Program, contact 
jason.feinsmith@xilinx.com.

Hope this helps,
Peter Alfke, Xilinx Applications


Article: 2215
Subject: Re: Xilinx XSI FPGA User Guide
From: Andy Gulliver <andy.gulliver@crossprod.co.uk>
Date: Thu, 02 Nov 1995 16:27:36 -0800
Links: << >>  << T >>  << A >>
Not a manual I've seen <FX: quickly scans data book shelves>....
not even with 5.1.1 (PC)  - mind you, that's the version that 
doesn't work with Windows95 or NT :-(

Regards

Andy Gulliver


Article: 2216
Subject: Re: altera problems
From: fliptron@netcom.com (Philip Freidin)
Date: Fri, 3 Nov 1995 00:57:56 GMT
Links: << >>  << T >>  << A >>
In article <47b0ak$ait@ixnews5.ix.netcom.com> dne_tech@ix.netcom.com (Wayne Addy ) writes:
> I am using Altera EPS448 (WSI 5AM 448) in a horizontal (parallel) mode
>of operation. The two chip tend to lose synchronization with each
>other. Anybody ever have this problem? Any solutions? Altera claims
>this isn't a problem. Note nReset pin as a resync is not an option in
>this design Thanks!

The Altera SAM448  ( a device designed at Altera to compete with devices
that I designed at AMD (29CPL151,'152, '154, ...) ), has some interesting
positives and negatives with respect to the 29CPLxxx parts. In particular,
the multiway branching was quite superior, while the restriction to having
it only work on the last 64 locations of 256 was (I'll be nice here) silly.

I personally believe the 29CPLxxx parts had a better instruction set.

A significant difference was also the input register for the test inputs.
The 29CPL parts have one, and the SAM does not. I am fairly sure that this
is the root of your problem.

If the two chips start out synchronized, and have identical uPrograms
( for the instruction section. output section can be different), and
have all their test inputs tied together, and are on the same clock,
then you are half way to having these parts slaved together. The other
half is that test inputs MUST ALWAYS meet the setup time requirements
which is quite long for the SAM, due to the lack of the input register.

Any test input that is asynchronous to the clock, or fails to meet the
setup AND hold requirements (MIN 0ns) will cause the behaviour you are
seeing, even if you have done all the things in the previous paragraph.

If your input signals are asynchronous, then a single input register
is not enough because of metastability, and you need to use at least
a two stage synchronizer, and then both SAMs need to take their test
inputs from the same second stage. Independent synchronizers for
each SAM (or the 29CPLxxx parts for that matter) will not work for
the same reasons.

My rumor mill has told me that AMD no longer builds 'my' 29CPLxxx
products, and Altera no longer makes the SAM parts. Does WSI still
make the SAM?

So that this article has some news group relevance, let me comment
that these days I build structures like the SAM448/29CPLxxx all the
time, and I do it in Xilinx XC4000 and XC4000E FPGAs. A particulary
nice side effect is that I get to build custom versions that are
more finely tuned to the application, than the standard parts ever
were, and the current reprogrammable designs are faster than the
older custom parts were.

Hope this is sufficient to get you statemachine to agree on the
sequence they should be following.

Philip Freidin.



Article: 2217
Subject: Re: AT&T vs. Xilinx
From: fliptron@netcom.com (Philip Freidin)
Date: Fri, 3 Nov 1995 01:14:09 GMT
Links: << >>  << T >>  << A >>
In article <30950B5E.541E@cybersecure.com> Patrick Drolet <pdrolet@cybersecure.com> writes:
>Stan Hodge wrote:
>> 
>> Hi.  I am currently evualuating a new FPGA technologies for our 
>> next generation product.  I have looked at Xilinx and AT&T.  The
>> new Xilinx software seem a bit more polished and easer to use 
>> than the AT&T neo stuff.  However, it seems that the part 
>> architecture from AT&T is much better.
>
>Actually, Xilinx tools seems better only if you wish to use their
>old parts: forget XC4000E series, or XC5200 series.  Their
>XACT 5.1.1 tools cannot merge a function generator with a flip-
>flop in the same CLB!

The Xilinx 5.1.1 software is the same as the quite stable and
(for Xilinx at least) relatively bug fre version 5.1
The only major difference is that the 5.1.1 release included the
newer Viewlogic Pro-Series, which is the windows base version of
their schematic and simulation software. Pro-Series is an extreme
step backwards, and I don't use it, and continue to use the older
DOS version called workview. For customers that want to use the
newer products like the XC4000E and XC5200, it is fairly simple
to ask Xilinx to be a beta site for the software. I've done this
and have been using the XC4000E since it was first announced, and
have COMPLETED over 100 designs. I have also done a few designs with
the XC5200 products. Your recomendation to 'forget' these new products
makes no sense to me.

>
>The "neo stuff" you are refering to is NeoCad.  AT&T use it.
>Actually, it is so good that Xilinx bought NeoCad a couple of 
>months ago.  Unfortunately, an despites of what Xilinx says, the 
>next version of XACT (6.0) won't be out until a year.  If you're
>ready to wait that long for good tools, choice is yours!

I suspect the reality is that V6.0 is much closer than a year away.

Philip Freidin



Article: 2218
Subject: Re: AT&T vs. Xilinx
From: husby@fnal.gov (Don Husby)
Date: 3 Nov 1995 17:22:53 GMT
Links: << >>  << T >>  << A >>
(Philip Freidin) fliptron@netcom.com wrote:
> The Xilinx 5.1.1 software is the same as the quite stable and
> (for Xilinx at least) relatively bug fre version 5.1
> The only major difference is that the 5.1.1 release included the
> newer Viewlogic Pro-Series, which is the windows base version of
> their schematic and simulation software. Pro-Series is an extreme
> step backwards, and I don't use it, and continue to use the older
> DOS version called workview.

I prefer the pro-series to the older workview.  It's much more pleasant to
use, and works well with Windows 3.1 (but NOT win95).  It doesn't require goofy 
memory managers and mice.  Since I use mostly NeoCad/ORCA now instead of 
Xilinx, I can stay in windows all the time, and switch back and forth from 
schematic to layout.  I dont use the simulation software so I don't know how 
pro-sim and view-sim compare.



Article: 2219
Subject: Re: FPGAs as a substitute for glue logic?
From: Derek Chang <dchang@san-jose.ate.slb.com>
Date: 3 Nov 1995 21:51:53 GMT
Links: << >>  << T >>  << A >>
What do you mean the design is different ?

You can do anything with an FPGA that discrete ICs
can do.

Derek




Article: 2220
Subject: FPGA => ASIC
From: daveb@iinet.net.au (David R. Brooks)
Date: Fri, 03 Nov 1995 23:13:44 GMT
Links: << >>  << T >>  << A >>
I have been asked to locate vendors who can take an FPGA-based design
(Xilinx, specifically), and migrate it to an ASIC for economy in large
volumes. I know of Xilinx' own Hardwire service, and Orbit
Semiconductor. What other sources would anyone recommend?

TIA

David R. Brooks <daveb@iinet.net.au>    Tel/fax. +61 9 434 4280



Article: 2221
Subject: US-NY-Syracuse Engineering positions
From: basevers@ix.netcom.com (Bas Evers)
Date: 4 Nov 1995 13:18:27 GMT
Links: << >>  << T >>  << A >>
Customer focus is the key to the R.K.B. Opto-Electronics
environment; we develop and manufacture high-performance quality-
assurance systems used in the paper industry. These systems are
equipped with CCD, IR or UV sensors.

We currently have the following positions available.

Service Engineer

     This is an opportunity for an individual with an Associate
     Degree in Electrical Engineering.
     
     Requires knowledge of digital and analog circuits, good
     communication and interpersonal skills.
     

Hardware / Software Engineer

     This is an excellent opportunity for an individual with a
     Bachelor's Degree plus a few years' experience, or a Master's
     Degree, in Electrical Engineering or Computer Science.
     
     Requires knowledge of Visual C++, DOS and Windows platform,
     Digital and Analog circuit design, Complex Programmable Logic
     Design, Field Programmable Gate Array, good communication and
     interpersonal skills. Some knowledge of Printed Circuit Board
     design, Graphical User Interfacing, Object-Oriented
     Programming, Digital Signal Processing, Ultra Violet-, Infra
     Red-, Charge Coupled Device- sensors, would be a plus.
     
All positions require some or frequent national and international
travel.

R.K.B. Opto-Electronics Inc. provides a supportive, cutting-edge
workplace in central New York, which offers an ideal climate (4
seasons), and endless recreational activities. Join us in our
growing success.
If you qualify, please forward your resume to:

Bas Evers
R.K.B. Opto-Electronics Inc.
P.O. Box 157
Syracuse, NY 13211
Fax: (315) 455 8216
E-Mail: BASEVERS@IX.NETCOM.COM

We look forward to hearing from you soon.


Article: 2222
Subject: Re: AT&T vs. Xilinx
From: garyk@svpal.svpal.org (George Noten)
Date: 5 Nov 1995 03:38:43 GMT
Links: << >>  << T >>  << A >>
Don Husby (husby@fnal.gov) wrote:
: I prefer the pro-series to the older workview.  It's much more pleasant to
: use, and works well with Windows 3.1 (but NOT win95).  It doesn't require goofy 
: memory managers and mice.  Since I use mostly NeoCad/ORCA now instead of 
: Xilinx, I can stay in windows all the time, and switch back and forth from 
: schematic to layout.  I dont use the simulation software so I don't know how 
: pro-sim and view-sim compare.

I think there is NO difference between DOS WorkView and the PROseries.  They
even have the same bugs since ViewLogic never has enough time to fix them 
(they release new products with the new bugs instead).  It applies both
to schematic entry and simulation.

Talking about Xilinx I can only tell that now I am using beta-release
software for 5200 series and it runs OK in a DOS window so I can easily
switch between schematic and layout.  Probably this is the only advantage
of the PROseries.



Article: 2223
Subject: simulation (.hst) file compatability
From: moby@kcbbs.gen.nz (Mike Diack)
Date: 5 Nov 95 07:57:23 GMT
Links: << >>  << T >>  << A >>
Something of a quandry, folks
If i do a PLDShell design, then simulate it, i get a .hst file
which i can view as w set of waveforms, expand, contract, swap
position & generally do what i want with...great stuff.
If i do a MACHXL design, i also get a .hst file which i cannot
expand, contract, swap etc when viewing...not so great stuff.
If i try to view the MACHXL generated file with the PLDSHELL
viewer, no dice.
Q : does there exist a more tractible viewer for MACHXL, or are
there commands not referenced in the doco that do what i want.
cheers
Mike


Article: 2224
Subject: Wanted motorola fpga mpa1036
From: nctnico@cistron.nl (Nico Coesel)
Date: Sun, 5 Nov 1995 14:44:04 LOCAL
Links: << >>  << T >>  << A >>
Wanted motorola fpga mpa1036

I'm looking for:
1 mpa1036 160 pin pqfp package
1 mpa1036 84 pin PLCC package

Email me price including shipment to the Netherlands (west Europe) and method of payment.
These devices are difficult to obtain over here.

Thanks in advance,
Nico Coesel




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