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
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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 10450

Article: 10450
Subject: FPGA market distribution
From: Arrigo Benedetti <arrigo@vision.caltech.edu>
Date: 19 May 1998 09:56:44 -0700
Links: << >>  << T >>  << A >>
Dear all,

I am looking for data on the global FPGA market distribution (e.g.
telecom, DSP, military, etc..) for a talk that I'm preparing. Does
anyone know a good source for this kind of information ?

thanks

-Arrigo
-- 
Arrigo Benedetti          o         e-mail: arrigo@vision.caltech.edu
Caltech, MS 136-93	 < >			phone: (626) 395-3695
Pasadena, CA 91125	 / \			fax:   (626) 795-8649
Article: 10451
Subject: Re: FPGA-based CPUs (was Re: Minimal ALU instruction set)
From: Rickman <spamgoeshere2@yahoo.com>
Date: Tue, 19 May 1998 13:08:04 -0400
Links: << >>  << T >>  << A >>
Mike Butts wrote:
> 
> There are a number of good reasons for doing a small CPU in
> an FPGA:
> 
> * Cost and size: With a single $20 chip, you get a CPU, which is
>     as fast or faster than common 8-bit or 16-bit embedded control
>     CPUs, *plus* you get all your peripheral logic for ports,
>     timers, UART, etc.  For example, the 68HC11 is still very
>     commonly used in small robotics apps, and it only runs at
>     a few MHz.  I expect at least 10 MHz from a carefully designed
>     FPGA-based CPU; 30 MHz or better with good pipelining.

What about the 50 MHz versions of the 8051 I see advertised? Surely this
is as fast as the custom CPU and would allow you to use a smaller FPGA.
I suspect that the total cost would be lower for a standard CPU/small
FPGA than for a bigger FPGA with custom CPU.

 
> * Performance: You can use reconfigurable computing techniques
>     to customize CPU instructions, and/or include "accelerator"
>     hardware to increase performance on your specific app.

Reconfigurable computing certainly has a lot of possiblities. But I
haven't seen very much to support it. I do know that it can be very
difficult to debug. Everyone knows how tricky it can be to debug self
modifing code. Think about how hard it would be to debug a self modifing
processor!! 
8-O

 
> * Education: The guts of the CPU and its peripherals are
>     completely open for inspection and modification.  It's
>     an ideal teaching tool for undergraduates to get hands-on
>     exposure to hardware architecture and systems design.

I think that is an excellent point. When I was in grad school, I wanted
to implement a simulation of a microcoded teaching CPU that they used
for a couple of classes. Until then it had only existed on paper. But
the simulation would not have allowed the students to modify or extend
the design easily. This would allow an EE student to play to his hearts
content, and he might actually learn something. ;-)

 
> * Satisfaction: Building a small computer from the gates up
>     through the instruction set architecture up through the
>     OS and compiler up to apps is a very satisfying exercise,
>     akin to building one's own small sailboat.  It can be a
>     potent antidote to the shrink-wrapped proprietary HW and
>     SW we generally must live with.
> 
>         --Mike

This is certainly a good reason to do a project in your spare time. The
education you would receive is not trivial either. It appears that a lot
of people have done this with a Forth implementation in mind. Do you
think they are doing this because of the personal satisfaction
motivation or do you think they have commercial motivations in mind?


-- 

Rick Collins

rickman@XYwriteme.com

remove the XY to email me.
Article: 10452
Subject: Re: Building signal delays inside an FPGA
From: Rickman <spamgoeshere2@yahoo.com>
Date: Tue, 19 May 1998 14:26:20 -0400
Links: << >>  << T >>  << A >>
Rita Madarassy wrote:
> 
> You can use unbonded pads to add delay like setup in the following manner:
> 
> ->---------------------[OBUF]-----[UPAD]----------[IBUF]----->
> 
> The delayed signal is the output of the IBUF. This should add at least
> 7ns of delay in a 4000XL-09 device.
> If you want to get an idea of the min delay expect a
> conservative 50% out of the max delay reported in the static timing
> analyzer.
> 

Whoa!!! Just because the timning analyser reports a delay of 7 ns
doesn't mean that you will get a 7 ns delay. That is an upper bound on
the delay. In any real chip it will be faster and as Xilinx produces
more mature parts, it may get MUCH faster. That is why they try to pound
on you to never, never assume minimum prop delays. Xilinx doesn't even
publish minimum delays. 

