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
"Michael A. Terrell" <mike.terrell@earthlink.net> wrote in message news:44FF8FE2.C059168A@earthlink.net... > Too bad he didn't get hit by a truck when he was leaving. ;-) One very mean trick is to praise the prick everywhere you go and wait for him to make a jump after the head-hunters get to him. Then the new boss finds out what a POS he is and fires himArticle: 108301
David Ashley wrote: > >>>a 8 bit "=" needs at maximum 7 AND2 and 7 INV not 15 XOR2. And of course > > > > > > This threw me for a bit, then I realized you're comparing > > 8 bits with a constant value, not two 8 bit registers. > > Actually wouldn't you need 7 AND2 and 8 INV if you're comparing to 0? > > -Dave > > > -- > David Ashley http://www.xdr.com/dash > Embedded linux, device drivers, system architecture If you are comparing your 8-bit count value to a constant, it can be handled in two levels of logic. Remember, you don't use up an input when you are comparing with a constant, the constant becomes part of the truth table, so you use all four inputs for the counter input. This is why it is preferable to (pre)load an up/down counter, and compare against a constant to reload/stop generate a terminal count signal. There are times when you have to compare the counter with a register, but they are fairly rare in my experience. Typically, you can avoid the vast majority of these cases with careful design.Article: 108302
On Thu, 07 Sep 2006 21:34:54 +0200, jean-francois hasson <jfhasson@club-internet.fr> wrote: >I work on a board with an Altera 7128S part (5V quite old but still used >...). It seems the part is most of the time working just fine but >depending on when it is powered on it overheats a lot and does not seem >to be well configured : an input acts as an output, and the component is >not working fine at all. Does anyone havea clue as to what could be >going wrong ? It does not happen all the time. This sounds suspiciously like latch-up caused by a power sequencing problem; typically, +5V or some other power rail applied to a device's input before the device itself has been powered-up. This can easily happen if you have voltage level-shifters on the CPLD's input, taking an external 12V or 24V signal and dropping it to 5V for the device. It can also happen if you have multiple interconnected PCBs with separate power to each. The problem can often be solved by adding current limiting resistors in series with each susceptible input. Keep the worst-case input current below about 1mA and you should be safe. These resistors will restrict the input bandwidth, but otherwise should cause no trouble. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 108303
jean-francois hasson wrote: > Hi, > > I work on a board with an Altera 7128S part (5V quite old but still used > ...). It seems the part is most of the time working just fine but > depending on when it is powered on it overheats a lot and does not seem > to be well configured : an input acts as an output, and the component is > not working fine at all. Does anyone havea clue as to what could be > going wrong ? It does not happen all the time. > > Thanks, > > JF Does this part have JTAG, and if so does it have the TRST pin? I had a lot of trouble with an Actel ProAsic device and the JTAG boundry scan. I finally had to tie the TRST pin low to keep it out of the boundry scan mode. Also check that your rise time on your VCC is within limits for the part.Article: 108304
jean-francois hasson wrote: > Hi, > > I work on a board with an Altera 7128S part (5V quite old but still used > ...). It seems the part is most of the time working just fine but > depending on when it is powered on it overheats a lot and does not seem > to be well configured : an input acts as an output, and the component is > not working fine at all. Does anyone havea clue as to what could be > going wrong ? It does not happen all the time. > > Thanks, > > JF Does this part have JTAG, and if so does it have the TRST pin? I had a lot of trouble with an Actel ProAsic device and the JTAG boundry scan. I finally had to tie the TRST pin low to keep it out of the boundry scan mode. Also check that your rise time on your VCC is within limits for the part.Article: 108305
zohair wrote: > How do we apply a constrain to the Xilinx PAR tool to let it know that two clocks in the design are synchronous, and so the clock tree needs to be built with that in mind? Normally you can use FROM :TO style of timing constraints to inform the tools of the required time from active edge of one clock to another. If you have signals crossing the clock boundaries in both directions you would need two FROM : TO timing specs. If in addition you use more than one edge of the clocks you may need more specs. example: NET "x1_clock" TNM_NET = "x1_clock"; NET "x2_clock" TNM_NET = "x2_clock"; TIMESPEC "TS_1x_2x" = FROM "x1_clock" TO "x2_clock" 1.75 ns; TIMESPEC "TS_2x_1x" = FROM "x2_clock" TO "x1_clock" 2.75 ns; That being said, if the clocks are generated on chip, for example using DCM's, the tools will automatically generate the required timing specs based on the PERIOD time spec of the source clock. HTH, GaborArticle: 108306
zohair wrote: > How do we apply a constrain to the Xilinx PAR tool to let it know that two clocks in the design are synchronous, and so the clock tree needs to be built with that in mind? What do you mean by synchronous? Typically, this means you derived one clock from the other, or both clocks from a master oscillator. Unfortunately, you still can't consider the resulting clocks "synchronous" anymore. They may be frequency locked, but you can't guarantee phase lock without careful design analysis. You can generally clean up the situation with careful use of DCM's, but even then, use care when crossing boundaries. I have seen a lot of designs fail due to improper treatment of clocks. As a result, I treat every boundary crossing as asynchronous, and tweak the crossing logic based on the measured phase relationship between the clocks.Article: 108307
Jonathan Bromley wrote: > Seems to me that your second idea would involve each device > having a complete DDR access controller in it. That sounds > like quite a bad idea to me; if you're going to make good use > of SDRAM you need to keep track of the RAM's internal state > to some extent (which banks are active, current row address, > that sort of thing) and it would be very difficult for all four > accessors to keep that kind of internal state in step. > > Of course, passing each client's requests to the RAM > controller is sure to cost some latency if you use a common > controller. If you have a custom controller (rather than a > standard single-port controller on a common bus) then you > can hide most of that latency in the arbitration delay, at the > expense of some extra complexity. > > It's an interesting question, though. I need to deal with > something quite similar in the immediate future, so any > other ideas would be gratefully received! Oh, and does > anyone have any strong opinions (positive or negative) > about any of the available open-source DDR controllers? No matter what happens, 4 separate widgets need to gain access to memory. If they have to interface to some other controller anyway, what's the advantage? Why not make the DDR itself the controller? For example wishbone, the idea behind replacing DDR's own interface with a wishbone in-between would be based on assertions that 1) DDR is overly complex, wishbone's simpler 2) IP core reuse -- wishbone is more standard I *need* to be able to burst large blocks of memory to the DDR. If I use a wishbone interface, then there needs to be some mechanism to translate a burst from one clock domain (the wishbone's) to the DDR's clock domain. That might involve some sort of fifo...and sounds complicated to me. On the other hand the DDR controller is actually not that complicated. Using DDR itself would allow known, easy burst accesses, and memory bandwidth can be maximized. Regarding the DDR's internal state, I'm planning on all widgets doing burst accesses, and each access would only be to a single row. If each widget just precharged the row upon exit, the overhead would be minimal, yet bandwidth would still be good. Finally, if a refresh cycle needs to be imposed, that can be done with a 5th widget that just does a refresh cycle, or it could be a function of the arbitrator itself. -Dave -- David Ashley http://www.xdr.com/dash Embedded linux, device drivers, system architectureArticle: 108308
Hi everyone, A few months ago, I have started working in a small group which designs FPGAs for video application. By the nature of this application, there is a collection of building blocks that are repeatedly being used in our designs. Currently, the knowledge about cores available and how to use them is kept by each designer, so if I need a core from someone I have to ask him to send it to me by e-mail. Certainly, this model is very problematic causing the same cores to be designed again and again by different engineers. I would like to suggest my managers a better way to share this valuable data between the engineers, and I'm looking for a solution that will provide: * Integration with a source control system (sadly, SourceSafe is being used in my company, so I'm binded to that awful tool) * A catalog of available cores * An easy way to add new cores and to update existing ones * A structured way to minimally document the core (functionality, interface) * Integration with design tools (Quartus, HDL Designer, Synplify...) I would appreciate if anyone can give me an idea if such tools exist on the market, or to let me know how such task is being handled in other companies. Thanks, AvishayArticle: 108309
Antti wrote: > Peter Alfke schrieb: > > > jacko wrote: > > >> > > > pin compatability is just customer support, how about a 1 pin high > > > implies a self program from a small hardwired rom, which gets enough of > > > the chip off the ground, to work as a programmer for itself and others. > > > > > > > > We have had that since the beginning, 20 years ago. > > It is called "Master Mode Configuration" > > > > Peter Alfke, Xilinx > > no - I think this is more like one of my past "idea for xilinx" > > FPGA has built in hardware loader for __small__ rom. this rom contains > the logic to implement the actual loader, be it compact flash or nand > or > whatever. easily doable. just make a small part of the FPGA to become > alive first. allowing the rest of the FPGA to be configured from the > 'bootstrap ipcore'. > > nobody is doing it - but without that, the RAM nased FPGA configuration > solutions are still kinda PITA. > > sure as Xilinx is now bringing back the parallel flash solutions from > XC2K > into S3E and Virtex-5 it becomes better, but the bootstrap idea would > still be the kicker! > > Antti This is way off-topic, but I would like to expand on Antti's comment. I'm planning on using my S3E sample pack board in this way. The FPGA will be configured from the end of memory, while the software for the embedded processor runs from the beginning of memory. The supplied FLASH memory can easily handle both the configuration and the program. The nice part of this configuration is that I don't need to waste resources on a an internal BRAM based ROM in my design, and can use all the BRAM's for RAM. It would be nice, however; if the ability to boot from a NOR flash could be expanded to NAND flash. Since many applications already include a large NAND flash memory, this would allow you to use higher density memories, while still dumping the separate configuration memory. I realize that normal NAND flash is a bit more complex to access, but there are now several vendors that supply NAND flash memories that automatically make the first page readable in a pseudo-microprocessor mode, and for the same reason - to allow a processor to bootstrap from flash without a separate BIOS ROM. Even if there was a requirement to use a NAND flash that auto-accessed the first page, it would be a nice improvement.Article: 108310
David Ashley <dash@nowhere.net.dont.email.me> wrote: >Hi, > >I have about 4 different independent things that each need to access >a ddr. > >On one hand it seems I can make them all wishbone >compliant then just have a wishbone ddr interface. > >Would be workable/advisable to instead just have each device >control the ddr itself, and use the ddr's own interface directly? I have created something similar. I created a fifo in a block ram which is used to source or sink data to or from the ddr memory from and to multiple devices at different speeds. In my application I need to write or read large bursts of data so I created a fifo which can work only one direction at a time. I use interleaved fixed burst sizes of 8 (16 bits per DQ line in one transaction) so the overhead is minimal. You might want to look into some sort of caching scheme anyway because accessing ddr to read or write just one address is dead slow. >I'd only need one complicated mechanism to initialize the ddr >after reset, but from then on each of the user processes can just >request access to the ddr, and when granted just take over >the lines. I created a hook into the ddr statemachine which allows me to execute any type of 'instruction' on the ddr memory from a microcontroller. This reduces initialisation to a software thing. Don't forget about refresh. >One concern is that ddr timing at 100 mhz is pretty tight. Having >the logic to combine 4 different sources into control signals for >the ddr might add too much overhead. Of course it can be You can run the DDR controller at 50MHz (half the ddr memory clock) which relaxes the timing for the address and control signals a lot (also good for meeting EMC limits because the drive strength can be reduced and the signals carry lower frequencies). The only line that actually needs tight timing is CS. Fortunately, this is the least loaded line in large multi-chip memory setups. The data lines are a different story. Using a clock with a fixed delay (in my case 90 degrees is just fine) to capture the data gives more than enough margin. As you can read, I didn't use the MIG tool (doesn't work for a Spartan3/200). -- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 108311
"radarman" <jshamlet@gmail.com> wrote: >zohair wrote: >> How do we apply a constrain to the Xilinx PAR tool to let it know that two clocks in the design are synchronous, and so the clock tree needs to be built with that in mind? > >What do you mean by synchronous? Typically, this means you derived one >clock from the other, or both clocks from a master oscillator. > >Unfortunately, you still can't consider the resulting clocks >"synchronous" anymore. They may be frequency locked, but you can't >guarantee phase lock without careful design analysis. You can generally >clean up the situation with careful use of DCM's, but even then, use >care when crossing boundaries. > >I have seen a lot of designs fail due to improper treatment of clocks. >As a result, I treat every boundary crossing as asynchronous, and tweak >the crossing logic based on the measured phase relationship between the >clocks. You can also specify an amount of clock jitter which translates into a clock uncertaintity which the router will take into account. It does tighten the timing budget. -- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 108312
radarman, You are quite right. The term 'synchronous' means "of the same time" or in the same phase. 'Syntonous' means "of the same tone" or the same frequency. So, to be precise, even to say something is 'synchronous' is often misleading, especially if the two signals being compared go through different circuits/parts/paths. You must know the jitter, wander, and possible maximum offset. And then you must subtract the worst case error from the clock period constraint if you expect to be able to use either clock domain to register data. There are even more fun clock terms, like isochronous, pleisiochronous, and so on.... Austin radarman wrote: > zohair wrote: >> How do we apply a constrain to the Xilinx PAR tool to let it know that two clocks in the design are synchronous, and so the clock tree needs to be built with that in mind? > > What do you mean by synchronous? Typically, this means you derived one > clock from the other, or both clocks from a master oscillator. > > Unfortunately, you still can't consider the resulting clocks > "synchronous" anymore. They may be frequency locked, but you can't > guarantee phase lock without careful design analysis. You can generally > clean up the situation with careful use of DCM's, but even then, use > care when crossing boundaries. > > I have seen a lot of designs fail due to improper treatment of clocks. > As a result, I treat every boundary crossing as asynchronous, and tweak > the crossing logic based on the measured phase relationship between the > clocks. >Article: 108313
avishay wrote:
> I would appreciate if anyone can give me an idea if such tools exist on
> the market, or to let me know how such task is being handled in other
> companies.
Step one is quality source control.
I'd start by finding a pc and setting up
a subversion server. Sounds like you use windows,
so maybe this would work:
http://svn1clicksetup.tigris.org/files/documents/3106/33794/Svn1ClickSetup-1.3.3.exe
Then I'd check in my own stuff and show anyone interested
how to do the same. If it works, and the designers like it,
I doubt that the boss will mind, because it's also free.
...except for a few months of your "spare" time, of course :)
-- Mike Treseler
Article: 108314The following long article at the www.fpga-faq.org site should help you better understand these issues: http://www.fpga-faq.org/FAQ_Pages/0017_Tell_me_about_metastables.htm On 7 Sep 2006 08:48:50 -0700, "himassk" <himassk@gmail.com> wrote: >Hi, > >Kindly clarify the following doubts on Two FF synchronizer. >Most of the material available in net says the two flip-flop >synchronizer is sufficient to remove all likely metastability. That is correct, with the qualifier that the path delay between the two flip flops should be minimized, thus maximizing the slack time, and the clock frequency should be minimized, thus maximizing the slack time. >The first flip-flop samples the asynchronous input signal and waits >for a full clock cycle to permit any metastability output signal to >come to stable either 1 or 0. This is not correct. There is no "waiting". This is a statistical process. >How can the ouput of the first FF will becomes stable before the >next clock cycle? On what factors it will depend? See the above mentioned article. >(Theoritically it not guarenteed that Two FF synchronizer avoids >metastability but proctically it is, how?) The practical result is that if there is sufficient slack time between the 2 FFs, the probability of the metastable getting through both is very small. >Whats vendors approach for the first FF to go to stable state before >next sampling edge arrives? High loop gain/bandwidth. >Whats information/insructions the vendor can provide designers >regarding first FF settling time etc....? Metastable characteristics data, and test results to back it up. The parameters can be used in the MTBF calculations to decide if a 2, 3 or more stage synchronizer is needed. >What are all the options available in the designer hand to make the >two ff synchronizer work properly? Maximize slack time, use highest performance FFs available, read the above article. >Please make me clear. Humans are inherently opaque. Making you clear would probably kill you. >Thanks in advance. Good luck! >Regards, >SruthiTeja. Philip Freidin Metastability Understanding crusader =================== Philip Freidin philip.freidin@fpga-faq.org Host for WWW.FPGA-FAQ.ORGArticle: 108315
Homer J Simpson wrote: > "Charlie Edmondson" <edmondson@ieee.org> wrote in message > news:44ff2839$1@news.cadence.com... > >> Had a similiar situation when I worked on the 91 Express lanes toll road. >> My boss was a real A-hole, who would do things like, pull out a knife and >> shave his arms, commenting on how sharp it was, while asking for the >> status of your assignments. The threat was very thinly veiled... > > That's when you pull out a mini butane torch and comment on how hot it is. I would have pulled out my pocket knife and trimmed my sideburns, then offered to trim his. Jerry -- Engineering is the art of making what you want from things you can get. ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻArticle: 108316
I have one more question. If I have two state machines with following signals gating their states P <= '1' WHEN ( B='1' ) ELSE '0'; P1 <='1' WHEN P='1' AND D > "00000000000000000" ELSE '0'; both these two signals are needed Now when I pass signal P1 to the state machine then do I have to pass it via a flip flop ? the signals B and D are assigned in another state machine and both the state machines are running at same clock. Thanks, -D dhruvakshad@gmail.com wrote: > Thank you very much for the tip. I realised my mistake. It works fine > now. > -DArticle: 108317
c d saunter wrote: > Peter Alfke (alfke@sbcglobal.net) wrote: > > <snip> > : Higher performance requires radical innovation and real cleverness > : these days. > : Peter Alfke > > Such as this? > > http://www.tip.csiro.au/ISEC2003/talks/OWe2.pdf > > JPL and Northrop Grumman built a 5k gate 8 bit CPU running at 20GHz by > using superconducitng logic on a chip, it needs helium cycle cryogenics to > hit 4.5k, but on the other hand it doesn't generate much heat being > superconducting... > > I'd have thought gate arrays would make an excelent tool for > investigating the technology... > > cds Hi cds, JPL and Northrop Grumman project is amasing. But you showed the slide made in 2002. 4 years have passed, what is the latest advance? Do they reach their goal? or don't get enough financial support and the project was aborted? WengArticle: 108318
himassk wrote: > Hi, > > Kindly clarify the following doubts on Two FF synchronizer. > Most of the material available in net says the two flip-flop > synchronizer is sufficient to remove all likely metastability. > > The first flip-flop samples the asynchronous input signal and waits > for a full clock cycle to permit any metastability output signal to > come to stable either 1 or 0. > > How can the ouput of the first FF will becomes stable before the > next clock cycle? On what factors it will depend? > (Theoritically it not guarenteed that Two FF synchronizer avoids > metastability but proctically it is, how?) > > Whats vendors approach for the first FF to go to stable state before > next sampling edge arrives? > Whats information/insructions the vendor can provide designers > regarding first FF settling time etc....? > > What are all the options available in the designer hand to make the > two ff synchronizer work properly? > > Please make me clear. You have received some good answers to your questions, but partly because I think you could still benefit from a simple explanation and partly because I feel like listening to myself talk, I will give you a third explanation of metastability and how to avoid its consequences. Metastability is a state of a FF or other similar device (such as a pencil standing on the pointed end) that has two stable states and if released at any point in between will eventually assume one of those two states. The trick is that depending on how close to the threshold point the pencil or FF is released, it can take an arbitrarily long time to end up in one of the stable states. For a pencil, holding it at a given position and releasing it is like the active edge of the clock occuring too close to a transition of the data input. If the FF samples the data input while it is changing, the intermediate logic gates may also be in transition and the feedback of the FF can be in the middle of the voltage range. If the logic values were all at stable values the output would change at a time that is a known delay from the clock edge. But since the internal logic values are not valid, the delay will not depend on the path delays, but rather on how fast the invalid logic values are pushed one way or the other to a stable state. Just like the pencil, this depends on how close to the threshold the invalid value is. This is when statistics take over. If you assume the delta from the logic value to the threshold is not deterministic, but rather random (as will usually be the case) then the time delay will also be random reaching out to infinity. The curve is such that there is a higher probability at shorter delays and an ever decreasing probability at longer delays. Since the area under the curve has to integrate to unity, you can see that the probability must go down very quickly since it stretches forever. So the upshot is that the current logic found in FPGAs is designed to maximize the probability of short delays. This means if you allow 2 or 3 ns of excess setup time between FFs (slack time), the probability of the first FF output still being metastable is so low, that you will never see it in your lifetime if you watch a billion FPGAs. I have not supported this with any hard data, but the FPGA vendors have done that for us. I believe Peter Alfke has made numerous measurements of the metastability coefficients for their products and the 2 or 3 ns is the short version of his data. Someone please correct me if I am wrong about the numbers. But please remember that it is the slack time, not the clock cycle time that allows metastability to be resolved. You can put logic in the path as long as you have sufficient slack time. Conversely, a clock cycle may not be long enough if the routing delay is too long reducing the slack time. It does not hurt to add a specific timing constraint to these paths.Article: 108319
Hi David, David Ashley wrote: > I have about 4 different independent things that each need to access > a ddr. > > On one hand it seems I can make them all wishbone > compliant then just have a wishbone ddr interface. Some off-the-shelf options that spring to mind: Firstly there's the opb_mch_ddr interface core that comes with Xilinx EDK - in addition to the OPB bus interface (which you can ignore), it has 4 independent channels that support a fairly simple simple cacheline fetch protocol (Xilinx CacheLink). In reality it's just their FSL port, with a specific access protocol. It's intended for interfacing MicroBlaze CPUs to memory, but no reason you couldn't use it for something else. Current versions of the core are fixed priority on the 4 ports, but I believe that round robin and other priority schemes are in the roadmap (if you read the VHDL sources anyway). Xilinx also has a MPMC (multiport memory controller) that was developed for the gigabit serial reference design (GSRD), also worth a look. I think you need to register to download this design. MPMC uses something called LocalLink, again just a sort of cacheline read/write protocol, nothing too tricky I don't think, and there should be full source examples of how to drive it in the reference design. Ultimately you have to arbitrate somewhere, be that on a bus, in the memory controller, or at the DDR pin/signal stage. But as others have suggested, that may be more trouble than its worth. Regards, JohnArticle: 108320
Hi guys, I'm trying to measure power consumption of my system on ML 310 board. I was wondering if any one of you have done this. I checked the board data sheet but I couldn't find any pin on the board from which I can get the current on Vccint which goes to the chip and thus measuring the power of the chip. Do you know if there is any pin for measuring the power of the chip or do you know any other way (other than simulation) for measuring power consumption of the chip on ML 310? Thanks in advance, AmirArticle: 108321
I don't want to spam, but I noticed someone referenced this book as a "must-have" on the comp.arch group I work for the publisher that is printing a new edition in September and would love to garner exposure for it in this forum. I don't want to appear as though I am spamming though so let me know if it is okay to provide more details. I can also provide an offer code that will give members of this board a 20% discount and free shipping. Amazon does not sell this book at a discounted price. Thanks all, TaraArticle: 108322
Hi David, i had a similar problem where 3 different clocked users, needed to access a SDRAM Interface wich run by a clock of 166 MHz. The main problem was that every user needed full page bursts in/out of the RAM. So every one of the users got its own dc-Fifo. A single arbitration unit took care that all users got access at the right time. As SDRAM Controller I used the OpenCore from Altera. This Design runs very well in Cyclone and Cyclone II devices. Hope that helps. Regards ChristianArticle: 108323
Hello all, We are trying to design a small microblaze design in a spartan 3 and the problem we have is that the microblaze does not always start when the bitsream is downloaded with JTAG. But when we implement the debug module it always works. Does anyone has a clue ? Is it timing problems ? Is there specific timing constraints to add for microblaze ? Software problem ( linker script is automatically generated by edk)? Any idea is welcome. Thank you. Stéphane.Article: 108324
On 2006-09-06, phaeton <blahbleh666@hotmail.com> wrote: > Hi can someone please explain to me how to post to usenet? you've cleared the first hurdle, read all of this page: <http://groups.google.com/support/bin/answer.py?answer=12348> Bye. Jasen
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