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 6525

Article: 6525
Subject: Re: FAQ's / Documentation sites wanted
From: hauck@ece.nwu.edu (Scott A. Hauck)
Date: Fri, 30 May 1997 21:47:25 -0500
Links: << >>  << T >>  << A >>
In article <5mn3hr$sv2@ftp.ee.vill.edu>, venkat@chaos.ee.vill.edu (K. S.
Venkatraman) wrote:

> Hi,
> 
> I need some documentation sites on FPGAs, their uses, advantages etc. Can 
> anyone provide a resourceful URL?
> 
> Thanks,
> Venkat.

I have two surveys on the uses of FPGAs in reconfigurable systems.  They
are available in the directory http://www.ece.nwu.edu/~hauck/publications/
The hardware/applications survey is mFPGAhard.ps or mFPGAhard.pdf
The software survey is mFPGAsoft.ps or mFPGAsoft.pdf
The PDF files are Adobe Acrobat, the PS files are postscript.

Scott
+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
|               Scott A. Hauck, Assistant Professor                         |
|  Dept. of ECE                        Voice: (847) 467-1849                |
|  Northwestern University             FAX: (847) 467-4144                  |
|  2145 Sheridan Road                  Email: hauck@ece.nwu.edu             |
|  Evanston, IL  60208                 WWW: http://www.ece.nwu.edu/~hauck   |
+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
Article: 6526
Subject: Re: VHDL PCI FPGA Implementation
From: Dave Greenfield <david_greenfield@altera.com>
Date: Fri, 30 May 1997 21:39:50 -0700
Links: << >>  << T >>  << A >>
Relative to compliance:

On the clock pin capacitance issue, Altera has tested and
recharacterized the FLEX 10K products; errata will be published soon
listing maximum at 12pF (within spec).

On the two pin approach - agree.  Trade-off Altera provides is 0-wait
state pin-sharing design or 1-wait state single pin (fully compliant)
design.  Current MegaCore function went with performance.  Future
MegaCore function will provide 1-wait state single pin design and
customers can certainly implement this functionality today.

Since when did we officially become the boys in blue?

Dave Greenfield
Altera Corporation
__________________________________

Stuart Clubb wrote:
On Thu, 29 May 1997 20:29:00 GMT, aquantz@ibm.net (Aaron Quantz)
wrote:

>Ahhhh.. But if you have seen the news lately you'll notice the Altera
>IS fully PCI compliant. The've just released a core product.

If by a core product you mean the pci_a megacore function, then I am
sorry, but I have to disagree.

At: http://www.altera.com/html/products/mc-pci_a.html#comp

They state compliance with REV2.1, yet list just 3 base parameters
clk2q, setup, and 33MHz clock. I have seen no electrical checklist
with a nice row of tick boxes.

Read the documentation, it's only a megabyte of pdf. Then read the PCI
spec. and compare.

I refer you again to page 6 of dsdma_01.pdf from the literature
section. Altera say they have two pins on three different PCI signals.


The two pin approach undoubtedly breaks the spec of 10pF maximum load
on a pin. The Altera solution gives a maximum 20pF, so they fail.

Another spec requirement is for the clock pin to have sub 12 pF,
Altera is listed as maximum 15pF. Fail again

Altera is not compliant. Of course they could change their
specifications, like they did with the EAB, that would be up to them.
Until they do, and ship guaranteed product, the pci_a core cannot
claim to be compliant.

Of course, it_probably_works, but so does a 6 nS SRAM in a 5 nS design
requirement, MOST OF THE TIME. Those who would choose to follow such
dubious engineering practices do so at their own, and company's, risk.

Anyone want to disagree?

Still silence from the boys in blue.

Stuart
Article: 6527
Subject: Re: VHDL PCI FPGA Implementation
From: Brad Taylor <brad@gigaops.com>
Date: Fri, 30 May 1997 23:53:32 -0700
Links: << >>  << T >>  << A >>
Stuart Clubb wrote:

> Altera say they have two pins on three different PCI signals.
> 
> The two pin approach undoubtedly breaks the spec of 10pF maximum load
> on a pin. The Altera solution gives a maximum 20pF, so they fail.
> 
> Another spec requirement is for the clock pin to have sub 12 pF,
> Altera is listed as maximum 15pF. Fail again
> 
> Altera is not compliant. Of course they could change their
> specifications, like they did with the EAB, that would be up to them.
> Until they do, and ship guaranteed product, the pci_a core cannot
> claim to be compliant.
> 
> Of course, it_probably_works, but so does a 6 nS SRAM in a 5 nS design
> requirement, MOST OF THE TIME. Those who would choose to follow such
> dubious engineering practices do so at their own, and company's, risk.
> 
> Anyone want to disagree?
> 
>

