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 6550

Article: 6550
Subject: Re: Fine Pitch PQFP : anyone any hassles?
From: steenl@pal.ece.orst.edu (Steen Larsen)
Date: 2 Jun 1997 21:22:37 GMT
Links: << >>  << T >>  << A >>
In article <5mjqq1$m3j$1@news01.btx.dtag.de>, HTD <Hans Dermot Doran> wrote:
>On Mon, 26 May 1997 20:47:42 GMT, stuart.summerville@practel.com.au
>(Stuart Summerville) wrote:
>
>>Hi all,
>>
>>I have a 208pin PQFP fpga  (0.5mm pitch) on a board. I am having
>>problems with pin connections to the board. Attempting to re-heat the
>>solder to make a clean connection seems to create problems with
>>surrounding pins - it doesn't take much to get a minute solder bridge
>>between two pins.
>>
>>Two questions:
>>
>>1) Do any of you find such packages tend to come in with such
>>connection problems?
>>
>>2) What is the feeling about attempting to re-solder such pins if a
>>connection seems to be flakey? Am I wasting my time trying to fix it?
>>Maybe if some pins have flakey connections then others on the same
>>chip are likely to (eg. if some are bent down too much, then obviously
>>the others are at a different level...).
>>
>
Resoldering can be done, but I am no good at it.  Sometimes the chip has
to be removed and the board traces will only handle 3-4 removals before
the traces separate from the board.  

The easiest solution for me was to go with the Altera 208PQFP socket since
I'm using an OTP FPGA.

Good luck.
-steenl
Article: 6551
Subject: Re: Best way to learn VHDL?
From: Samir Marc Falaki <Samir_Marc_Falaki@uqtr.uquebec.ca>
Date: Mon, 2 Jun 1997 21:34:29 GMT
Links: << >>  << T >>  << A >>
You can pick up a pretty good interactive tutorial (works with your
web browser) at :

    http://rassp.scra.org/

This CD ROM is great.  You have nice, pleasant graphics and you are
always a click away from the VHDL Language Reference Manual.  It is
well structured and is easy to follow.  It was developed by IEEE
and RASSP (Rapid Prototyping of Appl. Specific Signal Processors).

Cheers,

Sam Falaki
Article: 6552
Subject: Re: Altera Versus Xilinx
From: s_clubb@netcomuk.co.uk (Stuart Clubb)
Date: Mon, 02 Jun 1997 21:53:01 GMT
Links: << >>  << T >>  << A >>
On Mon, 02 Jun 1997 14:04:15 +0100, Iakovos Stamoulis
<I.Stamoulis@Sussex.ac.uk> wrote:

>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.

>From reading this posting, it looks like Altera documentation has been
misread by another NG member.

Read the documentation fully. I did. So I would suspect have most
others following the thread where we started and finished this one.

Altera FLEX10K is not PCI compliant.
Every device they have shipped is not compliant.
Every part sitting with their disti network is not compliant.
Every piece coming off the line is not compliant.

End of story. Dead, buried, WORM FOOD.

Stuart
A Lucent distributor speaking for himself.
Article: 6553
Subject: Re: Altera Versus Xilinx
From: s_clubb@netcomuk.co.uk (Stuart Clubb)
Date: Mon, 02 Jun 1997 21:53:02 GMT
Links: << >>  << T >>  << A >>
Gaaah!!!

On 2 Jun 1997 18:29:32 GMT, evjapps@inet.uni-c.dk wrote:
>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.

Parrot! Please remove Altera's hand from your bottom.
	You work for an Altera distributor do you not?
	Are you an Altera FAE for them perhaps?

I didn't just look at the specs. I printed them, read them, double
checked them with the PCI spec and made my conclusions:

Altera FLEX10K is not PCI compliant. Doesn't matter how much marketing
spin you put on it, or how many glossy adverts you throw at the
market, or how much html you use on your web site.

1
The Clock pin capacitance breaks the spec. This is due to be changed,
so they will be compliant on this checkbox at some point in the
future.

2
The pci_a core as it stands has some signals from the PCI bus driving
two pins on the FLEX10K device. That breaks the spec, and puts a
maximum 20 pF load on the pin.

Today, they are not compliant with the PCI specification, end of story

Stuart
A Lucent Distributor speaking for himself.
Article: 6554
Subject: Re: New Reconfigurable Computing newsgroup?
From: Michael J. Alexander <alexander@eecs.wsu.edu>
Date: Mon, 02 Jun 1997 16:21:43 -0600
Links: << >>  << T >>  << A >>
In article <c67vxp2xq.fsf@ite127.inf.tu-dresden.de>,
  Achim Gratz <gratz@ite.inf.tu-dresden.de> wrote:

