I see a lot of posts here that are specific to a single vendor's
devices or that device-vendor's tools.  I think it would make things a
bit more organized if we had a few subgroups beneath comp.arch.fpga
for the specific vendors (just like comp.os), and kept comp.arch.fpga
itself for vendor-agnostic (or vendor-comparative) discussions.
Traffic has been pretty high lately (~50 posts/day).

If you support this (or if you don't), please post in this thread.
Also let me know what vendors you'd like to see listed.  Off the top
of my head, alphabetically,

   Actel
   Altera
   Atmel
   Cypress
   Lattice
   Quicklogic
   Xilinx

I think it would be wise to keep the list short by limiting it to
vendors currently producing and selling chips, and which are available
from distributors at the retail level (ie EOL'ed or a specialty
device).

If there is sufficient support, I will RFD the matter over on
news.announce.newgroups and reference this thread as justification.
The call for votes will be crossposted here.

Thanks,

  - a

-- 
"I didn't see it then, but it turned out that getting fired was the
 best thing that could have ever happened to me. The heaviness of
 being successful was replaced by the lightness of being a beginner
 again, less sure about everything. It freed me to enter one of the
 most creative periods of my life."

          -- Steve Jobs, commencement speech at Stanford, June 2005

On Fri, 17 Jun 2005 02:34:48 -0700, Adam Megacz
<m...@cs.berkeley.edu> wrote:

>
>I see a lot of posts here that are specific to a single vendor's
>devices or that device-vendor's tools.  I think it would make things a
>bit more organized if we had a few subgroups beneath comp.arch.fpga
>for the specific vendors (just like comp.os), and kept comp.arch.fpga
>itself for vendor-agnostic (or vendor-comparative) discussions.
>Traffic has been pretty high lately (~50 posts/day).
>
>If you support this (or if you don't), please post in this thread.
>Also let me know what vendors you'd like to see listed.  Off the top
>of my head, alphabetically,
>
>   Actel
>   Altera
>   Atmel
>   Cypress
>   Lattice
>   Quicklogic
>   Xilinx
>
>I think it would be wise to keep the list short by limiting it to
>vendors currently producing and selling chips, and which are available
>from distributors at the retail level (ie EOL'ed or a specialty
>device).
>
>If there is sufficient support, I will RFD the matter over on
>news.announce.newgroups and reference this thread as justification.
>The call for votes will be crossposted here.
>
>Thanks,
>
>  - a

I don't see that there is enough traffic to justify it, and it will ineviably reduce the
readership
as many users will not bother looking in all the NGs, therefore reducing the usefulness.
Most of us are busy, and the difference in time and effort between speed-reading a few
dozen headers
a day on one NG, and reading a handful of headers in several NGs will undoubtedly mean
that fewer
people will bother. The busiest people are quite likely to be those most valuable to the
NG in terms
of experience and expertise, and nothing should be done to discourage them from
participating.

Many questions asked by a user of a specific FPGA may actually be fairly generic, so they
may miss
useful answers from people who only look in one of the maker-specific NGs. 

It will also be the case that the useful 'experts' will only subscribe to the NG for the
maker they
are actively using, but they may well have useful knowledge of others.

So in a word, NO! 

comp.arch.fpga.cpu might be a good idea.
Somewhere for all the NIOS &
MicroBlaze queries.

Cheers,
Jon

"Jon Beniston" <j...@beniston.com> wrote in message
news:1...@g14g2000cwa.googlegroups.com...
> comp.arch.fpga.cpu might be a good idea. Somewhere for all the NIOS &
> MicroBlaze queries.
>
> Cheers,
> Jon
>

Which newsgroup would I post my question relating to my implementation of a
6805 core in an fpga?  The .cpu group or the parent group or both.  At an
average of 10 topics per day, I'd prefer to keep it in one place, like Mike.

Cheers,
Alf

Unbeliever wrote:
> "Jon Beniston" <j...@beniston.com> wrote in message
> news:1...@g14g2000cwa.googlegroups.com...
> > comp.arch.fpga.cpu might be a good idea. Somewhere for all the NIOS &
> > MicroBlaze queries.
> >
> > Cheers,
> > Jon
> >
>
> Which newsgroup would I post my question relating to my implementation of a
> 6805 core in an fpga?  The .cpu group or the parent group or both.  At an
> average of 10 topics per day, I'd prefer to keep it in one place, like Mike.
>
> Cheers,
> Alf

I agree.  ~50 posts a day is not ~50 threads a day.  I use the google
groups site to access the newsgroup and almost never need to click
the "older topics" to find a thread that's still active.  I enjoy
seeing
threads related to vendors of fpga's I'm not currently using.  I also
enjoy seeing topics not related to my current work.  I would miss most
of this if I had to browse through multiple groups to find them.

Just my 2 cents.
Gabor

I would prefer to keep the group together.  If
one of the "little guys" 
comes up with a very marketable device, the buzz here will tend to get 
people interested.  Knowing some of the issues in other devices helps to 
shape expectations when switching to that vendor's part.

I *do* like the idea of moving the CPU stuff.  There has been a huge 
amount of processor related traffic which doesn't really relate to the 
hardware but to the "core" used.  I don't use any processors in my FPGA 
designs yet so the threads just clutter my FPGA experience here.  I read 
comp.lang.verilog but don't bother with comp.lang.vhdl and subscribe to 
both.  There's no reason someone designing with CPUs couldn't do both. 
Also, cross posting when a topic covers FPGA hardware AND the CPU is 
reasonable.

I like to see the occasional posts here on DSP implementation when they 
refer to hardware yet wouldn't enjoy a diatribe on how to adapt 
coefficients.  Hardware related DSP can be cross posted for those as well.

I'd hate to see the vendor schism.


Adam Megacz wrote:

> I see a lot of posts here that are specific to a single vendor's
> devices or that device-vendor's tools.  I think it would make things a
> bit more organized if we had a few subgroups beneath comp.arch.fpga
> for the specific vendors (just like comp.os), and kept comp.arch.fpga
> itself for vendor-agnostic (or vendor-comparative) discussions.
> Traffic has been pretty high lately (~50 posts/day).

<snip>

Hi - 

If we're going to split up the newsgroup--and I strongly suggest that
we don't--here are some suggestions:

  .vendor-to-vendor-flames - FPGA vendor employees argue endlessly
about whose performance claims are more specious, whose parts are less
available, and whose manners are more uncouth.

  .homework-problems - Repeated questions about traffic lights and
Coke machines, followed by "do it yourself" responses, "here's where
to start looking" responses, and "here's how to do it" responses, the
last of which guarantee that the stream of questions will never cease.

  .schematics-vs-hdl - Because we haven't quite beaten this one to
death yet.

  .i-need-an-orcad-symbol - Well, I mean, *I* don't need an Orcad
symbol.  It's for a friend.

  .recruiters - Offers of fabulous FPGA design jobs that require you
to relocate to the Falkland Islands or Faluja.  Sign up before
midnight tonight and get a free set of steak knives.

  .things-i-could-have-googled-for - Self-explanatory.  Or maybe not.

Bob Perlman
Cambrian Design Works


On Fri, 17 Jun 2005 02:34:48 -0700, Adam Megacz
<m...@cs.berkeley.edu> wrote:

>
>I see a lot of posts here that are specific to a single vendor's
>devices or that device-vendor's tools.  I think it would make things a
>bit more organized if we had a few subgroups beneath comp.arch.fpga
>for the specific vendors (just like comp.os), and kept comp.arch.fpga
>itself for vendor-agnostic (or vendor-comparative) discussions.
>Traffic has been pretty high lately (~50 posts/day).
>
>If you support this (or if you don't), please post in this thread.
>Also let me know what vendors you'd like to see listed.  Off the top
>of my head, alphabetically,
>
>   Actel
>   Altera
>   Atmel
>   Cypress
>   Lattice
>   Quicklogic
>   Xilinx
>
>I think it would be wise to keep the list short by limiting it to
>vendors currently producing and selling chips, and which are available
>from distributors at the retail level (ie EOL'ed or a specialty
>device).
>
>If there is sufficient support, I will RFD the matter over on
>news.announce.newgroups and reference this thread as justification.
>The call for votes will be crossposted here.
>
>Thanks,
>
>  - a

John_H <j...@mail.com> writes:
> If one of the "little guys" comes up with a very marketable device,
> the buzz here will tend to get people interested.

Wow.  Very, very, very good point.

  - a

Jon Beniston wrote:
> comp.arch.fpga.cpu might be a good idea. Somewhere for all the NIOS &
> MicroBlaze queries.

I'd second that :)  It's one of the few major topics that generate quite 
a lot of traffic, while being quite distinctly separate from the other 
topics discussed here - different toolflows, compiler issues etc.  If 
you were to consider a split, this would seem to be an obvious one.

I don't think separate hierarchies for vendors would benefit anyone 
particularly though - a lot of stuff is quite general.  I think this was 
covered elsewhere in this thread.

My 2c
Jeremy

Bob,
Now you're talking! How about
.good-book-about

.i-cant-get-linux-to-work-with.impact
.i-cant-get-linux-to-work-with.ise
.i-cant-get-linux-to-work-with.edk
.i-cant-get-linux-to-work-with.anything

.i-cant-get-any.spartan3
.i-cant-get-any.virtex4
.i-cant-get-any.satisfaction

To help folks filter stuff, I'd be happy to include [XILINX] or [ALTERA] in 
the subject line of posts specific about a vendor, but extra groups is a 
rubbish idea, IMO.
Cheers, Syms.