That one of the reasons behind the push to use synchronous designs. A
fully synchronous design can be proven to work simply by performing
logic analysis and a static timing analysis. If a signal runs too fast,
the clock makes it wait at the next register. But if you are doing
asynchronous design, you can't count on a minimum delay. So you have to
design your logic without feedback, or use a very complex analysis to
avoid race conditions. I learned how to do this in school, but in 20
years I have only seen it done once. No one else is willing to go the
extra mile (or ten) to be able to make sure it will work. 


-- 

Rick Collins

rickman@XYwriteme.com

remove the XY to email me.
Article: 10453
Subject: Re: Building signal delays inside an FPGA
From: "Richard Iachetta" <iachetta@us.ibm.com>
Date: 19 May 1998 18:27:49 GMT
Links: << >>  << T >>  << A >>
Rita   Madarassy <madarass@cats.ucsc.edu> wrote in article
<6jscep$gm8@darkstar.ucsc.edu>...
> You can use unbonded pads to add delay like setup in the following manner:
> 
> 
> 
> ->---------------------[OBUF]-----[UPAD]----------[IBUF]----->
> 
> 
> The delayed signal is the output of the IBUF. This should add at least
> 7ns of delay in a 4000XL-09 device.
> If you want to get an idea of the min delay expect a
> conservative 50% out of the max delay reported in the static timing
> analyzer.
> 

Rita,  I don't think you noticed that Alfredo needs to delay the signal 1 to 3
microseconds.

> In article <35614A77.D253C2E3@uv.es>,
> Alfredo Rosado  <alfredo.rosado@uv.es> wrote:
> >Hi,
> >    I am trying to build some kind of architecture to delay a signal
> >(typical delay ranging from 1 to 3 useconds). I have thought of doing it
> >with chained flip-flops, but if I have a fast clock signal, it will
> >waste a big amount of resources. Also, a FIFO could be an option, but it
> >would spend lots of resources as well.
> >    Is there any other possibility to do it?.
> >    Thanks in advance.

Alfredo, 

You didn't mention some of the details of how you needed this signal to be
delayed.  For example, do you need some active edge to be delayed by 1us or do
you need every transition of the signal (referenced to the fast clock) to
appear somewhere 1us later?  If its the first case where the signal transitions
to an active state and you don't care what the signal does after that for 1us
until you process it, then the suggestion to use a counter made by another
poster will work great.  Load the counter when the signal transitions, then
your delayed signal is created by logic that detects when the counter counts
down to 0.  However, if its the second case, where every transition must show
up 1 to 3 us later, then you have no choice (that I can see) but to chain
flip-flops or use a fifo like you were saying.  You can't even send slower
clocks to that chain to save resources because that would cause you to miss
some transitions.  Hope this helps.

-- 
Rich Iachetta
IBM Corporation
iachetta@us.ibm.com


Article: 10454
Subject: Xilinx Foundation Student Edition
From: milne@hi.com (Ewan D. Milne)
Date: 19 May 1998 18:53:47 GMT
Links: << >>  << T >>  << A >>
Back in April, Peter Alfke wrote:
>Prentice Hall publishes and sells the "Xilinx Foundation Student
>Edition" which supports all XC9500 devices and all XC4000-type devices
>up to 8k gates today, 10k gates in the next upgrade.
>...

The book and CD appear to be available from amazon.com and also
at Quantum Books in Cambridge, MA.  I am considering purchasing
this book and software, but was wondering when the "next upgrade"
would be available and how one would be able to tell which version
of the software was included.  I would like to have the capability
to target a design for the XC4010E device, but would be more inclined
to go ahead and purchase the current version if the next upgrade
will not take place within the next year.

Can anyone (Peter?) shed any light on this subject?

Thank you in advance for your replies.

-Ewan
Article: 10455
Subject: this is only a test
From: rk <stellare@erols.com>
Date: Tue, 19 May 1998 15:09:05 -0400
Links: << >>  << T >>  << A >>
this is a test, please ignore.

new news reader

rk