How does Altera get away with such crap?  Can't the PCI police put them
in jail for lying?  Beware of companies which don't understand the
difference between a working implementation in the lab and a validated
implementation which meets worst case specs.  If this is really their
attitude, it calls into question all of their 'guaranteed' specs.  After
looking at the way they count gates and implemant benchmarks I'm
starting to detect a pattern here.

This is all they give you as far as compliance is concerned:

ALTERA> Table 3 describes timing elements for FLEX 10K devices that are
ALTERA> compliant with the PCI Special Interest Group's (PCI-SIG) PCI
ALTERA> Local Bus Specification, revision 2.1. 
ALTERA> 
ALTERA> Table 3. Timing Elements for the EPF10K30RC240-3 Device
ALTERA>                  Timing Element        
Specification                                        
ALTERA>                  Clock-to-output time    11 ns
ALTERA>                  Set-up time              7 ns
ALTERA>                  Maximum clock rate      33 Mhz
                                                       

What ever the above means, it has very little to do with being legal on
the PCI bus. There are literally hundreds of specs and this tells me 
only about the three that are legal. Maybe the following quote from
from  
the licence agreement explains it a little better.


  
ALTERA> ALTERA DOES NOT WARRANT THAT THE FUNCTIONS
ALTERA> CONTAINED IN THE PROGRAMS AND MegaCore FUNCTIONS
ALTERA> WILL MEET YOUR REQUIREMENTS, OR THAT THE OPERATION
ALTERA> OF THE PROGRAMS AND MegaCore FUNCTIONS WILL BE
ALTERA> UNINTERRUPTED OR ERROR-FREE. YOU ALSO ASSUME
ALTERA> RESPONSIBILITY FOR THE SELECTION OF THE PROGRAMS
ALTERA> AND MegaCore FUNCTIONS TO ACHIEVE YOUR INTENDED
ALTERA> RESULTS AND FOR THE INSTALLATION, USE, AND RESULTS
ALTERA> OBTAINED FROM THE PROGRAMS AND MegaCore FUNCTION 


Well it is free!

-
Brad
Article: 6528
Subject: Re: VHDL PCI FPGA Implementation
From: s_clubb@netcomuk.co.uk (Stuart Clubb)
Date: Sat, 31 May 1997 12:49:36 GMT
Links: << >>  << T >>  << A >>
On Fri, 30 May 1997 21:39:50 -0700, Dave Greenfield
<david_greenfield@altera.com> wrote:

>On the clock pin capacitance issue, Altera has tested and
>recharacterized the FLEX 10K products; errata will be published soon
>listing maximum at 12pF (within spec).

I thought you might. I guess that means the yield wil go down.

**** SHAREHOLDER ALERT ****
Does the price now go up, or will you make less money?

>On the two pin approach - agree.  Trade-off Altera provides is 0-wait
>state pin-sharing design or 1-wait state single pin (fully compliant)
>design.  Current MegaCore function went with performance.  Future
>MegaCore function will provide 1-wait state single pin design and
>customers can certainly implement this functionality today.

Well there it is folks. I guess that we have now established that
Xilinx and Lucent are capable of zero wait burst, fully compliant,
today. The Altera MegaCore is not compliant, and indeed all FLEX10K
devices shipping are not PCI compliant.

>Since when did we officially become the boys in blue?

An off-handed reference to the colour blue used on your Data book
cover. I could make references to the witholding of evidence to gain a
conviction (design?), but that would not be sporting would it?

I believe Brad says it with a little more weight than I would.

I guess that this pretty much wraps this thread up.

Stuart
Article: 6529
Subject: Re: FAQ's / Documentation sites wanted
From: "Steven K. Knapp" <sknapp @ optimagic.com>
Date: 31 May 1997 15:11:41 GMT
Links: << >>  << T >>  << A >>
There is a comprehensive list of programmable logic vendors, design
software, books, boards, consultants, etc. available on the Programmable
Logic Jump Station.

Check out 'http://www.optimagic.com'
-- 
Steven Knapp
OptiMagic(tm) Logic Design Solutions
E-mail:  sknapp @ optimagic.com
Programmable Logic Jump Station:  http://www.netcom.com/~optmagic

K. S. Venkatraman <venkat@chaos.ee.vill.edu> wrote in article
<5mn3hr$sv2@ftp.ee.vill.edu>...
| Hi,
| 
| I need some documentation sites on FPGAs, their uses, advantages etc. Can

| anyone provide a resourceful URL?
| 
| Thanks,
| Venkat.
| 
Article: 6530
Subject: Re: Altera Versus Xilinx
From: s_clubb@netcomuk.co.uk (Stuart Clubb)
Date: Sat, 31 May 1997 16:09:50 GMT
Links: << >>  << T >>  << A >>
On Thu, 29 May 1997 07:03:31 GMT, "Jye Mei Ng"
<Jye=Mei=Ng%Port=Eng%Eng=Sin@netgate.compaq.com> wrote:

