comp.arch.fpga.<mfr>

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

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:

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

Wow. Very, very, very good point.

- a

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.

I say "nay"

c.a.fpga is sufficiently low volume, and high SNR that this isn't really justified, for the inevitable dilution that it would create. Most of the problems you suggest as reasons for a change are better handled by a decent newsreader client that can ignore threads.

The split is unnecessary - threads are usually quickly identified either from the subject or the first post, and same for soft-CPU threads.

comp.arch.fpga.cpu would not stop e.g. C programming questions in c.a.fpga anyway... - in the same way that comp.lang.vhdl still gets FPGA synthesis questions and so on.

c.a.fpga is the best technical newsgroup I know - the SNR is remarkable, even with the occasional inter-vendor marketing war. Don't try to fix what's not broken.

Regards,

John

Yes, keep us together. Where else could we ventilate our sibling rivalry? No audience, how boring! But I do think we should make it more entertaining and informative, less argumentative and poisonous. Peter Alfke, you-know-whith-whom