Article: 10456
Subject: Re: Building signal delays inside an FPGA
From: Ray Andraka <no_spam_randraka@ids.net>
Date: Tue, 19 May 1998 15:27:19 -0400
Links: << >>  << T >>  << A >>
If you are using xilinx 4K series (also spartan or virtex), use the CLB
memories as shift registers.  This gives you up to 17x (not quite due to
the counter logic) the density of a design that just uses the CLB
flip-flops.  Word-wide delay queues occur frequently in pipelined DSP
hardware.  The 4K's ability to implement a compact delay queue is one of
the reasons I prefer the Xilinx 4K over its competitors for signal
processing applications.  Xilinx has an app-note detailing the use of
the clb ram for long shift registers.  I think it is XAPP-52.  If you
can live with an inertial delay, using a counter as Ed suggested will be
more compact for large clock count delays.


Ed McCauley wrote:
> 
> Alfredo,
> 
> With what degree of precision must you delay your signal?  In the
> crudest terms, lets say you have three flops (in serial) each clocking
> at a 1 us rate: What goes in comes out 3 us later.  OK, that's probably
> not what you'd want BUT, how about 30 flops (or FIFO stages) clocking at
> 0.3 us?  You get the idea.  More precision / resolution --> more flops
> at a higher rate.
> 
> Plan 'B': use an counter!  On the occurrence of your signal, release a
> counter that was held in reset.  After N clocks of frequency, the count
> value reaches N which then signals the completion of your delay period.
> 
> To get a bit more technical, the latter approach would implement an
> inertial delay the former, a transport dely.
> 

> Alfredo Rosado wrote:
> >
> > Hi,
> >     I am trying to build some kind of architecture to delay a signal
> > (typical delay ranging from 1 to 3 useconds). I have thought of doing it
> > with chained flip-flops, but if I have a fast clock signal, it will
> > waste a big amount of resources. Also, a FIFO could be an option, but it
> > would spend lots of resources as well.
> >     Is there any other possibility to do it?.
> >     Thanks in advance.

-- 
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka

The Andraka Consulting Group is a digital hardware design firm
specializing in high performance FPGA designs for digital signal
processing, computing and control applications.
Article: 10457
Subject: Re: Minimal ALU instruction set.
From: Ray Andraka <no_spam_randraka@ids.net>
Date: Tue, 19 May 1998 15:41:53 -0400
Links: << >>  << T >>  << A >>
John Eaton wrote:

> Many FPGA's tout speeds up into the 100 Mhz's. It sounds great until you you realize
> and the only design that will actually run that fast is a shift register. This makes
> FPGA's the ideal canidate for a CPU design using serial logic. With serial logic all
> registers are serial shift registers and you can load anyone with a single bit mux.
> A 8 bit Full adder is simply a one bit full adder stage and one carry flip flop.
> It a great speed/logic trade off.
> 
> John Eaton

Bit serial processing also translates to the routing structure nicely. 
Most connections are very local, so the delays associated with long runs
and high fanouts don't exist, which means you can often get close to the
word rates of a fully parallel processor.  The big thing to watch for if
you pack alot of serial logic into one part is the power dissipation. 
The serial logic can often be clocked at or near the advertised toggle
frequency, and it is possible to present data that will cause nearly
every flop in the design to toggle on every clock.

-- 
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka

The Andraka Consulting Group is a digital hardware design firm
specializing in high performance FPGA designs for digital signal
processing, computing and control applications.
Article: 10458
Subject: Re: Xilinx Foundation Student Edition
From: "Steven K. Knapp" <sknapp@optimagic.com>
Date: Tue, 19 May 1998 13:56:26 -0700
Links: << >>  << T >>  << A >>
Xilinx has provided updated and complete information about Xilinx Student
Edition upgrades to VHDL, Verilog, F1.4, F1.5, and XC4010E/XL devices at
http://www.xilinx.com/programs/xse1.htm#FUO .

-----------------------------------------------------------
Steven K. Knapp
OptiMagic, Inc. -- "Great Designs Happen 'OptiMagic'-ally"
E-mail:  sknapp@optimagic.com
   Web:  http://www.optimagic.com
-----------------------------------------------------------


