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
Prashant wrote:
> Now I'm trying to simulate the gate level netlist for the
> design. The simulation takes a long time compared to RTL and I figured
> that was due to a lot of factors including not having the complete
> version for Modelsim.
Even with the full version, gate level is >10x slower.
> Is there a way to load a specific internal signal instead of all of
> them in Modelsim ?
do
add wave -r /*
to see everything.
Search for the signals you want, and copy the names for a script like:
##############
add wave *
# Top level signals
add wave /test_hdlc/ck_bytes/dut/octet_valid
# My buried signal
run -all
#############
> How do people using Modelsim for gate level simulations troubleshoot
> their gate level designs ?
Do static timing first and you may not have to.
The static timer gives much more specific data on problem delays.
Once static timing is working you should see no problems at the
gate level for synchronous designs.
Gate level debug tools include code breakpoints,
wave watching and temporarily inserting print or report statements.
-- Mike Treseler
Article: 46876Actually, Olivier, when I was granted to be a beta tester for Forge a week ago, I thought I had been told that this was for a 1-year period. Turns out that the licence will expire next week... All this talk in vain, I'll have to learn Verilog! I was hoping to parallelize the algorithm as much as possible by coding in Java long lists of if's against constants etc. Frank "Pierre-Olivier Laprise" <plapri@tesserae.McRCIM.McGill.EDU> wrote in message news:hlpf9.23$Go6.1999@charlie.risq.qc.ca... > If your algorithm is that big, perhaps, it isn't suited to FPGA > implementation?Article: 46877
On Tue, 10 Sep 2002 09:53:02 -0700, Peter Alfke <peter@xilinx.com> wrote:
>For the IC manufacturer, 5-V tolerance is an awful requirement, leading to all sorts
>of ugly compromises between chip size (cost), speed, and reliability. And 3.3-V
>tolerance is heading the same way.
I dread the day you can't get state-of-the-art FPGAs with 3.3V-tolerant I/O.
Maybe I should buy stock in companies that sell voltage-translation IC's. >:->
- Larry
Article: 46878Larry, Would you invest in a buggy whip factory because automobiles make obsolete the horse and carriage? It is a delicate balance: we must offer the cutting edge technology, yet be able to look over our shoulder and interface with last year's chips. At some point we lose the backward compatibility convenience (ie 5V) as we slide down Moore's curves. Austin Larry Doolittle wrote: > On Tue, 10 Sep 2002 09:53:02 -0700, Peter Alfke <peter@xilinx.com> wrote: > >For the IC manufacturer, 5-V tolerance is an awful requirement, leading to all sorts > >of ugly compromises between chip size (cost), speed, and reliability. And 3.3-V > >tolerance is heading the same way. > > I dread the day you can't get state-of-the-art FPGAs with 3.3V-tolerant I/O. > Maybe I should buy stock in companies that sell voltage-translation IC's. >:-> > > - LarryArticle: 46879
Hi, It is possible to save simulation results with modelsim, instead of running the simulation again when needed? YanArticle: 46880
>Although it may sound lazy, I can understand the desire to look for an >Orcad part. If you draw your own part, then you run the risk of making >an error in the pinout. .., Can you read a drawing with that many pins connected to a generic part? For FPGAs, I've always worked with schematic parts that were specialized to each application. What you really want is a database from the part vendor that tells you which pins on the package are used for what, and another file for each design that assigns signals to pins. Then you need software that will merge them together and make a constraints file (or whatever) that will tell the placer where to connect things and make another set of files that are part descriptions for your schematic capture package. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 46881
I wrote:
>> I dread the day you can't get state-of-the-art FPGAs with
>> 3.3V-tolerant I/O. Maybe I should buy stock in companies
>> that sell voltage-translation IC's. >:->
To which Austin Lesea replied:
>Would you invest in a buggy whip factory because automobiles make
>obsolete the horse and carriage?
>It is a delicate balance: we must offer the cutting edge technology,
>yet be able to look over our shoulder and interface with last year's
>chips.
Poor analogy. This year's FPGA may obsolete last year's FPGA,
but there are still a tremendous array of chips that the FPGA
is still supposed to interface to. Some of them may well be
"last year's", others simply won't move to 0.11nm technology
for technical or economic reasons. Typical chips in this
category are ADCs, DACs, stepping or servo motor drivers,
and communication PHY layers. Heck, even driving an LED is
problematic below 3V.
>At some point we lose the backward compatibility convenience
>(ie 5V) as we slide down Moore's curves.
Losing 5V tolerance doesn't bother me much, because 3.3V CMOS can
drive traditional 5V chips (because of their 1.8V nominal thresholds),
translating from 5V to 3.3V is a simple matter of two resistors,
and the industry has been using 3.3V for many years. A sudden
shift down from 3.3V would bother me.
- Larry
Article: 46882
On Tue, 10 Sep 2002 19:25:19 +0000 (UTC), Larry Doolittle wrote:
>[chop] there are still a tremendous array of chips that the FPGA
>is still supposed to interface to. Some of them may well be
>"last year's", others simply won't move to 0.11nm technology
^^^^^^
Oops. I guess 3.3V compatibility will be the least of our
concerns in 2025, eh? Of course I meant 0.11um, a.k.a. 110 nm.
- Larry
Article: 46883On Tue, 10 Sep 2002 17:00:05 GMT, Troy Schultz <tschultz@canada.com> wrote: >George Eccles wrote: >> I am considering using an Atmel ATF15xx series CPLD. This would be my >> first PLD of any sort, and I'm a little bit floundering. For >> instance, the part data sheet says that outputs can be configured for >> "open-collector" (open drain?) operation; but, I don't find any >> mention of that in the "Programmer's Reference Guide". >> >> Is there other documentation on these parts? Or, is there a better >> way to learn this stuff? >> >> Thanks, >> George >> >> >> -----= Posted via Newsfeeds.Com, Uncensored Usenet News =----- >> http://www.newsfeeds.com - The #1 Newsgroup Service in the World! >> -----== Over 80,000 Newsgroups - 16 Different Servers! =----- > >Last spring I started out with the Atmel ATF15xxx series, mostly due to >their logic doubling feature. I ran into a large number of problems >with their software. Was that WinCUPL? If so, do you know what rev it is? They're currently at 5.2.16. Thanks, George -----= Posted via Newsfeeds.Com, Uncensored Usenet News =----- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -----== Over 80,000 Newsgroups - 16 Different Servers! =-----Article: 46884
It's all a matter of trade-offs. For highest density, speed, reliability and lowest cost, you will have to sacrifice some backward compatibility, and many users are more than happy to do that. Others will settle for slightly less agressive specs and enjoy the compatibility. As they say, "you cannot have your cake and eat it". (Is this a more appropriate analogy?) If there is a market opportunity, somebody will design and make chips to fill it. (Capitalism 101). Peter Alfke, Xilinx Applications =========================== Larry Doolittle wrote: > I wrote: > >> I dread the day you can't get state-of-the-art FPGAs with > >> 3.3V-tolerant I/O. Maybe I should buy stock in companies > >> that sell voltage-translation IC's. >:-> > > To which Austin Lesea replied: > >Would you invest in a buggy whip factory because automobiles make > >obsolete the horse and carriage? > >It is a delicate balance: we must offer the cutting edge technology, > >yet be able to look over our shoulder and interface with last year's > >chips. > > Poor analogy. This year's FPGA may obsolete last year's FPGA, > but there are still a tremendous array of chips that the FPGA > is still supposed to interface to. Some of them may well be > "last year's", others simply won't move to 0.11nm technology > for technical or economic reasons. Typical chips in this > category are ADCs, DACs, stepping or servo motor drivers, > and communication PHY layers. Heck, even driving an LED is > problematic below 3V. > > >At some point we lose the backward compatibility convenience > >(ie 5V) as we slide down Moore's curves. > > Losing 5V tolerance doesn't bother me much, because 3.3V CMOS can > drive traditional 5V chips (because of their 1.8V nominal thresholds), > translating from 5V to 3.3V is a simple matter of two resistors, > and the industry has been using 3.3V for many years. A sudden > shift down from 3.3V would bother me. > > - LarryArticle: 46885
Peter Alfke wrote: > > rickman wrote: > > > > > I read up on the Mach4384V and it seems it is 5 volt tolerant if you use > > the LVCMOS IO type and don't use more than 64 pins this way. > > > I need TTL > > input/outputs (5 volt compatible) and I need about 90 of them. Any > > solution other than to use two chips? > > The most likely problem area is the "5-V tolerance". The manufacturer does not want > you to apply 5.5 V to the inputs, since this might, in the long run, overstress the > dielectric. > A series resistor is no help, since there is no current... > So ask yourself: Does the "TTL" driver really drive 5.5 V or even 5 V? > Bipolar TTL stays one (or two) diode drop(s) below Vcc, which might be safe, but I > would add a bleeding resistor to ground to be sure.( 10 to 100 kilohm). True CMOS > does drive to the Vcc rail. The problem is not the driving level, but overshoot. There are lots of things I can't control on the bus, so to make a robust board they need to be guarded against. Resistors are not a good solution because they take up too much space on the board. Instead of 90+ resistors I would prefer to use TTL buffer chips. > For the IC manufacturer, 5-V tolerance is an awful requirement, leading to all sorts > of ugly compromises between chip size (cost), speed, and reliability. And 3.3-V > tolerance is heading the same way. > There is a price you pay for all the great capabilities of the newest parts. If it > doesn't fit, use the old-fashiond parts. That is the idea, but I don't call a part that was introduced earlier this year "old-fashioned". I had to beg to get a sample of the XCR3256XL in the 256 FPBGA package just three or four months ago. If I would have wanted them any earlier, I would have had to sleep with someone... :) How can that be an old-fashioned part? > And BTW, idle current (quiescent current) is also going up, since transistors are > not completely cut off at the low supply voltages ( 1.5 V and below). One nanoamp > times hundred million transistors becomes real current :-) Another reason to work with more conventional designs. The bleeding edge stuff has its place, but it takes a long time for the old standards to go away. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 46886
Larry, And soon, 65 nm, and then even smaller..... Of course, someone should comment that the IO ring is (was) .35u for awhile, just to address the backwards compatibility. But as performance demands increase, even there we must consider mainstream foundry processes (like the 0.25u/0.13u low-K all copper for Virtex II Pro from IBM/UMC), rather than consider inventing a process that is not in the "mainstream" of CMOS logic. One can just about ask for anything, but getting the price, performance, and yield that you desire is a lot easier to do if all of the other ASICs, ASSPs use the same process. - Don't think of today. 'Today' is gone far too soon (as you point out: a real cliche but true). Manufacturers can not wait more than 1 year before they go for the shrink, otherwise they leave themselves open to competition. To say "I won't shrink to the next process" is similar to saying "I am going to stop breathing now." Besides, we have Virtex for 5V compatibility, Virtex II for 3.3V, Virtex II Pro for 3.3 V compatibility, and so on. We will provide solutions for those situations where there just has to be backwards compatability. Austin Larry Doolittle wrote: > On Tue, 10 Sep 2002 19:25:19 +0000 (UTC), Larry Doolittle wrote: > >[chop] there are still a tremendous array of chips that the FPGA > >is still supposed to interface to. Some of them may well be > >"last year's", others simply won't move to 0.11nm technology > ^^^^^^ > Oops. I guess 3.3V compatibility will be the least of our > concerns in 2025, eh? Of course I meant 0.11um, a.k.a. 110 nm. > > - LarryArticle: 46887
Larry Doolittle wrote: > To which Austin Lesea replied: > >At some point we lose the backward compatibility convenience > >(ie 5V) as we slide down Moore's curves. > > Losing 5V tolerance doesn't bother me much, because 3.3V CMOS can > drive traditional 5V chips (because of their 1.8V nominal thresholds), > translating from 5V to 3.3V is a simple matter of two resistors, > and the industry has been using 3.3V for many years. A sudden > shift down from 3.3V would bother me. That is ok when you have control over your interfaces, but I don't think you can use simple 3.3 volt logic with a 5 volt TTL bidir bus by using a couple of resistors. If the 3.3 volt chip is not 5 volt tolerant, you are SOL. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 46888
rickman wrote: > That is the idea, but I don't call a part that was introduced earlier > this year "old-fashioned". I had to beg to get a sample of the > XCR3256XL in the 256 FPBGA package just three or four months ago. I remember, I helped you with that :-) > If I > would have wanted them any earlier, I would have had to sleep with > someone... :) Please, not with me... > How can that be an old-fashioned part? It's all relative, and the scales are not the same for different families, technologies, and companies. > > And BTW, idle current (quiescent current) is also going up, > Another reason to work with more conventional designs. The bleeding > edge stuff has its place, but it takes a long time for the old standards > to go away. You bet, and that's why we keep devices in production fo many, many years. I think you can still by some XC3000-family parts ( introduced 1987). We do not force anybody to jump on the newest bandwagon... Peter AlfkeArticle: 46889
Austin Lesea wrote: > > Larry, > > And soon, 65 nm, and then even smaller..... > > Of course, someone should comment that the IO ring is (was) .35u for > awhile, just to address the backwards compatibility. But as performance > demands increase, even there we must consider mainstream foundry > processes (like the 0.25u/0.13u low-K all copper for Virtex II Pro from > IBM/UMC), rather than consider inventing a process that is not in the > "mainstream" of CMOS logic. > > One can just about ask for anything, but getting the price, performance, > and yield that you desire is a lot easier to do if all of the other > ASICs, ASSPs use the same process. <snip> Just for an 'other industry' reality check on this, take a look at http://www.goalasic.com/productguide.html They are able to offer 100V and 300V pins, on what I believe is 0.35u core process. - jgArticle: 46890
On Tue, 10 Sep 2002 16:34:52 -0400, rickman <spamgoeshere4@yahoo.com> wrote:
>Larry Doolittle wrote:
>>
>> Losing 5V tolerance doesn't bother me much, because 3.3V CMOS can
>> drive traditional 5V chips (because of their 1.8V nominal thresholds),
>> translating from 5V to 3.3V is a simple matter of two resistors, [chop]
>
>That is ok when you have control over your interfaces, but I don't think
>you can use simple 3.3 volt logic with a 5 volt TTL bidir bus by using a
>couple of resistors. If the 3.3 volt chip is not 5 volt tolerant, you
>are SOL.
True. I haven't had to interface to a TTL bidir signal recently.
Either direction by itself is OK, if you know what you are doing
at PC board layout time.
So, who makes an (~8)-channel, fast bi-directional level converter,
between 1.5-2.5V and 3.3-5.0V, with a convenient flow-through pin-out,
in an SOIC/TSSOP, that costs much less than a mid-range (e.g., XC2S300E)
FPGA?
- Larry
Article: 46891I have a design that uses Xilinx 18v00 PROMs (18V01 and 18V04) to boot some FPGAs. I would like to be able to field-update them thru their JTAG port but would rather not embed Xilinx's eisp software in my system. Does anyone have any info on the programming algorithm for these or similar PROMs? I already can handle sending and receiving TAP commands and data. Thanks. /mike n1ist@arrl.netArticle: 46892
Frank Andreas de Groot wrote: > > You are right but my problem is twofold, first I don't know VHDL, I bought a > book about digital design and VHDL and it's pretty straightforward, but the > main thing is, my "algorithm" is huge in hardware, I couldn't easily make > that within a year... If I would specify it in C, it would be several nested > loops with lots of pattern recognition and very complex decisions. No way I > will ever get that to work in VHDL. And I need to tweak it all the time, > radically change it maybe, and I can start all over again in VHDL... > We are talking about a newbie here, trying to put some major artificial > intelligence into a FPGA... > > My idea was to code in C/Java, get a slow but working FPGA fast to play > with, slowly learn VHDL at the same time, and replace more and more of my > C/Java by handcoded VHDL. Comparable to coding a quick prototype, a proof of > concept in Visual Basic, and then refining routine by routine, after which > you hand-optimize it in assembly... Sounds like you would be better to try and code in parallel as much as possible, and work with a view to deploy it to multiple processors. If the code is not stable, then FPGA migration is unlikely to be usefull. Focus on tight inner functions, coded in ASM, and then move those critcal functions to FPGA hardware. ( very like a custom floating point unit, or any co-processor ) Keep the outer SW shell in C, and run that in C on a 'FPGA processor', which can be soft or hard cored, DSP or RISC. > In 1 week I'll get the board and I'm very anxious to get started... > I'll sure try to code some Verilog or VHDL myself. I *need* the end result > to be as fast as possible. It might even be that there is no gain at all > when using a high-level procedural language converter... I also noted this announcement, which could have relevence to this. Seems this silicon support would assist parallel design, as will the tools that this will spawn. # The Intel president also confirmed the long-expected 3.06-GHz Pentium 4 # in the fourth quarter that will also be the first desktop processor to # use the firm's HyperThreading technology. This allows a single # processor to appear as dual processors, and has been used in # Intel servers since February to achieve a 30% performance # gain over uniprocessor chips. - jgArticle: 46893
"Cool Morning ..." <Far@East.Design> writes: > I am looking for an FPGA chip which has a built-in DAC. My intend > it to build a portable with three chips only, A compact-flash, an FPGA > containing the MP3 decoder > > What's the SIMPLEST approach possible to make a portable MP3 player > in today's technology? With ->ANY<- FPGA you can implement an Sigma-Delta DAC in the FPGAs normal logic gates. So I doubt you will find an FPGA with hardwired DAC circuits. Specific for Virtex: http://www.xilinx.com/xapp/xapp154.pdf They there show an minimal FPGA+R+C circuit. For audio you will need an second R parallel to the C (acts with first R as voltage divider 3.3->0.12V) and possibly an second C after the R-C connection point (to get rid of DC component, depends on your amplifier chip). -- Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/ Hacker, Unix Guru, El Eng HTL/BSc, Programmer, Archer, Roleplayer - Make your code truely free: put it into the public domainArticle: 46894
Neil Franklin wrote: > > "Cool Morning ..." <Far@East.Design> writes: > > > I am looking for an FPGA chip which has a built-in DAC. My intend > > it to build a portable with three chips only, A compact-flash, an FPGA > > containing the MP3 decoder > > > > What's the SIMPLEST approach possible to make a portable MP3 player > > in today's technology? > > With ->ANY<- FPGA you can implement an Sigma-Delta DAC in the FPGAs > normal logic gates. So I doubt you will find an FPGA with hardwired > DAC circuits. > > Specific for Virtex: http://www.xilinx.com/xapp/xapp154.pdf > > They there show an minimal FPGA+R+C circuit. For audio you will need > an second R parallel to the C (acts with first R as voltage divider > 3.3->0.12V) and possibly an second C after the R-C connection point > (to get rid of DC component, depends on your amplifier chip). You would also benefit from feeding the pulse stream through a TinyLogic gate, with special clean supply rails. The GND and VCC noise on a FPGA is unlikely to give a viable audio noise floor. Any Vcc/Gnd noise is fed straight thru the RC integrator, and this is internal (noisier) vcc.gnd, not the pins. -jgArticle: 46895
Larry Doolittle wrote: > <snip> > So, who makes an (~8)-channel, fast bi-directional level converter, > between 1.5-2.5V and 3.3-5.0V, with a convenient flow-through pin-out, > in an SOIC/TSSOP, that costs much less than a mid-range (e.g., XC2S300E) > FPGA? > On-Semi and Fairchild come close, with ~ $1 for 16 bit cross-voltage buffers/latches, in TSSOP48 packages. 1.5-3.3, or 2.5 - 5 are OK, 1.5 - 5 is a bigger ask, due to threshold shifts - you could always cascade two ;) -jgArticle: 46896
Rickman continues.......... > >> oops, affiliation and all that stuff - >> >> Michael Thomas >> LSC SFAE >> for the latest info on Lattice products - http://www.latticesemi.com > >Mike, > >I read up on the Mach4384V and it seems it is 5 volt tolerant if you use >the LVCMOS IO type and don't use more than 64 pins this way. I need TTL >input/outputs (5 volt compatible) and I need about 90 of them. Any >solution other than to use two chips? > >I am also finding rather high list pricing. What is a reasonable >expectation for pricing on the LC4256V-10F256BC and LC4384V-10F256C? I >can ask the distis, but I usually get list price unless I do a real song >and dance and I just need a realistic budgetary number. > >-- > >Rick "rickman" Collin man, I missed the thread for 2 days, you guys have gone crazy! Rick, I did reply tonight via email to get you in touch with a local resource - I agree, disty pricing never seems to bear much relation to what you finally get quoted, after some fancy dancing. I looked at pricing and see about a 30% difference in the 1k price between the LC4256V-75F256BC and the LC4384V-75F256C the 4256 offers 160 I/O the 4384 offers 192 I/O I probably won't get beat up to say both prices are below $32 - my email gives you your local FAE contact, who can also help with the technology side. We don't offer commercial speed as slow as 10ns in either device - both are available industrial at 10ns tho :) (geez, now 10ns is too slow?) TTL I/O isn't quite the same as 5.5v rail to rail, (our max rating) as Peter A. pointed out. Let us look into it with you. Michael Thomas LSC SFAEArticle: 46897
Hi I am interfacing a xilinx virtex with DSP over a tristatable bus. InPAR simulation the data bus goes to the final value after propagating over few X for small time(10 ns). There is no bus conflict also. The sample code is as follows if enable bus<=mem(conv_int(address_input)); else bus Z what could be the source of problem and will it cause problem in h/w.Article: 46898
"Hal Murray" <hmurray@suespammers.org> wrote in message news:unr0sa79g80m4f@corp.supernews.com... (snip of diagram impossible to read on a proportionally spaced font) > > What are you trying to do? > > I don't see any point in testing this circuit. That is I > think we understand things well enough to predict the > answer. > > I'd much rather have Peter collecting data at low voltage and > high temperatures or working on other types of chips. Sure, > if he runs out of other things to try, checking this would > be good. > > > This is potentially interesting if CLK is running slowly. > Peter's numbers show that you need ~2000 pS, and that assumes > tight routing. If your clock is twice that and you know it's a > 50-50 duty cycle, then the above circuit is safe and it saves > a half cycle. > > I would normally put the bubble on the first FF. This way > you only get a 1/2 cycle for Qo to get to the rest > of the logic and that might be a long path. (But the tools > should be able to check that.) > > > In general, being tricky around metastability is asking > for troubles. It's much safer to have a clean circuit > that is easy to check by eye. If you try to be tricky, > you might forget things like the 50-50 clock requirement, > or somebody who takes over your design might miss it... > This reminds me of the 8086, 8087, 8088 which use a 33% duty cycle clock. I wonder which tricks they used. Note that the 80287 also uses a 33% duty cycle clock, asynchronous to the 80286's 50% clock. -- glenArticle: 46899
On 11 Sep 2002 00:21:39 +0200, Neil Franklin <neil@franklin.ch.remove> wrote: >"Cool Morning ..." <Far@East.Design> writes: > >> I am looking for an FPGA chip which has a built-in DAC. My intend >> it to build a portable with three chips only, A compact-flash, an FPGA >> containing the MP3 decoder >> >> What's the SIMPLEST approach possible to make a portable MP3 player >> in today's technology? > >With ->ANY<- FPGA you can implement an Sigma-Delta DAC in the FPGAs >normal logic gates. So I doubt you will find an FPGA with hardwired >DAC circuits. > >Specific for Virtex: http://www.xilinx.com/xapp/xapp154.pdf > >They there show an minimal FPGA+R+C circuit. For audio you will need >an second R parallel to the C (acts with first R as voltage divider >3.3->0.12V) and possibly an second C after the R-C connection point >(to get rid of DC component, depends on your amplifier chip). For audio you need a different DAC (despite what the app note says). XAPP154 describes a first order delta sigma modulator. Audio usually uses at least a second order modulator. Regards, Allan.
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