>
> I'm all for it.
>

Excellent!

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

This is an interesting idea; I hadn't thought of trying to change
the original c.a.fpga charter, but that is a possibility if c.a.rpu
is created.

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

I understand that c.a.reconfig was debated as a choice of name for
c.a.fpga; however, the term ``reconfig'' is also used frequently in
fault-tolerant computing, which could attract a different audience (much
as the term ``FPGA'' has attracted a particular audience to
comp.arch.fpga)

Anyone else have suggestions for a better name?

--Mike A

-------------------==== Posted via Deja News ====-----------------------
      http://www.dejanews.com/     Search, Read, Post to Usenet
Article: 6555
Subject: Re: New Reconfigurable Computing newsgroup?
From: alexander@eecs.wsu.edu
Date: Mon, 02 Jun 1997 17:01:19 -0600
Links: << >>  << T >>  << A >>

> 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

Based on the charter of c.a.fpga, it's clear that a lot of the current
discussion was intended to take place somewhere besides the
``reconfigurable computing'' newsgroup (see the charter); i think everyone
agrees on this (including the person who did the original charter).
The question seems to be how best to proceed, given this.

Creating a ``sci.engr.electrical.fpga'' for FPGA discussions and
keeping c.a.fpga for reconfigurable computing is one
alternative, what I meant by the `reclaim'' approach.
Reconfigurable computing folks would then politely steer FPGA
discussions to the new s.e.e.fpga group.
I have a feeling, however, that as long as the reconfigurable
computing newsgroup contains the term ``fpga'', this will happen
a lot -- not that this would be bad, just that it will occur
relatively frequently.  (I could be completely wrong ;-)

On the other hand, if the reconfig newsgroup does NOT contain
the term ``fpga'', some reconfig computing folks may not
realize it exists... until someone from c.a.fpga steers
them to it.

Do people agree that there's a difference between reconfigurable
computing and FPGAs?  Do these topics warrent separate discussion
spaces?  (Comments?)

I think they do, and it's really a matter of deciding on
the best places (i.e., two newsgroup names) in which to discuss
the two topics.  (Not to say *that* will be an easy task ;-)

>
> 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.

Good idea, it'll be interesting to see these responses

--Mike A

-------------------==== Posted via Deja News ====-----------------------
      http://www.dejanews.com/     Search, Read, Post to Usenet
Article: 6556
Subject: Re: New Reconfigurable Computing newsgroup?
From: alexander@eecs.wsu.edu
Date: Mon, 02 Jun 1997 17:12:31 -0600
Links: << >>  << T >>  << A >>
Reiner,

Yes, a reconfigurable computing newsgroup would attract people with a
variety of backgrounds and promote new ideas. (No doubt, the
parallel-processing community would take part.)  In this context,
reconfigurable computing goes beyond the current technology (i.e., fpgas)
and is viewed as a new paradigm, ``computing through structural
programming'' as you put it.  ^^^^^^^^^^

Is comp.arch.fpga the right forum to discuss such topics?  It's
charter indicates that it *should* be, but the current discussions
on FPGA CAD tools seem to indicate otherwise.  Again, it seems
to be a quesiton of how to proceed:  ``reclaim'' comp.arch.fpga for
reconfigurable computing and move fpga discussions to another
(new) newsgroup; or leave comp.arch.fpga in place (with a modified
charter was one suggestion...) and create a new reconfigurable-computing
newsgroup, such as comp.arch.rpu


--Mike A

> 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

-------------------==== Posted via Deja News ====-----------------------
      http://www.dejanews.com/     Search, Read, Post to Usenet
Article: 6557
Subject: Re: In circuit programming of flash --->JTAG?
From: djimm2@aol.com (Djimm2)
Date: 2 Jun 1997 23:25:06 GMT
Links: << >>  << T >>  << A >>

Hello from Santa Monica (California) to the End of the world....

Dear David
Thank you for your reply.

>  I have used XC4000 JTAG: it works well. I used a setup whereby the
Did you do the "programming" with a third unit, like an uController or
PAL? Were you able to do all the WR and other signals needed to programm
through the JTAG only? (wow if so)


>  BTW who makes those Flash parts you mention, the ones with a JTAG
Actually no one. I hoped, that somebody nows one, but many asked only. But
it would be a good thing, hm?

Can you think of an approach to do it with the Xchecker instead of the
JTAG?

I have not yet read myself into JTAG, do you now where to look?

Thank you 
your Jimmy D.
Article: 6558
Subject: Re: New Reconfigurable Computing newsgroup?
From: alexander@eecs.wsu.edu
Date: Mon, 02 Jun 1997 21:01:32 -0600
Links: << >>  << T >>  << A >>
Hi Folks,

The preliminary discussion about comp.arch.rpu is generating good ideas:
I got the following suggestion off-line; any comments? (my comments
appended at end)

>
> When I look at:
>       comp.arch.rpu
> it really has no meaning at all.  (I'm not trying to be rude, but unless
> one already know what "RPU" means, one has no clue what this group would
> be for.)
>
> A name like:
>       comp.arch.fpga.reconfigurable
>       comp.arch.fpga.reconfig
> tells people what the group is for.  It is in the fpga hierarchy since
> it deals with reconfigurable computing using FPGAs.  Or maybe:
>       comp.arch.fpga.computing
> but I think this is less clear.
>
> If you want to do the fpga world a big service, how about proposing
> that comp.arch.fpga be reorganized into:
>   comp.arch.fpga              Miscellaneous
>   comp.arch.fpga.tools                CAD Tools
>   comp.arch.fpga.devices      Device info (chips, proms, programming, etc.)
>   comp.arch.fpga.designs      Designs using FPGAs (system and single chip)
>   comp.arch.fpga.reconfigurable       Reconfigurable computing
>
> That way people can find exactly the information they need and not be
> bothered with extraneous data.  (For example, I would not read the
> tools groups, but would read the rest.)
>
> So if you think this is a good idea, you really ought to propose a
> reorganization now.  That way it fixes the problem forever, instead
> of having to educate people down the road about separating out the
> topics...
>

I like the idea of a hierarchical reorg a lot.	Comp.arch.fpga currently
serves a valuable purpose, which I for one would like to see left
undisturbed as much as possible.  The suggestion to reorg hierarchically
would largely accomplish this; exactly which sub-groups to use would be
another matter, but in principle I like the approach.

On the other hand, several folks have suggested that much of what is
curently discussed in comp.arch.fpga does not belong under the comp.arch
hierarchy, but rather under the Science/Engineering/Electrical hierarchy;
for example, creating ``sci.engr.electrical.fpga'' for this purpose.
The logical reasoning behind this approach is clear; however, my feeling
is that it would fragment discussion on fpgas (by splitting discussions
across hierarchies), whereas the hierarchical reorg approach would have
a more orgainzing effect on the expanding fields that involve fpgas.

Any comments?

--Mike A

-------------------==== Posted via Deja News ====-----------------------
      http://www.dejanews.com/     Search, Read, Post to Usenet
Article: 6559
Subject: Re: New Reconfigurable Computing newsgroup?
From: Steve Casselman <sc@vcc.com>
Date: Tue, 3 Jun 1997 05:57:06 GMT
Links: << >>  << T >>  << A >>
alexander@eecs.wsu.edu wrote:
> 
> Hi Folks,
> 
> The preliminary discussion about comp.arch.rpu is generating good ideas:
> I got the following suggestion off-line; any comments? (my comments
> appended at end)
> 
> >
> > When I look at:
> >       comp.arch.rpu
> > it really has no meaning at all.  (I'm not trying to be rude, but unless
> > one already know what "RPU" means, one has no clue what this group would
> > be for.)
> >
> > A name like:
> >       comp.arch.fpga.reconfigurable
> >       comp.arch.fpga.reconfig
> > tells people what the group is for.  It is in the fpga hierarchy since
> > it deals with reconfigurable computing using FPGAs.  Or maybe:
> >       comp.arch.fpga.computing
> > but I think this is less clear.
> >
> > If you want to do the fpga world a big service, how about proposing
> > that comp.arch.fpga be reorganized into:
> >   comp.arch.fpga              Miscellaneous
> >   comp.arch.fpga.tools                CAD Tools
> >   comp.arch.fpga.devices      Device info (chips, proms, programming, etc.)
> >   comp.arch.fpga.designs      Designs using FPGAs (system and single chip)
> >   comp.arch.fpga.reconfigurable       Reconfigurable computing
> >
> > That way people can find exactly the information they need and not be
> > bothered with extraneous data.  (For example, I would not read the
> > tools groups, but would read the rest.)
> >
> > So if you think this is a good idea, you really ought to propose a
> > reorganization now.  That way it fixes the problem forever, instead
> > of having to educate people down the road about separating out the
> > topics...
> >
> 
> I like the idea of a hierarchical reorg a lot.  Comp.arch.fpga currently
> serves a valuable purpose, which I for one would like to see left
> undisturbed as much as possible.  The suggestion to reorg hierarchically
> would largely accomplish this; exactly which sub-groups to use would be
> another matter, but in principle I like the approach.
> 
> On the other hand, several folks have suggested that much of what is
> curently discussed in comp.arch.fpga does not belong under the comp.arch
> hierarchy, but rather under the Science/Engineering/Electrical hierarchy;
> for example, creating ``sci.engr.electrical.fpga'' for this purpose.
> The logical reasoning behind this approach is clear; however, my feeling
> is that it would fragment discussion on fpgas (by splitting discussions
> across hierarchies), whereas the hierarchical reorg approach would have
> a more orgainzing effect on the expanding fields that involve fpgas.
> 
> Any comments?
> 
> --Mike A
> 
> -------------------==== Posted via Deja News ====-----------------------
>       http://www.dejanews.com/     Search, Read, Post to Usenet

I left all the above because it deserves a reading and rereading. 
RPU stands for reconfigurable processing unit. You may not know it
now but you will in the near furture. It is a reconfigurable hardware
unit with a micro processor or processor port and it is open. Nobody
owns the trademark on RPU. For example I would not call the Colt chip
a FPGA but I would call it an RPU. The restructure thing is like saying 
we should have comp.arch.transistor.cpu because the first cpus used 
(and continue to use) transistors. If you look the only thread going
about reconfigurable computing here is this one. When we just
had a reflector there where not that many posts but all of them
where about reconfigurable computing. 

I say axe comp.arch.fpga and put it where it belongs then create
comp.arch.rpu

-- 
Steve Casselman, President
Virtual Computer Corporation
http://www.vcc.com
Article: 6560
Subject: Re: New Reconfigurable Computing newsgroup?
From: pirger@astrosun.tn.cornell.edu (Bruce Pirger)
Date: 3 Jun 1997 06:15:56 GMT
Links: << >>  << T >>  << A >>
In article <865302993.27430@dejanews.com>, alexander@eecs.wsu.edu says...
>
>Hi Folks,
>
>The preliminary discussion about comp.arch.rpu is generating good ideas:
>I got the following suggestion off-line; any comments? (my comments

>> A name like:
>>       comp.arch.fpga.reconfigurable
>>       comp.arch.fpga.reconfig
>> tells people what the group is for.  It is in the fpga hierarchy since
>> it deals with reconfigurable computing using FPGAs.  Or maybe:
>>       comp.arch.fpga.computing
>> but I think this is less clear.
>>
>> If you want to do the fpga world a big service, how about proposing
>> that comp.arch.fpga be reorganized into:
>>   comp.arch.fpga              Miscellaneous
>>   comp.arch.fpga.tools                CAD Tools
>>   comp.arch.fpga.devices      Device info (chips, proms, programming, etc.)
>>   comp.arch.fpga.designs      Designs using FPGAs (system and single chip)
>>   comp.arch.fpga.reconfigurable       Reconfigurable computing
>>
>


A few weeks ago I posted asking about a more relevant newsgroup for 
reconfigurable computing...  I searched all the available group names and
came up with a few short possibilities, c.a.fpga and perhaps those concerning
vhdl....Of course neither contain direct (or little) RC discussion.

It is certainly true that .rpu would not have made it to my short list, 
whereas reconfig or fpga or reconfigurable etc would.  I would strongly 
support including fpga and the root reconfig in the new name.  I also 
strongly agree that the name should not be tied to any available platform.

I do look forward to discussions in this group. As the adoption of the 
technology grows and begins to dramatically change digital hardware :), this 
will probably become a very active newsgroup, so planning now
would be very wise.  I vote for the c.a.fpga.various groups listed
above...  Foresight now will make us all happy later.

Bruce Pirger

including 

Article: 6561
Subject: Re: What is M1?
From: "Jan Gray" <jsgray@acm.org.nospam>
Date: 3 Jun 1997 06:36:44 GMT
Links: << >>  << T >>  << A >>
Kate Meilicke <kate.meilicke@xilinx.com> wrote in article
<339318E6.F2F@xilinx.com>...
> 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

It would be very helpful for those of us with homegrown tools, who are
considering a move from XNF to EDIF, if Xilinx would publish a
specification of how to emit EDIF for Xilinx tools, e.g. how to target
specific device features, specify timespecs, placement constraints, etc. 
That is, don't repeat the XNF experience where the information was
available only under NDA or through "reverse engineering" of
otherwise-generated XNF.

Perhaps such a EDIF-for-Xiilnx specification is available, but I haven't
yet received an update since 6.0 and it doesn't appear to be on the Xilinx
website.

Thank you.
Jan Gray
Article: 6562
Subject: Re: New Reconfigurable Computing newsgroup?
From: "Jan Gray" <jsgray@acm.org.nospam>
Date: 3 Jun 1997 06:52:13 GMT
Links: << >>  << T >>  << A >>
A contrarian perspective.  I favour the status quo.  The volume on the
present group is quite manageable.  I imagine many are like me --
interested in both reconfigurable computers *and* general FPGA information
-- and it is just plain convenient to have all the traffic dumped into one
happy milieu.

Splitting the group into two will not magically create CONTENT or VOLUME in
the comp.arch.fpga.really.reconfig.really branch.  Although there is not
much discussion about reconfigurable FPGA based computers, the other FPGA
traffic in this group is not at fault.

Many times I have seen groups split, only to have half of the messages
cross-posted to both groups, and worse.  Not to mention the hassles of
pestering one's news admin to be sure to carry the new group, etc.  No, it
seems better to wait until there is some sustained custom/reconfig
computing discussion traffic first.

However, I am quite sold on a comp.arch.fpga.split.discussion newsgroup!

Jan Gray

Article: 6563
Subject: Re: What is M1?
From: timolmst@cyberramp.net
Date: Tue, 03 Jun 1997 07:45:05 GMT
Links: << >>  << T >>  << A >>


>It would be very helpful for those of us with homegrown tools, who are
>considering a move from XNF to EDIF, if Xilinx would publish a
>specification of how to emit EDIF for Xilinx tools, e.g. how to target
>specific device features, specify timespecs, placement constraints, etc. 
>That is, don't repeat the XNF experience where the information was
>available only under NDA or through "reverse engineering" of
>otherwise-generated XNF.

>Perhaps such a EDIF-for-Xiilnx specification is available, but I haven't
>yet received an update since 6.0 and it doesn't appear to be on the Xilinx
>website.

You probably won't. Xilinx has historicly considered this information
to be propietary.

Article: 6564
Subject: Re: New Reconfigurable Computing newsgroup?
From: r.m.muench@ieee.nospam.org (Robert M. Muench)
Date: Tue, 03 Jun 1997 08:16:15 GMT
Links: << >>  << T >>  << A >>
On Fri, 30 May 1997 18:09:09 GMT, alexande@eecs.wsu.edu (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.  

Yes! This theme needs its own place!


Robert M. Muench
SCRAP EDV-Anlagen GmbH, Karlsruhe, Germany

==> Private mail : r.m.muench@ieee.nospam.org <==
-->   remove .nospam from my e-mail address   <--
==>			 ask for PGP public-key			  <==
Article: 6565
Subject: Re: New Reconfigurable Computing newsgroup?
From: Achim Gratz <gratz@ite.inf.tu-dresden.de>
Date: 3 Jun 1997 12:07:32 +0200
Links: << >>  << T >>  << A >>
alexander@eecs.wsu.edu writes:

> I like the idea of a hierarchical reorg a lot.	Comp.arch.fpga currently
> serves a valuable purpose, which I for one would like to see left
> undisturbed as much as possible.  The suggestion to reorg hierarchically
> would largely accomplish this; exactly which sub-groups to use would be
> another matter, but in principle I like the approach.

You should know what tends to happen to such reorgs.  At the very
minimum, that would require to remove comp.arch.fpga (the top group of
an hierarchy should never be active).

You are proposing a group for the discussion of Reconfigurable
Processing Units.  While FPGA are certainly the current way to
experiment with them in hardware, they have not much else to do with
FPGA.  That would make this group inappropriate as a subgroup to
c.a.fpga as it narrows the topic unnecessarily, IMHO.  It is certainly
an architectural topic, so comp.arch is the "right" hierarchy to put
it in.  Reconfig computing might even be split in the future if it
ever becomes mainstream.

This leaves the question what to do with c.a.fpga, since the stuff
that's most frequently discussed here has little relevance to computer
architecture.  My suggestion is to change the charter at least, if not
moving it to sci.engineering.fpga altogether.  If we want to be able
to complain about inappropriate posts in UseNet, the least thing we
should do is get the charters and hierarchy right.

So the cleanest way would be to _rename_ comp.arch.fpga so that
there's no doubt that we want to talk about reconfigurable computing
here (if the voters agree).  At the same time c.a.fpga becomes
defunct, sci.eng.fpga pops up.  Whether s.e.fpga is a hierarchy in
itself from the start needs to be decided, I don't think the current
volume warrants it.


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: 6566
Subject: Re: New Reconfigurable Computing newsgroup?
From: "Richard B. Katz" <stellere@erols.com>
Date: 3 Jun 1997 10:49:31 GMT
Links: << >>  << T >>  << A >>
note: last paragraph of this post is the most important; feel free to skip
right down there

alexander@eecs.wsu.edu wrote in article <865288300.15181@dejanews.com>...

<snip> [some discussions about steering posts and other stuff]

>Do people agree that there's a difference between reconfigurable
>computing and FPGAs?  Do these topics warrent separate discussion
>spaces?  (Comments?)

nope; i've seen some discussions of reconfigurable stuff in this newsgroup,
which makes sense, since it's an application of fpgas.  however, the volume
of *all* of the discussions about fpga's combined are relatively low and
easily fit into one newsgroup.  reading two newsgroups and seeing lots of
posts and 'steers' perhaps would be more annoying than simply reading one
newsgroup with both reconfigurable and non-reconfigurable posts in it and
making a decision on what to read and what not to read.

then again, it's probably not the biggest thing in life in general.  but
would hate to have the net police saying, "you should post there, not here"
in their pompous tone which is usually the result of being a religious
zealot to the net and some rules somewhere which few ever even know exist. 
and i may, perhaps, start to sweat if the discussion about an fpga-type
perhaps needs to go into it's applicability to reconfigurable computing in
concert with other features; but then i must decide where to post so the
net zealots don't come after me (and i'm not paranoid, they've come after
me before for discussing how to write i/o commands for win 'nt and 95 in
delphi - oh, the shame of it all - they droned on and on and on in their
religious fervor, quoting all these rules and netiquette and other
nonsense), and i will nervously make my selection, and quiver when i press
the post to group button.  of course, i gotta start worrying about which
topics are worthy of cross-posting; and if i cross-post in the middle of a
thread, gotta include enough background so somebody can pick up the topic
and understand it.  see, it's already too much for this minor league brain
of mine.

<someone said>

>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.  

so, if this place is intended for reconfigurable computing, and it is
definitely not overloaded, it seems that we're in pretty good shape.

<someone else said> 

>is comp.arch.fpga the right forum to discuss such topics?  It's
>charter indicates that it *should* be, but the current discussions
>on FPGA CAD tools seem to indicate otherwise.  

uh, perhaps the net police should come out and send this cad tool
discussions to where-ever cad tool discussions should go.  but then again,
i was just reading about atmel's new cad tools to enable reconfigurable
computing on their at6000 series.  rats, more worries about cross-posting.

<yet someone else said>

> 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.

now, what if i wish to discuss reconfigurable 'puting in
NON-general-purpuse computing.  where do i post that?

<and that yet someone else also said>

> 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).

by the way, we have done and seen some designs in fpga's that are anything
but static - quite programmable on the fly (like 160 personality changes
per second), for example, and others that showed a great deal of
reprogrammability - although without the ultimate potential of some of the
newer systems.  of course, the sram fpga proponents (and guys marching
around with reconfigurable computing buzzwords flowing from their mouths
who've never even designed an fpga) were less than thrilled when they found
out what people are doing with the evil antifuse-based devices.  like
actually thinking about what they're doing.

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


so, the big conclusion is: the volume of posts to this newsgroup is
moderate and well-sized now,

and i don't see a big overflow of posts on reconfigurable computing making
this newsgroup unreadable or confusing.

rk


_____________________________


p.s. what do the field programmable interconnect guys have to say?  do they
have their own newsgroup?

p.s.s. how about the field programmable analog circuits?  maybe we should
be building some more analog computers?
	maybe they'll be coming back in style like other recycled ideas.

p.s.s.s. i saw in the paper an ad for a board with the xilinx xc6216 on it
that plugs into the pci bus; i called the
	number in the ad and nothing has happenned.  called back, same deal.  so,
anybody know where i can
	buy one of these boards?  want to get it quick, too, for an e-valuation. 
<-- this part of the post is serious.

Article: 6567
Subject: Re: What is M1?
From: Simon Bacon <SimonBacon@tile.demon.co.uk>
Date: Tue, 03 Jun 97 12:59:45 GMT
Links: << >>  << T >>  << A >>

In article <01bc6fe8$794e6d50$30a5b8cd@p5-166>
           jsgray@acm.org.nospam "Jan Gray" writes:

> It would be very helpful for those of us with homegrown tools, who are
> considering a move from XNF to EDIF, if Xilinx would publish a
> specification of how to emit EDIF for Xilinx tools, e.g. how to target
> specific device features, specify timespecs, placement constraints, etc. 
> That is, don't repeat the XNF experience where the information was
> available only under NDA or through "reverse engineering" of
> otherwise-generated XNF.

Absolutely right.  If Xilinx want to reduce their support costs they
could publish their EDIF syntax in YACC format and even produce a
stand-alone syntax checker.

Simon


Article: 6568
Subject: test
From: Pelican <wnguyen@pacbell.net>
Date: Tue, 03 Jun 1997 07:55:00 -0700
Links: << >>  << T >>  << A >>
test
Article: 6569
Subject: Re: new to FPGAs
From: "Steven K. Knapp" <sknapp @ optimagic.com>
Date: 3 Jun 1997 16:09:59 GMT
Links: << >>  << T >>  << A >>
There is comprehensive information on all matters related to programmable
logic
on the Programmable Logic Jump Station at 'http://www.optimagic.com'.  It
has information on:

FPGA/CPLD Companies:  http://www.optimagic.com/companies.html
    Design Software:  http://www.optimagic.com/software.html
        Consultants:  http://www.optimagic.com/consultants.html
              Books:  http://www.optimagic.com/books.html
             Boards:  http://www.optimagic.com/boards.html
         Newsgroups:  http://www.optimagic.com/newsgroups.html
 FPGA/CPLD Research:  http://www.optimagic.com/research.html
 Information Search:  http://www.optimagic.com/search.html
-- 
Steven Knapp
OptiMagic(tm) Logic Design Solutions
E-mail:  sknapp @ optimagic.com
Programmable Logic Jump Station:  http://www.netcom.com/~optmagic

Henry F Fernandes <hff135@skorpio3.usask.ca> wrote in article
<5mkjk8$52@tribune.usask.ca>...
| I am new to this area. Can any point out a FAQ or any suitable site on
the
| web where someone like me can find information?
| 
| --
| ----------- Henry Fernandes	(hff135@cs.usask.ca)
| http://www.cs.usask.ca/homepages/grads/hff135/index.html
| - Glory Glory Man United
| 
Article: 6570
Subject: Re: What is M1?
From: "Steven K. Knapp" <sknapp @ optimagic.com>
Date: 3 Jun 1997 16:19:37 GMT
Links: << >>  << T >>  << A >>
[snip]
 
| >Perhaps such a EDIF-for-Xiilnx specification is available, but I haven't
| >yet received an update since 6.0 and it doesn't appear to be on the
Xilinx
| >website.
| 
| You probably won't. Xilinx has historicly considered this information
| to be propietary.
| 
The XNF specification was previously available under non-disclosure to
practically any user with a valid reason to want it.  However, you can now
obtain a copy of the Xilinx .XNF specification via their website at
'ftp://ftp.xilinx.com/pub/documentation/xactstep6/xnfspec.pdf', 390 KB.  I
haven't seen an equivalent document for Xilinx EDIF, yet.

If you are interested in the M1 release, take a look at
'http://www.xilinx.com/support/techsup/ftp/htm_index/docs_M1.htm' for a
list of relevant documents in Adobe Acrobat (PDF) format.


-- 
Steven Knapp
OptiMagic(tm) Logic Design Solutions
E-mail:  sknapp @ optimagic.com
Programmable Logic Jump Station:  http://www.optimagic.com
Article: 6571
Subject: Re: Any designs to avoid in FPGAs
From: "Steven K. Knapp" <sknapp @ optimagic.com>
Date: 3 Jun 1997 16:29:22 GMT
Links: << >>  << T >>  << A >>
| 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).

While I agree that FPGA arithmetic could always be faster, there are some
truly remarkable designs using FPGAs for arithmetic processing, today. 
Most noteworthy are those in Digital Signal Processing.  The FPGA's fast
carry logic and on-chip memory make them ideal for such applications.  For
some standard DSP functions like FIR filters, an FPGA outperforms a
leading-edge DSP processor by 10x or more!  I've seen cases where a single
large FPGA replaced a board-full of DSP processors.  FPGAs are currently
best used in fixed-point DSP applications.

For those interested, here are a few relevant links:

General overview of using FPGAs for DSP: 
'http://www.xilinx.com/apps/dspoview.htm'

Xilinx DSP applications site:  'http://www.xilinx.com/apps/dsp.htm'

Altera DSP applications site: 
'http://www.altera.com/html/programs/ta_dsp.html'


-- 
Steven Knapp
OptiMagic(tm) Logic Design Solutions
E-mail:  sknapp @ optimagic.com
Programmable Logic Jump Station:  http://www.optimagic.com
Article: 6572
Subject: ECL FPGA Demo at DAC
From: Eric Fleischman <ericggc@ix.netcom.com>
Date: Tue, 03 Jun 1997 10:48:10 -0700
Links: << >>  << T >>  << A >>
If you are attending the Design Automation Conference, don't miss
DynaChip's demonstration of their Fast Field Programmable Gate Array. 
These unique FPGAs use Active Repeaters to propagate signals with
extremely short routing delays.

At the demo you will see:

   - Over 100 MHz system-level performance using HDL synthesis flows
   - Short, predictable routing delays that are not affected by fanout
   - Ultra high speed I/O structures that support up to 200 MHz clock
and data
   - ECL, PECL and GTL interface levels

Dates and Times:

June 9, 10 and 11 at the Anaheim Convention Center

Monday at 10:00 and Tuesday at 11:00 in Exemplar's Booth #852
Monday, Tuesday and Wednesday from 2:00 to 4:00 in Synopsys' Suite
#D3418

For an appointment, send email to support@dyna.com or just stop by the
sites listed above.

You can get more information on the company at their web site
http://www.dyna.com
Article: 6573
Subject: New High-Speed FPGA - Demo at DAC
From: Eric Fleischman <ericggc@ix.netcom.com>
Date: Tue, 03 Jun 1997 10:49:26 -0700
Links: << >>  << T >>  << A >>
If you are attending the Design Automation Conference, don't miss
DynaChip's demonstration of their Fast Field Programmable Gate Array. 
These unique FPGAs use Active Repeaters to propagate signals with
extremely short routing delays.

At the demo you will see:

   - Over 100 MHz system-level performance using HDL synthesis flows
   - Short, predictable routing delays that are not affected by fanout
   - Ultra high speed I/O structures that support up to 200 MHz clock
and data
   - ECL, PECL and GTL interface levels

Dates and Times:

June 9, 10 and 11 at the Anaheim Convention Center

Monday at 10:00 and Tuesday at 11:00 in Exemplar's Booth #852
Monday, Tuesday and Wednesday from 2:00 to 4:00 in Synopsys' Suite
#D3418

For an appointment, send email to support@dyna.com or just stop by the
sites listed above.

You can get more information on the company at their web site
http://www.dyna.com
Article: 6574
Subject: Re: Fine Pitch PQFP : anyone any hassles?
From: johnm@Newbridge.COM (John McDougall)
Date: 3 Jun 1997 18:56:37 GMT
Links: << >>  << T >>  << A >>
In article <5mvdit$mbh$1@news.nero.net>,
Steen Larsen <steenl@pal.ece.orst.edu> wrote:
>In article <5mjqq1$m3j$1@news01.btx.dtag.de>, HTD <Hans Dermot Doran> wrote:
>>On Mon, 26 May 1997 20:47:42 GMT, stuart.summerville@practel.com.au
>>(Stuart Summerville) wrote:
>>
>>>Hi all,
>>>
>>>I have a 208pin PQFP fpga  (0.5mm pitch) on a board. I am having
>>>problems with pin connections to the board. Attempting to re-heat the
>>>solder to make a clean connection seems to create problems with
>>>surrounding pins - it doesn't take much to get a minute solder bridge
>>>between two pins.
>>>
>>>Two questions:
>>>
>>>1) Do any of you find such packages tend to come in with such
>>>connection problems?
>>>
>>>2) What is the feeling about attempting to re-solder such pins if a
>>>connection seems to be flakey? Am I wasting my time trying to fix it?
>>>Maybe if some pins have flakey connections then others on the same
>>>chip are likely to (eg. if some are bent down too much, then obviously
>>>the others are at a different level...).
>>>
>>
>Resoldering can be done, but I am no good at it.  Sometimes the chip has
>to be removed and the board traces will only handle 3-4 removals before
>the traces separate from the board.  
>
>The easiest solution for me was to go with the Altera 208PQFP socket since
>I'm using an OTP FPGA.

I use a hot-air gun with a small nozzle. Works great.



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