Ewan D. Milne wrote in message <6jskfr$9up$1@sunfish.hi.com>...
>Back in April, Peter Alfke wrote:
>>Prentice Hall publishes and sells the "Xilinx Foundation Student
>>Edition" which supports all XC9500 devices and all XC4000-type devices
>>up to 8k gates today, 10k gates in the next upgrade.
>>...
>
>The book and CD appear to be available from amazon.com and also
>at Quantum Books in Cambridge, MA.  I am considering purchasing
>this book and software, but was wondering when the "next upgrade"
>would be available and how one would be able to tell which version
>of the software was included.  I would like to have the capability
>to target a design for the XC4010E device, but would be more inclined
>to go ahead and purchase the current version if the next upgrade
>will not take place within the next year.
>
>Can anyone (Peter?) shed any light on this subject?
>
>Thank you in advance for your replies.
>
>-Ewan


Article: 10459
Subject: Re: XC5200s and Foundation 1.4
From: Bill Warner <wtw@sepulcher.engr.sgi.com>
Date: 19 May 1998 21:25:06 GMT
Links: << >>  << T >>  << A >>
Rickman <spamgoeshere2@yahoo.com> wrote:
> Graham Eastwood wrote:
> This sounds very scary to me. What happens if you just bought the M1
> tool and you don't have the XACT stuff? You also wouldn't even know that
> this is not normal!!! The M1 tools have been out for about 5 or 6 months
> now. Is anyone working on this???
> 
> I assume that this is not a problem for any of the XC4000 families?

My group has been pleased with M1.4 for XC4000XL (using Syplify for
synthesis at least.)  Some of our designs have been moved from XACT,
with no problems.

Thanks,
-- 
Bill Warner                 Silicon Graphics                wtw@sgi.com
Article: 10460
Subject: Archives for comp.arch.fpga?
From: Chris Lee <p_halpern@earthlink.net>
Date: Tue, 19 May 1998 15:51:58 -0700
Links: << >>  << T >>  << A >>
I wonder if someone could point me to an archive for this newsgroup that
would contain old posts from 1990 plus or minus a couple of years.  I
have had no luck with Deja News (only goes back to 1995); I can't find
an FAQ for this group, and the super.org archive that some of the web
pages point to is 404 Not Found.  I would appreciate any help in finding
a comp.arch.fpga archive--thanx in advance!

Chris
Article: 10461
Subject: FPGA/Programmable Logic/Reconfigurable Computing Conferences in May-June 1998
From: "Steven K. Knapp" <sknapp@optimagic.com>
Date: Tue, 19 May 1998 16:41:55 -0700
Links: << >>  << T >>  << A >>
The following conferences on FPGAs, programmable logic, reconfigurable
computing, or related topics will be happening during the remained of May
and June, 1998.  For additional information, visit the Conferences section
on The Programmable Logic Jump Station at
http://www.optimagic.com/conferences.html.

