Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
In a previous article jhallen@world.std.com (Joseph H Allen) writes: : ;Suppose I'm doing a read burst. The target must watch the IRDY# line from :the initiator to determine whether to hold the current read data or to send ;out the next word. IRDY# can arrive as late as 7ns before the clock edge, :and the data must be out by 11ns after to the clock edge- thus you have 18ns ;for this decision to occur, including pad propagation delays and big routing :delays between IRDY# and (perhaps) an output mux. Is this correct or am I ;missing something here? You are correct. PCI is very hard to do with FPGA if you want high throughput. Althought it this may not be true, I often get a feeling that the spec is designed to keep little guys who can't afford to do gate arrays off the market. Instead of output muxes, have you thought about possibly feeding IRDY to flip-flops' enable input? Or was that what you were talking about? In most cases, that will give you the best timing. Whether you can sustain the burst internally is another story. If you are doing it for a research project, you may be interested in Lucent's plan to incoporate a hard wired PCI section on some of their ORCA3C family of FPGAs. Right now it looks like they may be too expensive for commercial use because PCI products are very cost sensitive.Article: 7001
Klaus Falser wrote: > > Hello, > can anybody recommend me some literature about production testing when > using CPLD's? > Is it really true, that the design inside the CPLD must not be tested an > can be assumed as working correctly (apart from design errors)? Does it > make sense to have test pins where internal signals can be monitored? > > I'm very gratefull for every hint I can get. > Thank you very much > K. Falser I have been searching for that, too. We design flight critical boards and would like to be able to test the final design implemented in CPLD/FPGAs. Some FPGAs give you the capablity to probe internal nets without taking them out to the I/O boundary (check Xilinx and Actel FPGAs). One thing that one can do is to MUX the desired nodes and clock them out on an output node. Another trick is explained on XAPP076 "Embedded Instrumentation Using XC9500 CPLDs" on Xilinx web site. You are right that these devices are tested in factory, that includes the flash and eeprom ( but not the Anti-fuse elements) programming elements on the silicon. Regards, Kayvon Irani Los AngelesArticle: 7002
In article <5r08ek$fke@neptune.myri.com>,
Wen-King Su <wen-king@myri.com> wrote:
>In a previous article jhallen@world.std.com (Joseph H Allen) writes:
>;Suppose I'm doing a read burst. The target must watch the IRDY# line from
>:the initiator to determine whether to hold the current read data or to send
>;out the next word. IRDY# can arrive as late as 7ns before the clock edge,
>:and the data must be out by 11ns after to the clock edge- thus you have 18ns
>;for this decision to occur, including pad propagation delays and big routing
>:delays between IRDY# and (perhaps) an output mux. Is this correct or am I
>;missing something here?
>You are correct. PCI is very hard to do with FPGA if you want high
>throughput. Althought it this may not be true, I often get a feeling
>that the spec is designed to keep little guys who can't afford to do gate
>arrays off the market. Instead of output muxes, have you thought about
>possibly feeding IRDY to flip-flops' enable input? Or was that what you
>were talking about? In most cases, that will give you the best timing.
For example for a Xilinx XC4010E-3:
The clock pad to output pad delay is 11ns, so you can't delay the clock to
fix anything. Thus the required IRDY# setup time is:
Input delay: 2.5ns
Inverter (clb) delay: 2ns
Routing delay (clb output to 32 clock enables): 9ns
Output FF clock enable setup time: 2.5ns
Total: 16ns
Subtract minimum clock pad to
output ff clock delay: less than 6.8ns- I guess 4ns
IRDY# setup time: 12ns
but PCI only gives you 7ns.
The routing delay is as returned by xact when used to place and route the
design with only the IRDY# line and output flip-flops.
>Whether you can sustain the burst internally is another story.
But there you have the full 30ns cycle time to play with and can use
pipelining. I can't imagine how they deal with this problem, even in ASICs,
for 66MHz PCI. Why coundn't they have just made the IRDY# and TRDY# lines
pipelined?
--
/* jhallen@world.std.com (192.74.137.5) */ /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
Article: 7003I wrote my project in VHDL for Altera 10k. I hope use Synopsys to do logic systhesis. In my VHDL file, I have use lpm_megafunction and lots of a_74XX component. How to setup synopsys environment to work well? Thanks. Casper Chen -- NAMES Casper K. Chen kschen@vlsi.ee.hwh.edu.tw SNAIL No. 111, HwaHsin St., ChungHo City, Taipei, Taiwan PHONE +886-2-9426424Ext301 FAX +886-2-9426424Ext203Article: 7004
In a previous article jhallen@world.std.com (Joseph H Allen) writes: :For example for a Xilinx XC4010E-3: ; :The clock pad to output pad delay is 11ns, so you can't delay the clock to ;fix anything. Thus the required IRDY# setup time is: : ; Input delay: 2.5ns : Inverter (clb) delay: 2ns ;Routing delay (clb output to 32 clock enables): 9ns : Output FF clock enable setup time: 2.5ns ; Total: 16ns : ; Subtract minimum clock pad to : output ff clock delay: less than 6.8ns- I guess 4ns ; : IRDY# setup time: 12ns ; :but PCI only gives you 7ns. ; :The routing delay is as returned by xact when used to place and route the ;design with only the IRDY# line and output flip-flops. It would be a surprise if the clock delay is only 4ns. But in any case I agree XC4010E-3 isn't fast enough for what you need. Try Lucent ORCA, which has a selectable FF enable polarity. ;>Whether you can sustain the burst internally is another story. : ;But there you have the full 30ns cycle time to play with and can use :pipelining. I can't imagine how they deal with this problem, even in ASICs, ;for 66MHz PCI. Why coundn't they have just made the IRDY# and TRDY# lines :pipelined? If we can build processors that run at 200-300 MHz, I don't see why a 66MHz point-to-point link will be difficult for ASIC. However, I agree with you about PCI protocol's deficiency. The sad thing is there is nothing one can do about it. With proper pipelining in the bus protocol, we should be able to achieve 66MHz with FPGA currently available.Article: 7005
If you are planning to use version 2.2 or earlier, forget it. The Foundation package contains software by Xilinx and Aldec. The Aldec part (VHDL, Schematic capture, simulation) has a very fancy GUI and fancy functionality, but it simply does not work. The Aldec software performed so bad that we decided to halt the project altogether. Now, a jear later i am planning to take the project up again, if there is goed software available and Xilinx is willing to give it to mee free. (Yes _FREE_! Xilinx owes me one!) Positive notes: The software written by Xilinx themselves is OK. The support from the Xilinx distributor here in Holland is realy exelent!! ---------- Arjan Navneet S Yadav wrote: > > hi, > > if anyone has used the VHDL synthesizer available with > Xilinx Foundation series could they summarize their experience ? > especially how does it compare to viewlogic's vhdl synthesizer > and to Synopsys FPGA Express for PCs. > > is the Synopsys FPGA Express for PCs synthesizer as good > as the one which they offer on unix workstations ? > > i would appreciate an email reply besides the news posting. > news delivery at our site is rather unreliable. > > thanks in advance. > > cheers, > yadav > > email:yadav@cse.iitb.ernet.inArticle: 7006
Now available is a technical report that summarizes our work in
hardware-based GAs (the abstract is appended to this message). It
includes a detailed description of the design (called the HGA),
analytical and empirical studies of the design to identify the
pipeline's bottlenecks, results from simulations and our prototype, a
description of several problems that the HGA is applicable to, and a
comparison with other hardware implementations of GAs. It can be
obtained from
http://www.cs.wustl.edu/~sds/research/r-area.html#hga
Also available at that URL are the design's (VHDL) source code, our
conference paper of two years ago, and my M.S. thesis of three years ago.
Later,
Stephen
--
Stephen D. Scott sds@cs.wustl.edu
Department of Computer Science 535 Jolley Hall
Washington University, Campus Box 1045 phone: (314) 935-4425
One Brookings Drive fax: (314) 935-7302
St. Louis, MO 63130-4899 URL: http://www.cs.wustl.edu/~sds/
================================= CUT HERE =================================
Abstract
A genetic algorithm (GA) is an optimization method based on natural
selection. Genetic algorithms have been applied to many hard
optimization problems including VLSI layout optimization, boolean
satisfiability, power system control, fault detection, control systems,
and signal processing. GAs have been recognized as a robust
general-purpose optimization technique. But application of GAs to
increasingly complex problems can overwhelm software implementations of
GAs, causing unacceptable delays in the optimization process. This is
true of any non-trivial application of GAs if the search space is large
or if real-time performance is necessary. It follows that a hardware
implementation of a GA is desirable for application to problems too
complex for software-based GAs.
Hardware's speed advantage and its ability to parallelize offer great
rewards to genetic algorithms. Speedups of 1-2 orders of magnitude
have been observed when frequently used software routines were
implemented in hardware by way of field-programmable gate arrays
(FPGAs). Since most of the GA's operations are simple, a hardware
implementation is feasible. Reprogrammability is essential in a
general-purpose GA engine because certain GA modules require
changeability (e.g. the function to be optimized by the GA). In
hardware, reprogrammability is possible with FPGAs. Thus an FPGA-based
GA is both feasible and desirable.
A fully functional self-contained hardware-based genetic algorithm (the
HGA) is presented here as a proof-of-concept system. It was designed
using VHDL to allow for easy scalability. It is designed to act as a
coprocessor with the CPU of a PC. The user programs the FPGAs which
implement the function to be optimized. Other GA parameters may also be
specified by the user. An analysis of the design is given that
identifies the bottleneck of the HGA's pipeline under varying
conditions. Simulation results of the HGA are also presented. A
prototype HGA is described and compared to a similar GA implemented in
software. In our tests, the prototype and simulations took two to five
percent as many clock cycles to run as the software-based GA. Suggested
design improvements could dramatically increase the HGA's speed even
further. Finally, we give other potential applications of the HGA which
are feasible with current FPGA technology.
Article: 7007>If you are doing it for a research project, you may be interested in >Lucent's plan to incoporate a hard wired PCI section on some of their >ORCA3C family of FPGAs. Using such a part would make a subsequent ASIC version a lot of work :) Peter. Return address is invalid to help stop junk mail. E-mail replies to z80@digiserve.com.Article: 7008
In article <33cf25b0.1138643@news.unipg.it>, Gianpaolo Scassellati <tivpc@geocities.com> writes >How can I implement a clock generator in a Altera device ? >(Vhdl or Ahdl) >I need to specify clock frequency, so I cannot make a simple feedback >chain. > >Thanks. Hi, IMHO you can't, the only thing you can do is to get a frequency source and then scale it down via a counter. Don't be fooled by the 'after Nns', this comes from the modelling concept of VHDL. You would need to create a down counter which can be set that will toggle a flip flop etc. You could have your frequency select lines (if you have a discrete set) select the down count. See if your compiler has a model for a 74HC40103. -- Andre PowellArticle: 7009
Joseph, > Suppose I'm doing a read burst. The target must watch the IRDY# line from > the initiator to determine whether to hold the current read data or to send > out the next word. IRDY# can arrive as late as 7ns before the clock edge, > and the data must be out by 11ns after to the clock edge- thus you have 18ns > for this decision to occur, including pad propagation delays and big routing > delays between IRDY# and (perhaps) an output mux. Is this correct or am I > missing something here? Assuming a Xilinx...but still true for most FPGAs.... You are correct that you have to react to IRDY within the next cycle. Since there is also clock input delay, you can add a few ns to the 7ns setup time. Therefore you do have enough time to go through one FMAP to a flop to control the CE of the IOBs. If you use the CE's in the IOB FFs, then the next data is waiting on the internal tri-state bus (correct implementation of a PCI in an FPGA is to use the internal tri-state bus for all the registers...do not use a logic mux...that implementation uses more resources and timing is worse) and can be clocked in when needed, and the data in the IOB FFs can be held if needed. > This sucks big time, if true. It means you can't use pad output flip-flops > for the bus (once IRDY is received it's too late to change the data in any > output flip-flops). In a Xilinx, you have to use the PAD I/O flops, and their CEs...it's the only way to make PCI timing, and it is good resource utilization. <snip> > So (assuming I'm not missing something here), what moron designed PCI > without thinking about pipeline delays? PCI was designed to be implemented in ASICs. But I don't disagree that there are some things that could have been done to make implementation more 'palatible', but it would have been at a performance sacrifice. To implement PCI in an FPGA, it takes a lot of understanding of the PCI spec, the architecture/features of the FPGA being used, deterministic logic design and mapping, and a lot of hand placement... It's not that easy, but it isn't that hard if you know the above... Austin Franklin darkroom@ix.netcom.comArticle: 7010
See the Xilinx Data Book for the I/O timing. The 4013E-3 makes PCI I/O timing just fine. > It would be a surprise if the clock delay is only 4ns. But in any case I > agree XC4010E-3 isn't fast enough for what you need. Try Lucent ORCA, > which has a selectable FF enable polarity. I completely disagree. I have done many PCI interfaces in Xilinx 4013E-3 parts, and it makes PCI timing just fine. You need to use a -2 to do master mode, but -3 is fine for target. Master mode requires you to route the raw PCI control signals to more destinations than a target requires, and therefore requires the faster part. Also, the FF enable polarity is not a problem. IRDY is inverted in the logic that is used to drive the flop that drives the IOB CE line, so this is not a problem. You have time to go through one FMAP to one flop and still make PCI timing. Austin Franklin darkroom@ix.netcom.comArticle: 7011
In a previous article z80@dserve.com (Peter) writes: : ; :>If you are doing it for a research project, you may be interested in ;>Lucent's plan to incoporate a hard wired PCI section on some of their :>ORCA3C family of FPGAs. ; :Using such a part would make a subsequent ASIC version a lot of work ;:) If you are going commercial with a moderate volume ( ~10K units), and you do not have enough resources to use ASIC as if it is FPGA, this approach actually makes a lot of sense. Lucent can do ASIC conversion for you, and they are not exactly asking for an arm and a leg at that volume. What I would really like to see happen is a union of antifuse and SRAM based FPGA technology. One of the things that will make the PCI equipped ORCA expensive is the small size of its market. Instead, if we can add superfast antifuse connected links to a conventional SRAM based FPGA, we can implement the same speed sensitive logic core with antifuse, and leave the rest of the chip reconfigurable. No need to fragment the market by incorporating different custom ASIC cores into the same family of products.Article: 7012
Peter <z80@dserve.com> wrote: >>If you are doing it for a research project, you may be interested in >>Lucent's plan to incoporate a hard wired PCI section on some of their >>ORCA3C family of FPGAs. > >Using such a part would make a subsequent ASIC version a lot of work >:) Don't know why... their ASIC data books all have PCI interface macrocell units in the "System Level Cores" section. Presumably even the same one as on their ASICS, if they're thinking... -george william herbert gherbert@crl.comArticle: 7013
Peter <z80@dserve.com> wrote: >>If you are doing it for a research project, you may be interested in >>Lucent's plan to incoporate a hard wired PCI section on some of their >>ORCA3C family of FPGAs. > >Using such a part would make a subsequent ASIC version a lot of work >:) Don't know why... their ASIC data books all have PCI interface macrocell units in the "System Level Cores" section. Presumably even the same one as on their FPGAs, if they're thinking... -george william herbert gherbert@crl.comArticle: 7014
George Noten wrote: > A.C.Rochat (arjan.rochat@pi.net) wrote: > : If you are planning to use version 2.2 or earlier, forget it. > > : The Foundation package contains software by Xilinx and Aldec. > > : The Aldec part (VHDL, Schematic capture, simulation) has a very > fancy > : GUI and fancy functionality, but it simply does not work. > > : The Aldec software performed so bad that we decided to halt the > project > : altogether. > > : Now, a jear later i am planning to take the project up again, if > there > : is goed software > : available and Xilinx is willing to give it to mee free. (Yes _FREE_! > > : Xilinx owes me one!) > > : Positive notes: > : The software written by Xilinx themselves is OK. > : The support from the Xilinx distributor here in Holland is realy > : exelent!! > > This reminds me very much of my own experience with Viewlogic > PROseries. > The only good part of it was the beta-test version of Speedwave > simulator. > The synthesis just did not work. Now I know that PRO-/View- synthesis > > tools are not to be trusted. You are telling me that neither is > Aldec. > Can anybody recommend something that is good enough and does not cost > you your life savings? What about the new VHDL synthesis tool from > MINC? > > George. I have used the Foundation Tools from XILINX and they indeed do work. And they are very cost effective. I also own Exemplar, Model Tech and have used many other VHDL packages. By far the most cost effective are the Foundation tools. You can get the whole package with an FPGA development board from APS for $2800.00. The MINC VHDL compiler does not come with ROUTER software and is size limited. XILINX would package the ALDEC tools, and continue to (yes the new M1 Foundation will have ALDEC and FPGA Express[only for large parts]). If you are having problems you should check the XILINX app notes or ALDEC. Perhaps you are doing something wrong. You can see the APS kits at http://www.associatedpro.com -- ---------------------------------------------------------------- Richard Schwarz, President Associated Professional Systems (APS) EDA and Communications Tools http://www.associatedpro.com richard@associatedpro.com 410.569.5897 fx:410.661.2760Article: 7015
In article <5qqf36$r1r@thorgal.et.tudelft.nl>, "L. Kumpa" <LKumpa@nonet.net> writes > > >The "Try Actel Software / Free Software!" link is STALE... (19/7/97) > > No it isn't. I downloaded the package on sunday 20/7/97, No problems. > >Herbert Kleebauer <klee@mistress.informatik.unibw-muenchen.de> wrote in >article <5qklqc$s9h@thorgal.et.tudelft.nl>... >> Has somebody tested the free actel software? Is it worth to download? >> Is programmer support included? Is the ACTIVATOR needed or is there >> a free design for a simple programming hardware. >> >> If Vielogic would release the old DOS Workview as freeware this maybe >> could be a good system for homberew chips. >> >> ------------------------------------------------------------------------- > -- Kindest Regards, Gerry | We manufacture processor modules gerry@devantech.demon.co.uk | using PIC, 80C31, 80C188EB, 68302 http://www.devantech.demon.co.uk | also assemblers & C compilers.Article: 7016
Hi, We are doing a project with NASA for an airborne measuring system. We will be providing the system cpu board. The engineers at NASA would like us to use programmable logic (I prefer EPLDs) that have an epitaxial layer. They say this provides better resistance to radiation induced lockup. What I want to know is what chips out there have this epitaxial layer. I gather it is not common. Any help is most appreciated. Please email me your ideas as well as posting them. I don't check this group as often as I should. :) Michael J. Kelly tel: (508) 278-9400 fax: (508) 278-9500 web: http://www.cogcomp.comArticle: 7017
>Don't know why.. Normally, when going FPGA -> ASIC, one does a netlist transfer. Since one would not have the netlist for the PCI portion, one would then have to design this from scratch. OTOH if the FPGA vendor offers a hardwire version of the device, that would represent a viable halfway stage. But still much more costly than an ASIC. I have done a few FPGA -> ASIC conversions, and on say 10k+ quantity there is no comparison. One can get straight ASICs (i.e. all digital, single supply rail, no fancy business) done with very low NREs. Peter. Return address is invalid to help stop junk mail. E-mail replies to z80@digiserve.com.Article: 7018
Klaus Falser wrote: > >can anybody recommend me some literature about production testing when >using CPLD's? Suggestions: 1. Contact the relevant CPLD manufacturer (Vantis, Lattice, Altera etc). 2. Contact companies in the automated test equipment game, for example JTAG Technologies are on http://www.jtag.com/ and have some useful free literature (I'm NOT on commission, and have been neither customer nor supplier). >Is it really true, that the design inside the CPLD must not be tested an >can be assumed as working correctly (apart from design errors)? Does it >make sense to have test pins where internal signals can be monitored? 3. No, it certainly isn't true!!! I always ensure I have some sort of test regime. You may not need to bring internal signals out to pins (waste of pins, so normally means you are using a larger package than is appropriate) if the test regime is carefully designed and the design is not too complex (ie internal states can be inferred from external signals). 4. Although it can introduce various complications, including a liability to new failure modes, in-system programmability (isp) of CPLDs ensures that the IC behaviour can't change between programming and being fixed to the board. Also allows a "self-test" configuration to be loaded first and proved OK before "operational" configuration is programmed - this may be a useful approach, depends on what else is on the board. 5. Many (most?) isp CPLDs have JTAG or similar boundary-scan test/validation circuitry. This is not a trivial subject, but can be extremely worthwhile - especially if you want to be able to give your customer a reasonable guarantee of functionality. 6. Remember that PCB layout needs to be tester-friendly. For bed-of-nails testing this often means that all test points must be on a 0.1" grid. 7. A small, low-current LED that is permanently on or flashes happily when system is in good order can be a great confidence boost - even if all it tells you is that the clock is running. Good luck Tim Forcer tmf@ecs.soton.ac.uk Department of Electronics & Computer Science The University of Southampton, UK The University is not responsible for my opinionsArticle: 7019
Hello, I have just read in the Xilinx newsletter that one of the problems with *large* FPGAs is the dynamic dissipation. This is fairly obvious I suppose. The move to 3.3V is offered as the cure, for the time being, but this gives only some 50% drop. I also know, having done a few FPGA -> ASIC conversions where the target had to be low-power, that the bulk of an ASIC's *dynamic* Icc can be avoided by clock gating (i.e. local clocks, rather than a global clock going all over the place, and using clock enables). I saw drops of up to 5x by using heavy clock gating in the FPGA version, and much more (10x-100x easily) in an ASIC. Should Xilinx therefore not provide some local clocking? Years ago, on the XC3064 etc, one could use a Long Line as a local clock net. This was recommended by Xilinx app engineers at the time, as being the next best "proper" thing to using the global clock net. It worked perfectly. I did many designs, which were not only simulated but also actually tested over temperature, without any problems. But this no longer works in the newer devices, when building e.g. long counters or shift registers. In fact it stopped working rather suddenly about 2 years ago, with the new 3064 devices (can't remember more details, since I have not used Xilinx parts much since then). Presumably this is because the speed improvement has improved the clock-Q timing by a larger factor than it has improved the worst-case interconnect delays. This would break any shift-reg sort of circuit. So we are now right back to routing ACLK/GCLK to *every* D-type, and using clock enables, together with what is sometimes silly extra logic to generate the clock-enable at the right time. Lots of milliwatts! Peter. Return address is invalid to help stop junk mail. E-mail replies to z80@digiserve.com.Article: 7020
A.C.Rochat (arjan.rochat@pi.net) wrote: : If you are planning to use version 2.2 or earlier, forget it. : The Foundation package contains software by Xilinx and Aldec. : The Aldec part (VHDL, Schematic capture, simulation) has a very fancy : GUI and fancy functionality, but it simply does not work. : The Aldec software performed so bad that we decided to halt the project : altogether. : Now, a jear later i am planning to take the project up again, if there : is goed software : available and Xilinx is willing to give it to mee free. (Yes _FREE_! : Xilinx owes me one!) : Positive notes: : The software written by Xilinx themselves is OK. : The support from the Xilinx distributor here in Holland is realy : exelent!! This reminds me very much of my own experience with Viewlogic PROseries. The only good part of it was the beta-test version of Speedwave simulator. The synthesis just did not work. Now I know that PRO-/View- synthesis tools are not to be trusted. You are telling me that neither is Aldec. Can anybody recommend something that is good enough and does not cost you your life savings? What about the new VHDL synthesis tool from MINC? George.Article: 7021
Hello fellow newsgroup users, On 16-7-97 I posted a question in this newsgroup about selection criteria for FPGA's and CPLD's. Some of you kindly responded on 16 and 17-7-97 (Philip Freidin, Brian Dipert (twice), L. Kumpa). When I came to see if any answers were there (23/7/97, I'm a busy guy), all these messages were apparantly deleted from the server, that is, I could still see what messages had been posted, but the messages themselves were gone. Why? Peter WeltenArticle: 7022
There is something strange going on here. I see only five postings in the whole week between July 9 and July 16. Where is the killer ? Peter AlfkeArticle: 7023
> why do articles dissapear so fast? >Peter Welten The life of articles in a news group is a function of you news administration at your ISP. There is no central site for all news, it is distributed and duplicated at thousands of sites. (the usenet news group system was invented by disk drive manufacturers). There is an archive of articles for this news group at: http://www.super.org:8000/FPGA/ where you can read my replies over and over again. Philip :-)Article: 7024
Peter Welten wrote about being unable to see responses to his July 16 post "Selection Criteria for CPLD's/FPGA's" Have a word with your service provider (NLnet?). All news servers retire posts after a given duration. The duration will vary between newsgroups and servers. For instance, alt.binaries.* will expire rapidly, but "local interest" (eg nl.* in your case) may be kept for weeks or months. The providers aren't trying to make the net ephemeral, it's just they have to manage a vast number of bytes represented by up to hundreds of posts per day on a quite enormous number of newsgroups. Try to convince your service provider that comp.* groups are responsible, don't get binaries posted to them, and don't contain porn (although we seem to get as much spam porn adverts as most - but that's another problem). They may then increase the hold time. For more info on things like this, look at <news:news.announce.newusers>. Tim Forcer tmf@ecs.soton.ac.uk Department of Electronics & Computer Science The University of Southampton, UK The University is not responsible for my opinions
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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