>Sorry if this is ask before, I'm new to this group. I'm currently a student
>and am interested to know which is better. Especially for the application
>to PCI,ISA connections.

I think that we have just established the PCI bit in another thread:

Xilinx is capable of full PCI implementation with zero wait burst,
fully compliant. You will need to design it yourself. The Xilinx
offered core runs at half burst speed.

Altera FLEX10K is not PCI compliant. Specs will change to enable half
burst speed. Full burst will not, on current information be PCI
compliant.

Lucent Technologies also offers a fully compliant PCI solution at full
burst rates.

Your proven choice so far is therefore Xilinx or Lucent.

As for ISA bus, that's pretty straightforward for all I guess, but it
would depend on your back-end logic requirements as to who you decided
to use.

Stuart
Article: 6531
Subject: Re: In circuit programming of flash with Xilinx devices??
From: z80@dserve.com (Peter)
Date: Sat, 31 May 1997 18:50:20 GMT
Links: << >>  << T >>  << A >>
Should be, by implementing a simple state machine which just does what
you would do in software.

>Is it possible?


Peter.

Return address is invalid to help stop junk mail.
E-mail replies to z80@digiserve.com.
Article: 6532
Subject: FS: CADKEY '97 -100+ Available- Save $HUNDRED's EACH!!!
From: Karl Kristianson <KarlKristian@ntr.net>
Date: Sat, 31 May 1997 15:34:22 -0600
Links: << >>  << T >>  << A >>
FS: CADKEY '97 -100+ Available- Save $HUNDRED's EACH!!!

Hello!

A new copy of Cadkey 97 is selling on the street for $1,195. 
To guarantee updates for the next year costs $350 more, 
bringing it up to $1,545 total!

We have available over 100 NEW unopened, shrinkwrapped 
copies of Cadkey 6.0 on CD for DOS which can be upgraded to 
Cadkey 97, INCLUDING the year's worth of free updates, for 
the street price of $595; that's $950 less than the normal 
street price!