June, 1998 (http://www.optimagic.com/conferences.html#Jun98)
==========
The Sixth FPGA/PLD Design Conference & Exhibit, 24-26 June, 1998, Pacifico
Yokohama, Yokohama, Japan.

Design Automation Conference (DAC'98) 15-19 June, 1998, Moscone Center, San
Francisco, California, USA.

Synplicity Users Group
14 June 1998, ANA Hotel, San Francisco, CA, USA.

Field-Programmable Devices (FPD'98) Conference
The 5th Canadian Workshop of Field-Programmable Devices.
7-10 June 1998, Montréal, Québec, Canada.

May, 1998 (http://www.optimagic.com/conferences.html#May98)
=========
Lattice VHDL and In-System Programming Training Seminar
27/28 May, 1998, Unterschleissheim, Germany

Atmel's New AT40K FPGA, 21 May, 1998, 10:00 Pacific time. Web-based seminar
requires pre-registration and download.

-----------------------------------------------------------
Steven K. Knapp
OptiMagic, Inc. -- "Great Designs Happen 'OptiMagic'-ally"
E-mail:  sknapp@optimagic.com
   Web:  http://www.optimagic.com
-----------------------------------------------------------



Article: 10462
Subject: Re: Turbo bit in Altera 7000
From: "Matthew Morris" <mmorris@no_spam.carrieraccess.com>
Date: Tue, 19 May 1998 18:42:44 -0600
Links: << >>  << T >>  << A >>
Beware the TURBO bit..

If you turn off the turbo bit, a timing simulation will not check setup and
hold
you could have all sorts of violations and it wouldn't tell you.

This is of course a feature, "bug", in 8.2 and below. I haven't checked 8.3
to see if they fixed it yet.

Matt


Ying C. wrote in message <6jpo40$iat$1@agate.berkeley.edu>...
>
>
>If you click on the warning message and click on "Help on Message" in
>Max+plus II, it will tell you that for 7000E device, there is only 1 bit
>which controls slow slew rate/turbo hit. Hence, either slow slew rate or
>turbo bit (not both) needs to be enabled.
>
>By the way, Global Project Logic Synthesis will affect the whole design;
>use Logic option if you want to do it pin by pin.
>
>Regards,
>
>Ying
>ying@csua.berkeley.edu
>
>In article <355FFCF3.4BF41553@cern.ch>,
>Flemming JENSEN  <Flemming.Jensen@cern.ch> wrote:
>>Dear everybody
>>
>>I am trying to switch off the turbo bit in my Altera 7128E circuit, but
>>I can't make it work. I try to set the global settings under "Global
>>project logic synthesis" and here I choose the "define synthesis style".
>>No matter how I set the turbo bit it is not switched off. Either I get
>>the warning "Project has conflicting defaults for turbo bit and slow
>>slew rate.
>>
>>My problem is that I want to reduce the switching speed, because they
>>might cause some problems in my design.
>>
>>Thank you for taking the time for reading this.
>>
>>Flemming
>
>


Article: 10463
Subject: Re: Building signal delays inside an FPGA
From: murray@pa.dec.com (Hal Murray)
Date: 20 May 1998 02:48:38 GMT
Links: << >>  << T >>  << A >>
In article <35614A77.D253C2E3@uv.es>, Alfredo Rosado <alfredo.rosado@uv.es> writes:

>     I am trying to build some kind of architecture to delay a signal
> (typical delay ranging from 1 to 3 useconds). I have thought of doing it
> with chained flip-flops, but if I have a fast clock signal, it will
> waste a big amount of resources. Also, a FIFO could be an option, but it
> would spend lots of resources as well.

What sort of signal are you trying to delay and/or how accurately does
the output of the delay have to follow the input?

If you just need to delay an occasional rising edge, then you
can do that with a counter.

-- 
These are my opinions, not necessarily my employers.
Article: 10464
Subject: Re: FPGA-based CPUs (was Re: Minimal ALU instruction set)
From: Mike Butts <mbutts@realizer.com>
Date: Wed, 20 May 1998 04:57:15 +0000
Links: << >>  << T >>  << A >>
Rickman wrote:

> What about the 50 MHz versions of the 8051 I see advertised? Surely this
> is as fast as the custom CPU and would allow you to use a smaller FPGA.
> I suspect that the total cost would be lower for a standard CPU/small
> FPGA than for a bigger FPGA with custom CPU.

No question.  Mostly the point of this little exercise is to do
CPU+logic
with the smallest FPGA.  Total cost of FPGA + SW = $20.  Plus a
hardwired
CPU would miss out on the reconfigurable processor angle, and would
place lower on the education and satisfaction scales.  In any serious
commercial effort I don't think there's any question that silicon
is best spent on a fast hard-wired CPU, tightly coupled to FPGA.

> Reconfigurable computing certainly has a lot of possiblities. But I
> haven't seen very much to support it. I do know that it can be very
> difficult to debug. Everyone knows how tricky it can be to debug self
> modifing code. Think about how hard it would be to debug a self modifing
> processor!!

Oh, no, that's almost never the idea.  Nearly all reconfigurable
computing
applications are compiled, or should I say cross-compiled, on
conventional
computers.  One or more pre-compiled FPGA binaries are downloaded at
run time to get the computing done.  Even that's hard enough.  Someday
we 
hope to have FCCMs doing their own place and route jobs at high speed, 
but even that is still a research topic.

> It appears that a lot
> of people have done this with a Forth implementation in mind. Do you
> think they are doing this because of the personal satisfaction
> motivation or do you think they have commercial motivations in mind?

Oh, gee, you'd have to ask on comp.lang.forth, but I'm pretty sure it's
99% personal satisfaction.  The author of SOD32, the Forth system that
the folks in Hong-Kong used for their FPGA-based Forth processor
<http://www.xs4all.nl/~lennartb/forth.html> says he "wrote it just for
the hack value".  (Not forgetting that most good things in computing got
started for just their hack value.)

     --Mike
Article: 10465
Subject: 44 pins size fpga or cpld
From: eng50195@leonis.nus.sg (Ho Voon Yee)
Date: 20 May 1998 08:01:43 GMT
Links: << >>  << T >>  << A >>
Hi, pardon my ignorance, but is there
any 44-pins sized fpga or cpld around  that contains about
7000 gates?



Thanks in advance
Article: 10466
Subject: Re: FPGA-based CPUs (was Re: Minimal ALU instruction set)
From: z80@ds1.com (Peter)
Date: Wed, 20 May 1998 09:58:25 GMT
Links: << >>  << T >>  << A >>

>What about the 50 MHz versions of the 8051 I see advertised? Surely this
>is as fast as the custom CPU and would allow you to use a smaller FPGA.
>I suspect that the total cost would be lower for a standard CPU/small
>FPGA than for a bigger FPGA with custom CPU.

I was recently involved in a project which was going to go to 500k-1M
pieces per year, obviously to an ASIC, and we found that under about
1M pieces a *separate* CPU was always cheaper.

Eventually, the company running this got into a partnership with a
major Japanese chip vendor (who makes various CPUs) and this Jap firm
was so interested in making this ASIC that they chucked in one of
their CPUs very cheaply. Only then it made sense.

As the volumes go up, the FPGA gets cheaper, but the external CPU gets
cheaper too.

The exception to the above is when there is no physical space for a
CPU.



Peter.

Return address is invalid to help stop junk mail.
E-mail replies to zX80@digiYserve.com but
remove the X and the Y.
Article: 10467
Subject: Re: Archives for comp.arch.fpga?
From: David Pashley <David@fpga.demon.co.uk>
Date: Wed, 20 May 1998 11:30:16 +0100
Links: << >>  << T >>  << A >>
In article <35620D0E.786B@earthlink.net>, Chris Lee
<p_halpern@earthlink.net> writes
>I wonder if someone could point me to an archive for this newsgroup that
>would contain old posts from 1990 plus or minus a couple of years.  I
>have had no luck with Deja News (only goes back to 1995); I can't find
>an FAQ for this group, and the super.org archive that some of the web
>pages point to is 404 Not Found.  I would appreciate any help in finding
>a comp.arch.fpga archive--thanx in advance!
>
Chris,

There's no "official" faq, although if you look through recent threads,
there are plenty of useful websites around.

I started contributing here in late 1993 IIRC, at which point the group
was very new, running at just a couple of postings per week, and mainly
about parallel computer architectures using multiple FPGAs, which was
the original purpose.

I'm unaware of any earlier archive, but there's probably little to find
before 1995 anyway.

-- 
David Pashley                 <
 ------------------------  <  <  <  ---------- Email: david@fpga.demon.co.uk
| Direct Insight Ltd    <  <  <  <  >            Tel: +44 1280 700262      |
|                          <  <  <               Fax: +44 1280 700577      |
 ---------------------------  <  ------------------------------------------
Article: 10468
Subject: Re: Archives for comp.arch.fpga?
From: Markus.Wannemacher@FernUni-Hagen.De (Markus Wannemacher)
Date: 20 May 1998 11:31:25 GMT
Links: << >>  << T >>  << A >>
Chris Lee (p_halpern@earthlink.net) wrote:
: I wonder if someone could point me to an archive for this newsgroup that
: would contain old posts from 1990 plus or minus a couple of years.  I
: have had no luck with Deja News (only goes back to 1995); I can't find
: an FAQ for this group, and the super.org archive that some of the web
: pages point to is 404 Not Found.  I would appreciate any help in finding
: a comp.arch.fpga archive--thanx in advance!

Hi Chis,

The super.org archive includes threads from July 94 to Aug. 96
There is no more support for this archive, so it is in bad
condition. The address is:

ftp://www.super.org/pub/www/FPGA/caf.html

Be sure to use "ftp", not "http".

The links on this page are not correct. Use allways
ftp://www.super.org/pub/www/FPGA as the base address
and add manually the file name, e.g. 
ftp://www.super.org/pub/www/FPGA/thread_old.html

Additionally, I do maintain a newer archive with all threads
starting from Febr. 1997:

http://www.fernuni-hagen.de/IT/FPGA/news/

Good luck

Markus Wannemacher

Article: 10469
Subject: Re: FPGA-based CPUs (was Re: Minimal ALU instruction set)
From: amos@nsof.co.il-n0spam
Date: 20 May 1998 14:38:30 GMT
Links: << >>  << T >>  << A >>
Mike Butts <mbutts@realizer.com> writes:

>There are a number of good reasons for doing a small CPU in
>an FPGA:

>* Cost and size: (...)
>* Performance: (...)
>* Education: (...)
>* Satisfaction: (...)

You've left out: *Versatility: Once the design is made, it's rather easy
to retarget it to the next version of chips, debug, add features, etc. 

--
	Amos Shapir
Paper: nSOF Parallel Software, Ltd.
       Givat-Hashlosha 48800, Israel
Tel: +972 3 9388551   Fax: +972 3 9388552        GEO: 34 55 15 E / 32 05 52 N
Article: 10470
Subject: Re: FPGA-based CPUs (was Re: Minimal ALU instruction set)
From: "Steven K. Knapp" <sknapp@optimagic.com>
Date: Wed, 20 May 1998 08:24:54 -0700
Links: << >>  << T >>  << A >>
Those interested in a CPU+FPGA for fun or education should take a look at
the relatively inexpensive board offered by XESS Corp.
(http://www.xess.com/FPGA/ho05000.html).  It has an 8031, a 32K SRAM, and
either an FPGA or CPLD (your choice).  Prices range from US$160 to US$350,
depending on the FPGA and whether you qualify for an educational discount.

The XESS board is also supported by the Xilinx Student Edition book, which
contains the Xilinx design software on CD-ROM.  The book retails for $87 and
is available for sale on-line (http://www.optimagic.com/books.html#Xilinx).

-----------------------------------------------------------
Steven K. Knapp
OptiMagic, Inc. -- "Great Designs Happen 'OptiMagic'-ally"
E-mail:  sknapp@optimagic.com
   Web:  http://www.optimagic.com
-----------------------------------------------------------

Mike Butts wrote in message <356262AB.1CA1BC6D@realizer.com>...
>Rickman wrote:
>
>> What about the 50 MHz versions of the 8051 I see advertised? Surely this
>> is as fast as the custom CPU and would allow you to use a smaller FPGA.
>> I suspect that the total cost would be lower for a standard CPU/small
>> FPGA than for a bigger FPGA with custom CPU.
>
>No question.  Mostly the point of this little exercise is to do
>CPU+logic
>with the smallest FPGA.  Total cost of FPGA + SW = $20.  Plus a
>hardwired
>CPU would miss out on the reconfigurable processor angle, and would
>place lower on the education and satisfaction scales.  In any serious
>commercial effort I don't think there's any question that silicon
>is best spent on a fast hard-wired CPU, tightly coupled to FPGA.
>
>> Reconfigurable computing certainly has a lot of possiblities. But I
>> haven't seen very much to support it. I do know that it can be very
>> difficult to debug. Everyone knows how tricky it can be to debug self
>> modifing code. Think about how hard it would be to debug a self modifing
>> processor!!
>
>Oh, no, that's almost never the idea.  Nearly all reconfigurable
>computing
>applications are compiled, or should I say cross-compiled, on
>conventional
>computers.  One or more pre-compiled FPGA binaries are downloaded at
>run time to get the computing done.  Even that's hard enough.  Someday
>we
>hope to have FCCMs doing their own place and route jobs at high speed,
>but even that is still a research topic.
>
>> It appears that a lot
>> of people have done this with a Forth implementation in mind. Do you
>> think they are doing this because of the personal satisfaction
>> motivation or do you think they have commercial motivations in mind?
>
>Oh, gee, you'd have to ask on comp.lang.forth, but I'm pretty sure it's
>99% personal satisfaction.  The author of SOD32, the Forth system that
>the folks in Hong-Kong used for their FPGA-based Forth processor
><http://www.xs4all.nl/~lennartb/forth.html> says he "wrote it just for
>the hack value".  (Not forgetting that most good things in computing got
>started for just their hack value.)
>
>     --Mike


Article: 10471
Subject: Re: Archives for comp.arch.fpga?
From: "Steven K. Knapp" <sknapp@optimagic.com>
Date: Wed, 20 May 1998 08:42:20 -0700
Links: << >>  << T >>  << A >>
We maintain a partial FAQ on programmable logic on The Programmable Logic
Jump Station (http://www.optimagic.com/faq.html).

We also have links to the comp.arch.fpga newsgroup and archives on our
Newsgroups page at http://www.optimagic.com/newsgroups.html.  Special thanks
to Markus Wannemacher for pointing out the problem with links to the older
comp.arch.fpga archive.

-----------------------------------------------------------
Steven K. Knapp
OptiMagic, Inc. -- "Great Designs Happen 'OptiMagic'-ally"
E-mail:  sknapp@optimagic.com
   Web:  http://www.optimagic.com
-----------------------------------------------------------

Chris Lee wrote in message <35620D0E.786B@earthlink.net>...
>I wonder if someone could point me to an archive for this newsgroup that
>would contain old posts from 1990 plus or minus a couple of years.  I
>have had no luck with Deja News (only goes back to 1995); I can't find
>an FAQ for this group, and the super.org archive that some of the web
>pages point to is 404 Not Found.  I would appreciate any help in finding
>a comp.arch.fpga archive--thanx in advance!
>
>Chris


Article: 10472
Subject: XC300 ROM
From: "A. Kasd" <kasd@ntua.gr>
Date: Wed, 20 May 1998 21:36:08 +0300
Links: << >>  << T >>  << A >>
Hi,
I wonder if somebody has used any ROM in
the XC3000 series FPGAS.....
Looking in Xilinx documentation of the
UNIFIED libraries there is no such feature.
Although, in their site there is a patch that
provides schematic files (Viewlogic) for
16x2 and 32x1 ROMs for XC3000 along
with the XNF files.....
I tried to instantiate in VHDL code these
XNFs and I get a PAR error in the M1.4
placement tool saying something like: F and G
LUTs in the CLBMAP have 5 inputs instead
of 4....and this comes from the above XNFs !!!
Can anybody provide some help?

Thanks in advance

P.S.: Removing from the XNF file the CLBMAP
section, the placement goes on normally (?) !!!

Article: 10473
Subject: Re: Minimal ALU instruction set.
From: arnim@atlantis.actrix.gen.nz (Arnim Littek)
Date: 20 May 98 20:39:36 GMT
Links: << >>  << T >>  << A >>
In article <Et568q.1zq@world.std.com>,
Joseph H Allen <jhallen@world.std.com> wrote:
>If I were using the XC4000 series they might be workable because of the
>relatively large stack cache.  But if I'm going to assume an XC4000, I might
>as well assume wider memory paths, implement a MIPS or ARM clone and then
>have GCC available for it.


Since your original target was 5202, ie. bottom end, and having enough RAM
for stack cache is now arising, the newer baby Spartan parts might fit the
bill, as being in the same league, price/size-wise, but also having the
on-board distributed RAM.  Dunno if the toy tools available in book/CD
formats include the Spartan parts as targets yet, though.

FWIW,

Arnim.
-- 
Arnim Littek                                    arnim@actrix.gen.nz
Actrix Networks Ltd.                            fax +64-4-801-5335
uucp/PPP/SLIP/BBS accounts                      tel +64-4-801-5225
Article: 10474
Subject: Re: Building signal delays inside an FPGA
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Wed, 20 May 1998 17:39:04 -0700
Links: << >>  << T >>  << A >>
Alfredo Rosado wrote:

> Hi,
>     I am trying to build some kind of architecture to delay a signal
> (typical delay ranging from 1 to 3 useconds). I have thought of doing
> it
> with chained flip-flops, but if I have a fast clock signal, it will

You can build a virtual shift register in the synchronous RAM of the
XC4000E or XC4000XL devices, which gives you 32 bits per CLB.

Or you can use a presettable synchronous counter. There are lots of ways
of doing this, depending on your constraints.

You will never get close to microseconds by just concatenating logic
delays of a few nanoseconds each.

Peter Alfke, Xilinx Applications



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
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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