Or, maybe Cadkey 6.0 has enough power for you with no 
upgrade at all! (Cadkey '97 is basically Cadkey 8.0)

I'm selling these for best offer, one or all.

If you would like more info on Cadkey 97, here's Cadkey 97's 
Web page: http://www.cadkey.com/cadkey/index.htm

Thanks!

Karl Kristianson
Article: 6533
Subject: Re: In circuit programming of flash with Xilinx devices??
From: "John McGibbon" <fpga@worldnet.att.net>
Date: 31 May 1997 22:15:19 GMT
Links: << >>  << T >>  << A >>


Peter <z80@dserve.com> wrote in article
<33956660.159142955@news.netcomuk.co.uk>...
> Should be, by implementing a simple state machine which just does what
> you would do in software.
> 
> >Is it possible?
> 


One problem that you will have to solve is the fact that DIN on the Xilinx
(in serial mode) is also connected to D0 on your FLASH part.  It would seem
that you would need to use some handshaking back to your downloader to
indicate when you are driving the line during the flash program cycle
verses when you are listening for more data in the receive mode.   Since
the INIT pin becomes an I/O after configuration and it is connected to the
XCHECKER cable this would seem to be a reasonable choice.

An alternative might be to add a jumper between DIN on the Xilinx and D0 on
the flash, and add a second pin from D0 on the flash to an I/O on the
xilinx.  During normal operation, the jumper is installed and the xilinx
boots from the flash.  During your download/reprogram mode, remove the
jumper.  DIN on the Xilinx is driven from the download cable and D0 on the
flash is driven from the Xilinx I/O pin.  At this point you could have a
state machine receive data serially, buffer it up using Ram in the part and
then program the FLASH in parallel mode.

The next question seems to be more to the point.  Can the XCHECKER cable be
used in this function?  My GUESS is that it can't in it current
configuration.  You may have to create your own downloader cable/circuit
that can shift into a serial data transfer mode after the target has been
loaded with a boot configuration.

This would be a neat way to reconfigure parallel flash mounted to a board
without alot of additional circuitry.  It could also be used for
reconfiguring serial flash proms from Atmel.

John
john_mcgibbon@memecdesign.com
Article: 6534
Subject: Re: In circuit programming of flash with Xilinx devices??
From: djimm2@aol.com (Djimm2)
Date: 31 May 1997 22:55:14 GMT
Links: << >>  << T >>  << A >>
Dear John
Thank you for your reply. I first thought, that this is one of these
"dead" usergroups, which eat up only space on the servers. Your (second in
all) reply taight me different.

> During normal operation, the jumper is installed and the xilinx
How about a combination of your suggestion:
I could use XC4000's RAM to store a portion and then program the Flash
with it. The jumper is a concern, but I could use a 1..5K resistor between
Xchecker to overcome this.

> You may have to create your own downloader cable/circuit
Do you know what it really does? I looked at it, and it was filled with
CPLD etc.

> This would be a neat way to reconfigure parallel flash mounted to a
board
without alot of additional circuitry.
actually I would need a resistor only, which I planned anyway, because of
the protection of the XC4000.


Another question is:
Is it possible to send data FROM the XC4000 through the XChecker TO the
PC??

Thank you again for your reply.
Your Jimmy D.




download it then I could I can 
Article: 6535
Subject: Re: FPGA gate counting: No truth in advertising
From: john@customer1st.com (John Sievert)
Date: Sat, 31 May 1997 21:05:28 -0500
Links: << >>  << T >>  << A >>
Nothing hidden here! 

Let me see, I signed my name, my company name is in my domain name, both
my name and my company's name are in the phone book,  and the POP I
connected from is listed right in the email.  What's wrong with being
the sales engineer here?  Aren't you a QL employee? Aren't we all
involved in this industry?

The issue isn't who works for who, but what's in the summary judgement -
and therefore, who owns what. That isn't mud slinging, its a fact and
now a matter of public record.   How is that mud slinging? What's your
problem? 

If you've got something to say on this case, I'd be interested in
hearing it.  This court case is complex, but interesting and worthy of
discussion.  If you want to make personal attacks, I guess I'd consider
that a waste of time.  But, if that's the image you want to project for
you and your company, I guess that's your business. 

Regards
John Sievert
Customer 1st, Inc. 


<Blair@QuickLogic.com> wrote:

> In article <19970526224329123272@cust4.max1.minneapolis.mn.ms.uu.net>,
>   john@customer1st.com (John Sievert) wrote:
> >
> > Technology, which it appears, probably came from Actel (per summary
> > judgement against QuickLogic on patent infringement.).
> >
> > <kevintsmith@compuserve.com> wrote:
> >
> > > In this case, it's not marketing hype, just superior
> > > technology.
> >
> > --
> > Regards,
> > John Sievert
> 
> Aren't you the Actel Manufacturers Rep in the MN area?
> 
> It would behoove you to not sling mud and try to hide your identity.
> 
> Regards,
> Ben Blair
> Manager Field Applications
> QuickLogic Corporation
> 
> -------------------==== Posted via Deja News ====-----------------------
>       http://www.dejanews.com/     Search, Read, Post to Usenet


-- 
Regards,
John Sievert
Article: 6536
Subject: In circuit programming of flash --->JTAG?
From: djimm2@aol.com (Djimm2)
Date: 1 Jun 1997 02:52:22 GMT
Links: << >>  << T >>  << A >>
Hi there !

Still in search of a way to incircuit program a parallel flash device with
using the Xchecker.

As the bigger (i.e. 4MBit or 8MBit) flashs have a JTAG prot, would it be
possible to program them through that? 

Has anybody done JTAG on XC4000?

CU
Jimmy D.
Article: 6537
Subject: Re: Any designs to avoid in FPGAs
From: Reiner Hartenstein <hartenst@aix6.rhrk.uni-kl.de>
Date: Sun, 01 Jun 1997 09:19:23 +0000
Links: << >>  << T >>  << A >>
Phani Putrevu wrote:
> 
> Hi,
> 
> I was wondering if there are a class of circuits/systems that I should
> not implement using FPGAs. I am told that floating point units dont
> perform well when implemented using FPGAs. In fact a multiplier that I
> had implemented required 200ns (16 bit). Present day CPUs have much
> better FPUs/ALUs.
> 
> There was some discussion abt implementing comparator using FPGAs, and
> some suggested use CPLDs for combinational logic. Are there any other
> thumb rules as to when to go for an FPGA and when not to.
> 
> This becomes important when you are considering co-design and you want
> to decide if a function is to be executed in h/w or s/w. I have seen
> systems where this is specified as a part of the input code.
> 
> Thanks a lot.
> 
> Phani
> ------------------------------------------------------------------------
>      Phani K Putrevu                      384 Probasco Street  #14
>      MS - Comp  Engg                      Cincinnati    OH   45220
>      University of Cincinnati             Ph : 513-281 1154  (res)
>      email: pputrevu@ececs.uc.edu              513-556-0904  (lab)
>      URL : http://www.ececs.uc.edu/~pputrevu
> ------------------------------------------------------------------------

most applications heavily using arithmetics are not well supported by
the fine granularity FP circuits available commercially to-day. That's
why the research trend goes toward coarse granularity, such as e. g.
with the Kress Array (a reconfigurable array of reconfigurable ALUs -
for configuration using an optimizer: much faster and more efficient
than routing and placement - see: http://xputers.informatik.uni-kl.de).

Reiner Hartenstein
Article: 6538
Subject: Re: New Reconfigurable Computing newsgroup?
From: Reiner Hartenstein <hartenst@aix6.rhrk.uni-kl.de>
Date: Sun, 01 Jun 1997 09:49:18 +0000
Links: << >>  << T >>  << A >>
Michael Alexander - EECS wrote:
> 
> Reconfigurable Computing Enthusiasts,
> 
> I would like to solicit preliminary input on the following (draft) proposal
> for creating a newsgroup devoted to reconfigurable computing.
> ....
>               (DRAFT) REQUEST FOR DISCUSSION
> 
>          Group Name:  comp.arch.rpu
>              Status:  unmoderated
>        Distribution:  world wide
>             Summary:  Discussions related to reconfigurable computing systems
>         Proposed by:  Michael J. Alexander (alexander@eecs.wsu.edu)
> 
> This is a formal Request For Discussion (RFD) on the creation of an
> unmoderated newsgroup, comp.arch.rpu
> 
...
===============================================================================


I appreciate your efforts. I would propose, that you establish this
group. 

On the long run it will address also people from scenes other than
comp.arch.fpga. Parallel processing conferences are in a process of
reorientation their scope, where also reconfigurable is added as an
alternative to instruction level parallelism. An example is IPPS'98
(International Parallel Processing Symposium, Orlando, Florida, End of
March 1998)

Funding agencies started shifting funds from parallel to reconfigurable
(e. g. see the DARPA adaptive computing systems program). This indicates
the kind of a part of the clientele to be reached by the proposed
newsgroup. I could support you in announcing the group via our e-mailing
lists including such people. 

This new group would stress "computing thru structural programming"
rather than tinker toy approaches to hardware implementation.

Please, do not hesitate.
Best regards
Reiner Hartenstein                   http://xputers.informatik.uni-kl.de
Article: 6539
Subject: Re: In circuit programming of flash --->JTAG?
From: daveb@iinet.net.au_spam_trap (David R Brooks)
Date: Mon, 02 Jun 1997 00:05:12 GMT
Links: << >>  << T >>  << A >>
djimm2@aol.com (Djimm2) wrote:

:Hi there !
:
:Still in search of a way to incircuit program a parallel flash device with
:using the Xchecker.
:
:As the bigger (i.e. 4MBit or 8MBit) flashs have a JTAG prot, would it be
:possible to program them through that? 
:
:Has anybody done JTAG on XC4000?
:
 I have used XC4000 JTAG: it works well. I used a setup whereby the
XC4000 was configured (via JTAG) to look like a shift register &
counter, & used that to program the flash. Then reset the board, & the
FPGA self-configures from the flash, & runs.

 BTW who makes those Flash parts you mention, the ones with a JTAG
port? I have wanted such a thing for many a year...


--  Dave Brooks    <http://www.iinet.net.au/~daveb>
PGP public key via <http://www.iinet.net.au/~daveb/crypto.html>, or servers
    "From" line rigged to foil spambots: daveb <at> iinet.net.au
Article: 6540
Subject: Re: New Reconfigurable Computing newsgroup?
From: Steve Casselman <sc@vcc.com>
Date: Mon, 2 Jun 1997 04:11:06 GMT
Links: << >>  << T >>  << A >>
Reiner Hartenstein wrote:
> 
> Michael Alexander - EECS wrote:
> >
> > Reconfigurable Computing Enthusiasts,
> >
> > I would like to solicit preliminary input on the following (draft) proposal
> > for creating a newsgroup devoted to reconfigurable computing.
> > ....
> >               (DRAFT) REQUEST FOR DISCUSSION
> >
> >          Group Name:  comp.arch.rpu
> >              Status:  unmoderated
> >        Distribution:  world wide
> >             Summary:  Discussions related to reconfigurable computing systems
> >         Proposed by:  Michael J. Alexander (alexander@eecs.wsu.edu)
> >
> > This is a formal Request For Discussion (RFD) on the creation of an
> > unmoderated newsgroup, comp.arch.rpu
> >
> ...
> ===============================================================================
> 
> I appreciate your efforts. I would propose, that you establish this
> group.
> 
> Please, do not hesitate.
> Best regards
> Reiner Hartenstein                   http://xputers.informatik.uni-kl.de


I'm all for this effort. This is like a split of the 
software/systems types from the hardware/systems types. 
It is a very natural outcome created by growth in the 
industry. The difference between two type can be debated
but they exist and should be addressed. Comp.arch.fpga
is nothing like I thought it would be when we first started.
It never will be, but hey it does say FPGA and FPGAs are
hardware and the CAE tools to implement them with. RPUs are 
processing units, most of which use FPGAs today. To use them
you have to write programs for hardware and software objects.
Its a different world and needs its own place.

I vote yes!

-- 
Steve Casselman, President
Virtual Computer Corporation
http://www.vcc.com
Article: 6541
Subject: NT4 and EECAD applications, and SP3
From: eteam.nospam@aracnet.com (bob elkind)
Date: Mon, 2 Jun 1997 07:15:06 +0100
Links: << >>  << T >>  << A >>
A while back I reported on problems with some EECAD apps
running under NT4 SP2, specifically with memory leaks that
caused the application to crash.  The same apps worked
just fine under Win95. [SP2=Service Pack 2, an OS update]

I'm reporting now that the same apps now work just fine with
NT4 SP3 installed.  Robustness is greatly improved.
If you are still running SP2, I strongly suggest you check out
SP3.

I've been running SP3 for about 2 weeks.

Also, Netscape Commonicator 4 Beta 4 and 5 are both much more
robust with SP3 installed.

Hope this helps, my friends.

-- Bob Elkind

****************************************************************
Bob Elkind                              mailto:eteam@aracnet.com 
7118 SW Lee Road               part-time fax number:503.357.9001
Gaston, OR 97119           cell:503.709.1985   home:503.359.4903
****** Video processing, R&D, ASIC, FPGA design consulting *****
Article: 6542
Subject: Dear all Altera CPLD designers!
From: "Rune Bæverrud" <r@acte.no>
Date: Mon, 02 Jun 1997 12:00:11 +0200
Links: << >>  << T >>  << A >>
Dear all Altera CPLD designers
(Professonals, students, hobbyists, professors, FAEs)

I have set up a web site for you - the FreeCore Library - which is
available at http://www.acte.no/freecore

Everything you find here is free - including free function modules for
use in your next project.

Q: Who is behind the FreeCore Library?
A: YOU ARE!

This site will grow as you submit your functions to share with other
designers! If you've done anything useful in Altera programmable logic
that you would like to share with the rest of us - please send it to me!

Best Regards,
Rune Baeverrud
Article: 6543
Subject: Re: New Reconfigurable Computing newsgroup?
From: Gareth Baron <gareth@trsys.demon.co.uk>
Date: Mon, 2 Jun 1997 13:26:04 +0100
Links: << >>  << T >>  << A >>
In article <3391459D.3211@aix6.rhrk.uni-kl.de>, Reiner Hartenstein
<hartenst@aix6.rhrk.uni-kl.de> writes
>Michael Alexander - EECS wrote:
>> 
>> Reconfigurable Computing Enthusiasts,
>> 
>> I would like to solicit preliminary input on the following (draft) proposal
>> for creating a newsgroup devoted to reconfigurable computing.
>> ....
>>               (DRAFT) REQUEST FOR DISCUSSION
>> 
>>          Group Name:  comp.arch.rpu
>>              Status:  unmoderated
>>        Distribution:  world wide
>>             Summary:  Discussions related to reconfigurable computing systems
>>         Proposed by:  Michael J. Alexander (alexander@eecs.wsu.edu)
>> 
>> This is a formal Request For Discussion (RFD) on the creation of an
>> unmoderated newsgroup, comp.arch.rpu
>> 
>...
>===============================================================================
>
>


I also appreciate your efforts.  I would back you up considering this is
most definitely the way of modern computers in the future.



Gareth Baron

Article: 6544
Subject: Re: Altera Versus Xilinx
From: Iakovos Stamoulis <I.Stamoulis@Sussex.ac.uk>
Date: Mon, 02 Jun 1997 14:04:15 +0100
Links: << >>  << T >>  << A >>
>  > Altera FLEX10K is not PCI compliant. Specs will change to enable
> half
>  > burst speed. Full burst will not, on current information be PCI
>  > compliant.
>
Sorry... but what exactly makes Altera FLEX non-PCI compliant ???
>From reading the relevant application note, it look-like altera are
more than capable to provide the driving characteristics and speed
to be PCI Compliant.

Jac

Article: 6545
Subject: Re: New Reconfigurable Computing newsgroup?
From: Achim Gratz <gratz@ite.inf.tu-dresden.de>
Date: 2 Jun 1997 15:08:52 +0200
Links: << >>  << T >>  << A >>
alexande@eecs.wsu.edu (Michael Alexander - EECS) writes:

> 
> Reconfigurable Computing Enthusiasts,
> 
> I would like to solicit preliminary input on the following (draft) proposal 
> for creating a newsgroup devoted to reconfigurable computing.  

I'm all for it.

> As you may know, the original charter for Comp.arch.fpga intended
> this newsgroup as a discussion place for reconfigurable computing. 
> (See ftp://ftp.uu.net/usenet/news.announce.newgroups/comp/comp.arch.fpga)
> At that time, Comp.arch.fpga was deemed the most appropriate name
> for such a newsgroup.
> 
> At this time, I think it's worthwhile to consider creating a new newsgroup 
> devoted to reconfigurable computing, leaving Comp.arch.fpga to serve in 
> its current (very useful) role.  If you're intersted in reconfigurable 
> computing, please read the draft proposal below.  

This should be reflected by a change to the c.a.fpga charter also.

> The proposed unmoderated newsgroup Comp.arch.rpu will be open 
> to discussions on topics related to reconfigurable computing, 
> which can be described as the practice of using in-system-reconfigurable 
> processing units (RPU) to accelerate operations in general-purpose computing.  

I hope that RPU is not already used for some specific product.  If it
is, c.a.reconfig or some such seems more appropriate.


Achim Gratz.

--+<[ It's the small pleasures that make life so miserable. ]>+--
WWW:    http://www.inf.tu-dresden.de/~ag7/{english/}
E-Mail: gratz@ite.inf.tu-dresden.de
Phone:  +49 351 463 - 8325
Article: 6546
Subject: Re: New Reconfigurable Computing newsgroup?
From: "R. T. Wurth" <rwurth@att.com>
Date: Mon, 02 Jun 1997 09:21:37 -0400
Links: << >>  << T >>  << A >>
<<<Posted to c.a.fpga, and news.groups, with a courtesy copy (Cc:) to
the quoted author>>>

Michael Alexander - EECS wrote:

> Reconfigurable Computing Enthusiasts,

> I would like to solicit preliminary input on the following (draft) proposal
> for creating a newsgroup devoted to reconfigurable computing.

> As you may know, the original charter for Comp.arch.fpga intended
> this newsgroup as a discussion place for reconfigurable computing.
> (See ftp://ftp.uu.net/usenet/news.announce.newgroups/comp/comp.arch.fpga)
> At that time, Comp.arch.fpga was deemed the most appropriate name
> for such a newsgroup.

> At this time, I think it's worthwhile to consider creating a new newsgroup
> devoted to reconfigurable computing, leaving Comp.arch.fpga to serve in
> its current (very useful) role.  If you're intersted in reconfigurable
> computing, please read the draft proposal below.

> In order to keep the discussion open to everyone, please post any
> comments to Comp.arch.fpga

> Thanks,

> --Mike Alexander

> |     (Draft RFD also at http://www.eecs.wsu.edu/~alexande/draft_rfd.html)    |

> ===============================================================================

>               (DRAFT) REQUEST FOR DISCUSSION

>          Group Name:  comp.arch.rpu
>              Status:  unmoderated
>        Distribution:  world wide
>             Summary:  Discussions related to reconfigurable computing systems
>         Proposed by:  Michael J. Alexander (alexander@eecs.wsu.edu)

> This is a formal Request For Discussion (RFD) on the creation of an
> unmoderated newsgroup, comp.arch.rpu

> CHARTER

> The proposed unmoderated newsgroup Comp.arch.rpu will be open
> to discussions on topics related to reconfigurable computing,
> which can be described as the practice of using in-system-reconfigurable
> processing units (RPU) to accelerate operations in general-purpose computing.

> Appropriate topics include, but are not limited to, programming tools,
> languages and systems that support dynamic configuration; reconfigurable
> processing architectures and RPUs, both commercial and research; and
> applications of reconfigurable computing.

> RATIONALE

> Reconfigurable computing is an emerging field that represents a significant
> departure from traditional computing models (e.g., von Neuman).  Although
> many of these systems use FPGAs, reconfigurable computing systems represent
> an important new computing paradigm, making such discussions less and less
> appropriate for Comp.arch.fpga, which is largely focused on CAD tools and
> issues pertinant to traditional static FPGA designs (e.g., ASICs, glue logic).

> Until quite recently, reconfigurable computing has meant computing systems
> built from FPGA devices.  However, a new generation of FPGA-like devices,
> which are often called reconfigurable processing units (RPU), support
> key features such as partial fast reconfiguration.  RPUs enable a new
> computing paradigm based on ``virtual hardware'', where application-specific
> hardware is time-multiplexed on the RPU in order to meet adaptive computing
> requirements.  Reconfigurable computing systems are hardware/software systems
> in which hardware functionality is not fixed a priori, but rather is tailored
> at runtime to meet application computational requirements.

> It appears from its charter that Comp.arch.fpga was intended to be a
> vehicle for discussing FPGA-based computational engines and systems such as
> those that have appeared at the IEEE workshops FCCM 93-97.  Discussions
> on Comp.arch.fpga focus largely on the use of FPGA CAD tools and design
> techniques, which are extremely useful to the general, larger FPGA-design
> community.  Rather than ``reclaim'' Comp.arch.fpga as the proper domain
> to discuss reconfigurable computing, it would be most beneficial to allow
> Comp.arch.fpga to maintain its current function (as the proper discussion
> place for FPGAs) and introduce a new group, Comp.arch.rpu, devoted
> to discussing the use of reconfigurable processing units.

> ===============================================================================

Two wrongs don't make a right.  I think it would be better to spin off a
real engineering-oriented fpga group (sci.engr.electrical.fpga?) and
then make a serious effort to move the posts not in keeping with the
original comp.arch.fpga posts off c.a.fpga to s.e.e.fpga.  Many uses of
FPGAs have nothing to do with computing, and 
should not be discussed under the comp.arch hierarchy, e.g., FPGAs used
in comms 
equipment and having little or no connection with any CPU (other than a
few alarm and control leads connecting to an alarm filtering and
processing CPU).  I think it would be wrong to keep general-purpose
posts here.  (Then again, I think much of 
comp.dcom.telecom.* should really be in sci.engr.electrical, with the
exception of stuff like modems, lans, etc.)

Since this raises issues of how to keep newsgroups on-charter, and what
to do about newsgroups that have generally accepted discussion domains
at variance with their charters, I am crossposting to news.groups. 
Perhaps the news.groupies there can add further insight.

I am sure you are also aware that for your RFD to really make it to
formal RFD status, you will have to add more legalistic boilerplate and
format it in accordance with David Lawrence's FAQ on rules for
formatting RFDs, which you 
can probably find in news.answers or on the rtfm.mit.edu FAQ archives.
-- 
   R. T. Wurth / (w) Holmdel, NJ / (h) Rumson, NJ
   rwurth@att.com
Article: 6547
Subject: Re: Altera Versus Xilinx
From: evjapps@inet.uni-c.dk
Date: 2 Jun 1997 18:29:32 GMT
Links: << >>  << T >>  << A >>
>   Iakovos Stamoulis <I.Stamoulis@Sussex.ac.uk> writes:
>  >  > Altera FLEX10K is not PCI compliant. Specs will change to enable
>  > half
>  >  > burst speed. Full burst will not, on current information be PCI
>  >  > compliant.
>  >
>  Sorry... but what exactly makes Altera FLEX non-PCI compliant ???
>  From reading the relevant application note, it look-like altera are
>  more than capable to provide the driving characteristics and speed
>  to be PCI Compliant.
>  
>  Jac
>  
>  
>>>>
Jac is right about Altera's compliance to the PCI spec's. Please look at the datasheets for their new PCI master/target MegaCore function with DMA.
This function allows zero wait state Read & write at 33 MHz operation. It uses approx. 50% of an EPF10K30-3 and is easily modified to what ever parameters is neaded.

Regards

Uffe Tyrsted Toft
-------------------------------------------
ACTE NC Denmark A/S
E. V. J. Elektronik
Titangade 15
DK 2200 Copenhagen N
Phone: +45 35 86 90 22
Fax:     +45 35 86 90 00
E-mail: evjapps@inet.uni-c.dk
-------------------------------------------
Article: 6548
Subject: Re: I2C Interface
From: evjapps@inet.uni-c.dk
Date: 2 Jun 1997 18:32:52 GMT
Links: << >>  << T >>  << A >>
>   hgw@cssmuc.frt.dec.com (Hans-Guenther Willers) writes:
>  Hi All!
>  
>  has someone done an I2C slave interface in a HDL (AHDL, VHDL,
>  Verilog)?
>  
>  
>  
>  Greetings,
>  
>  Hans-Guenther Willers (is hgw@frt.dec.com)
>  
>  
>>>>

Take a look on the following homepage. You will find an I2C bus controller a.o.

http://www.acte.no/freecore

Regards
Uffe Tyrsted Toft
-------------------------------------------
ACTE NC Denmark A/S
E. V. J. Elektronik
Titangade 15
DK 2200 Copenhagen N
Phone: +45 35 86 90 22
Fax:     +45 35 86 90 00
E-mail: evjapps@inet.uni-c.dk
-------------------------------------------
Article: 6549
Subject: Re: What is M1?
From: Kate Meilicke <kate.meilicke@xilinx.com>
Date: Mon, 02 Jun 1997 15:03:02 -0400
Links: << >>  << T >>  << A >>
Bill,

Any new designs should use edif or sedif.  XNF is still supported for
legacy designs and some EDA tools don't currently support EDIF.

Kate


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