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
"Tony Burch" <tony@burched.com.au> wrote in message news:41b829df$0$9113$afc38c87@news.optusnet.com.au... > BurchED, Making FPGA Prototyping Easy, http://www.burched.biz [snip] > (4) User website spotlight for December. > Altium DXP / Nexar design software > http://www.altium.com/dxpcentral/thirdpartyboards/search/ > BurchED boards can be used with the Altium DXP / Nexar design software, by > connecting Altium's Universal JTAG Interface. Have a look at DXP / Nexar - for those who dont have the Altium cable that cable is similar to Xilinx PIII except that additional second JTAG port pins are added. The details how todo your own Altium livedesing compatible cable can be found at www.XESS.com website, there is example design that containts enough info. Sure XESS boards or Amontec Cameleon can be programmed to be Altium cable compatible AnttiArticle: 76701
> that makes it a lot simpler, in very minimal case you possible only need > setAddress and setConfiguration to put the device in "configured" state. > After that you possible can do the special tasks for the gadget as you need > it. Is there a special USB slave device that enumerates and configures hosts?Article: 76702
Hey At Altiums homepage there is a PDF with 3rd party boards, it acutally tells that all 3rd party board can be used, as long as there is a full connected parrellel port on it :) i have a spartan 2 board from coreworks, and i works nicely with protel/nexar, both soft and hardware chain. if anyone have that board i have a 90% finished libery(with softjtag) to protel for that, just drop in a mail.. repzak "Antti Lukats" <antti@case2000.com> skrev i en meddelelse news:cp9agc$480$03$1@news.t-online.com... > "Tony Burch" <tony@burched.com.au> wrote in message > news:41b829df$0$9113$afc38c87@news.optusnet.com.au... >> BurchED, Making FPGA Prototyping Easy, http://www.burched.biz > [snip] >> (4) User website spotlight for December. >> Altium DXP / Nexar design software >> http://www.altium.com/dxpcentral/thirdpartyboards/search/ >> BurchED boards can be used with the Altium DXP / Nexar design software, >> by >> connecting Altium's Universal JTAG Interface. Have a look at DXP / >> Nexar - > > for those who dont have the Altium cable that cable is similar to Xilinx > PIII except that additional second JTAG port pins are added. The details > how > todo your own Altium livedesing compatible cable can be found at > www.XESS.com website, there is example design that containts enough info. > Sure XESS boards or Amontec Cameleon can be programmed to be Altium cable > compatible > > Antti > >Article: 76703
Don't forget ST is a very big company (much bigger than X or A) and have many different areas of expertise. I wouldn't be surprised if they start using their own FPGAs to improve where they already are pretty good. In fact, i believe that FPGAs will ony benefit from this. ST will use them where that have not been used before, thus expanding challenging X and A on new grounds. No doubt X and A will still make, overall, the best FPGAs, but will they still make the best FPGAs for, say, the automotive market? Existing companies don't know much about the automotive market, ST knows more than most. On the other had, if ST fail, it'll probably mean nobody is ever going to try the FPGA market. After all those failures, people will just get fed up of it. Either way, it's gonna be interesting! On 08 Dec 2004 13:10:09 -0800, SG <gupt@hotmail.com.NOSPAM> wrote: > >The key things here is that ST Micro is going after the embedded FPGA >market. This is not an established market and Xilinx & Altera will >have advantages only in terms of tool familiarity. > >About ST's architecture, if the Logic synthesis and P&R tools are open >source, it should be very easy to figure out what the architecture >is. Also, I don't think its a very big innovation, otherwise, ST >would go after the standalone FPGA market, instead of a non-existant >embedded FPGA market. > >My 2 cents. >SumitArticle: 76704
Hal Murray wrote: > > 2. Use a low jitter clock reference for the MGT. No PLL or DLL > > sources. A cheap crystal osc will do just fine. > > Many of the fast delivery oscillator packages now include a PLL > and get programmed at the last minute rather than grinding a special > crystal. > > What sort of jitter is acceptable? Are the PLLs in such an > oscillator good enough if there aren't any other PLLs? Howdy Hal, But there IS another PLL - it's in the RocketIO. If you want to place an analog PLL before the analog RocketIO PLL, you have to know how they are going to act as a pair... and I don't believe there are enough details released on the RocketIO PLL to be able to model that (as if 99% of the people would pull up SPICE to do it anyway). I view the above point about PLL's as different than the jitter issue - I probably should not have grouped it with the DLL/jitter point since it has little to do with the RocketIO itself - it's really an issue of what the response of one PLL trying to follow another PLL is. The RocketIO user guide lists a number for allowable jitter (dependant on bitrate... the lowest is 40ps, the highest is 120ps), but doesn't spec the frequency range over which it applies, which is probaby just as important. Have fun, MarcArticle: 76705
SG <gupt@hotmail.com.NOSPAM> writes: > And at first glance, looks like a true open-source license [...] Are you allowed to fork the code and distribute it to people that are not members of the GOSPL community (i.e., to those who haven't signed the GOSPL Community License)? If you can't, then it isn't Open Source or Free Software. > (publish any changes to source code that you make). The requirement to publish any changes that you make to the code is bogus and reduces the usefulness of the code greatly. Also, you need to apply for a license, and ST seems to be able to deny you one. That is not good, either. (And, the application form is in Microsoft Word .doc format. Way to endear oneself to the Open Source / Free Software crowd.) I will try to get my hand on the license, I haven't found it yet on their web pages. What is missing, in my opinion, is not 1 million lines of code with a half-assed, half-open license. We need complete and unencumbered documentation of the hardware, the way we have it for general purpose CPUs like IA-32, PowerPC, etc. If there is a need for Free Software, it will then appear. Maybe GOSPL provides these docs. I'm fully convinced that there are people out there who are able and willing to write synthesis and P&R tools for sufficiently well documented FPGA hardware, and give these tools away as Free Software. But having to reverse engineer the hardware first is not fun and not worth it, and so it isn't done to a sufficient level. This all is not to say that GOSPL is evil, or doomed, or the wrong strategy for ST. But in my view, it is nothing that the OpenSource / Free Software communities need to get excited about. Yet.Article: 76706
Allan Herriman wrote: > > On Wed, 08 Dec 2004 18:04:31 -0500, rickman <spamgoeshere4@yahoo.com> > wrote: > > I must be a 'no one'. Well, I wouldn't go *that* far.. :) > Rick, we have discussed this before, e.g. in this thread: > http://groups-beta.google.com/group/comp.arch.embedded/browse_frm/thread/7e0ec68b5c53e4 You have a *much* better memory than I do. I think I had looked into this, but my idea was rejected by higher ups in favor of a speciallized chip that actually used the top N bits of the accumulator to drive an ADC. This sine wave was then filtered and fed back to the chip for clipping via a comparator. > This is something I've done in real designs. I've also developed > tools for estimating the output jitter of the NCO, taking the loop > bandwidth (and order) of the PLL into account. > It is possible to achieve very low levels of jitter at the PLL output, > if the frequencies are carefully chosen such that the higher level > spurious signals at the output of the NCO are well outside the PLL > loop bandwidth. I looked at the posts that you refer to. That post has some defunct links for other posts or web pages. Heck, a couple of them are to altavista that doesn't even refer you to whoever bought them. Things change fast on the internet. > >I always figured that the low pass filter would do the smoothing for > >me. > > Exactly. Although this does require the phase detector to be linear > (otherwise the jitter signals will be demodulated). Common phase > detector types (e.g. most digital phase detectors driving charge > pumps) aren't particularly linear due to inexact balance between the > pull-up and pull-down current sources. A figure of 10% is sometimes > quoted. What phase detectors *are* linear? -- 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: 76707
Ben Twijnstra wrote: >>I need an information about some prices for some fpga. >> >> Acex1k speed -1, 208 pins. >> Cyclone speed -6, 240pins. > Check http://www.arrow.com. > > Do realize that you haven't specified the actual size of the device, just > the pin count, family and speed grade. No mention of gate/LE count. That tends to mean all of them ... ReneArticle: 76708
Hi Paul, That's interesting too! I think what you're saying is that some inputs to the LUT are more power thirsty than others. So, in your example, the A input in your example controls more muxes than the B input. This means that you could reduce power by taking this into account. If you had a LUT structure with four inputs A, B, C, D then A would feed 8 muxes, B feeds 4, C feeds 2, and D feeds just one. For any two input function, only two inputs are used and the P & R tools could prefer to use the C and D inputs for the least amount of internal switching of nodes. Also, the net that changes most frequently should be on the D input. Correct? Thanks, Syms. "Paul Leventis (at home)" <paulleventis-news@yahoo.ca> wrote in message news:aLidnZsPU9W2PircRVn-ow@rogers.com... > > Let's take a 2-LUT implementing an XOR as an example (see diagram). We > have > x = A?1:0 and y = A?0:1, and f = B?y:x. Let's say A switches from 0-->1 > (and B = 0). Node x toggles from a 0 to 1. Node y toggles from a 1 to a > 0. > And node f toggles from a 0 to a 1 (with x). So you have not only the > output of the LUT toggling, but also the internal stages. If you extend > the > example to an N-LUT, you'll see that a toggle on input A results in > 2^(N-1) > first stage nodes toggling, 2^(N-2) second stage, etc. or 2^N - 1 nodes > toggling *internal* to the LUT. If you look at an AND instead, you'll see > that only one first stage node toggles state with a change in A. > > A B > +-+ | | > |0|-|\ x | > +++ | |__ | > +-+ | | |\ > |1|-|/ | | > +++ | | |__ f > +-+ | | | > |1|-|\ y| | > +++ | |__|/ > +-+ | | > |0|-|/ > +++Article: 76709
> I m facing some problems with clock gating in Virtex II FPGA > using BUFGMUX, The Xilinx ISE 6.2.03i is saying the design is not > completely routable. I know that clock gating in an FPGA is not > advisable, but my requirement is like that. I have total 15 clocks of 5 > diffterent frequencies. All these 15 clocks are gated with gate enable > before going to the individual modules. The gating must be done in my > clock tree module only. > > Can anyone please give some inputs on this... Any help will > be greatly appreciated. SynplifyPro has an option to automatically convert gated clocks into clock enables. Very useful for ASIC prototyping. Cheers, JonArticle: 76710
On Thu, 09 Dec 2004 10:26:25 -0500, rickman <spamgoeshere4@yahoo.com> wrote: >Allan Herriman wrote: >> >> On Wed, 08 Dec 2004 18:04:31 -0500, rickman <spamgoeshere4@yahoo.com> >> wrote: >> >> I must be a 'no one'. > >Well, I wouldn't go *that* far.. :) > >> Rick, we have discussed this before, e.g. in this thread: >> http://groups-beta.google.com/group/comp.arch.embedded/browse_frm/thread/7e0ec68b5c53e4 > >You have a *much* better memory than I do. I think I had looked into >this, but my idea was rejected by higher ups in favor of a speciallized >chip that actually used the top N bits of the accumulator to drive an >ADC. This sine wave was then filtered and fed back to the chip for >clipping via a comparator. That is a sound way of solving the problem. In addition, it's fairly well understood. It's no surprise that the higher ups liked it. > >> This is something I've done in real designs. I've also developed >> tools for estimating the output jitter of the NCO, taking the loop >> bandwidth (and order) of the PLL into account. >> It is possible to achieve very low levels of jitter at the PLL output, >> if the frequencies are carefully chosen such that the higher level >> spurious signals at the output of the NCO are well outside the PLL >> loop bandwidth. > >I looked at the posts that you refer to. That post has some defunct >links for other posts or web pages. Heck, a couple of them are to >altavista that doesn't even refer you to whoever bought them. Things >change fast on the internet. And now we have groups-beta.google.com. I liked the old interface. Here's the missing link (about phase noise in analog plls): http://groups-beta.google.com/group/sci.electronics.design/browse_frm/thread/9befb6a9959fc07d Aargh! groups-beta.google.com now uses a variable spaced font for ascii art. Bad! Bad! > > >> >I always figured that the low pass filter would do the smoothing for >> >me. >> >> Exactly. Although this does require the phase detector to be linear >> (otherwise the jitter signals will be demodulated). Common phase >> detector types (e.g. most digital phase detectors driving charge >> pumps) aren't particularly linear due to inexact balance between the >> pull-up and pull-down current sources. A figure of 10% is sometimes >> quoted. > >What phase detectors *are* linear? Digital PFDs with charge pump outputs are about as good as it gets. An analog multiplier or a diode ring DBM might be quite linear for small level inputs, but these have the disadvantage of a sinusoidal characteristic (i.e. they're quite non-linear for jitter inputs above about 0.1UI - a post NCO PD will typically see much more than that) and don't come with a built-in frequency detector. Regards, AllanArticle: 76711
rickman wrote: > This has been discussed > many, many times here and I still don't see any open source tools that > are worth using. You probably use a lot of open source tools allready - spice - espresso (which is part of ISE, IIRC) - gcc (which is part of EDK) - tcl (which is part of allmos every EDA tool around that does not use a lisp dialect instead) Kolja SulimmaArticle: 76712
Paul Leventis (at home) wrote: (snip regarding power, XOR trees, and FPGAs) > While logically a LUT is just 16x1 ROM, physically it is not built the same > way as a RAM. > A traditional RAM is built with a 2D-array of bits, where a row is selected > by decoding the address, and a pair of differential bit lines per cell is > precharged and then the cell pulls one side down which is amplified by a > sense-amplifier to speed things up (gross simplification). In that > structure, regardless of what you are reading, you burn the same power since > the reads are differential, and you burn power on each read, regardless of > the previously read value, since all that precharge, pull-down and sensing > happens every read. That sounds more like a DRAM or SDRAM. Traditional SRAMs were completely combinatorial, such that the output changed the appropriate propagation delay after the address changed. Wouldn't the precharging require a clock? I would have thought a 2D array, where a row is decoded, the outputs from the selected row, either differential or not are supplied to a mutliplexer to select the appropriate bits to output. At 16 cells the advantage of 2D decoding might not be worthwhile. > A LUT however is traditionally built as a multiplexor tree. You have 16 > SRAM cells feeding a tree of 2:1 muxes. The 4 inputs of the LUT each > control one level of the tree. There is a diagram below for a 2-LUT. I wonder how 16 bit SRAMs were built? As far as I understand it, the first semiconductor memory for a commercial computer was the storage protection keys for the IBM 360/91, built out if 16 bit SRAM chips. -- glenArticle: 76713
Hi, I have a project that needs a digital implementation of filtering analog signals. Basically, the filter should process two analog signals (amplitude demodulations and some multiplications) to generate one output. The throughput must be higher than 500kHz. I initially looked at DSP, but a colleage of mine directed my attention to FPGA solutions. I have looked at Atera and Xilinx websites and found they offer DSP development boards (dual A/D and dual D/A). I would appreciate very much if any of you can make a recommendation for my application. I am new to FPGA, but fairly familiar with DSP. Basically, I am looking for a prototyping board which is easy to use, has at least two A/D and one D/A, and includes all the necessary software. The total cost I can spend is around 3K. Thank you very much for any help. Best, Daniel.Article: 76714
I'd like to create a sound synthesizer along the lines of a *very* simplified Commodore SID chip. Any tips on how to get started? Thanks. -DaveArticle: 76715
I believe I know the answer to this, but I just want to check around in case I missed something. I have an FPGA design where I'm taking an existing frame grabber board that we make and turning it around to make a CameraLink camera simulator. It works and I can even select the camera clock speed from a set of 8 values I precompiled. However, I find I now want to be able to gradually ramp up the clock speed to see where our receiver boards start failing. My set of 8 frequencies span 85MHz to 16MHz. I would really rather be able to select frequencies from the range of 20-85MHz in 1MHz increments. The duty cycle of the output clock must be no worse then 60/40 for the ChannelLink transmitter chip, which has a PLL to think of. I think I'm SOL and the best I can do is use as many DCM devices as I can, divide the results by 1/2/3/4 and use lots of BUFGMUX devices to select from that set of clocks and divided clocks. In other words, extend what I've already done until I run out of applicable resources. Besides being icky, that doesn't actually get me many clocks, not to mention the limited number of BUFGMUX devices to make a mux tree of clocks. So is there a way that I'm missing for getting a single software- selectable output clock with a nearly 50/50 duty cycle ranging from 20 to 85MHz? On an XC2V3000-4? (For the record, this is an open source design, but using a pre-made board that I cannot otherwise change.) -- Steve Williams "The woods are lovely, dark and deep. steve at icarus.com But I have promises to keep, http://www.icarus.com and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep."Article: 76716
Stephen Williams wrote: (snip) > However, I find I now want to be able to gradually ramp up the > clock speed to see where our receiver boards start failing. My > set of 8 frequencies span 85MHz to 16MHz. I would really rather > be able to select frequencies from the range of 20-85MHz in 1MHz > increments. The duty cycle of the output clock must be no worse > then 60/40 for the ChannelLink transmitter chip, which has a PLL > to think of. > I think I'm SOL and the best I can do is use as many DCM devices > as I can, divide the results by 1/2/3/4 and use lots of BUFGMUX > devices to select from that set of clocks and divided clocks. In > other words, extend what I've already done until I run out of > applicable resources. Besides being icky, that doesn't actually > get me many clocks, not to mention the limited number of BUFGMUX > devices to make a mux tree of clocks. If you start from a higher frequency, and use the divide by 1.5, 2.5, etc. circuits that Peter Alfke has shown in some Xilinx notes, you should be able to get pretty many frequencies in that range. Do the frequencies need to be integer multiples of 1MHz? -- glenArticle: 76717
In article <ljy8g7r1ho.fsf@troy.dt.e-technik.uni-dortmund.de>, Marius Vollmer <marius.vollmer@uni-dortmund.de> wrote: >What is missing, in my opinion, is not 1 million lines of code with a >half-assed, half-open license. We need complete and unencumbered >documentation of the hardware, the way we have it for general purpose >CPUs like IA-32, PowerPC, etc. If there is a need for Free Software, >it will then appear. Maybe GOSPL provides these docs. We had something quite close to that, I _believe_, for the XC4000 series; I believe that's why those were the chips used in the amazing evolution-of-hardware experiments in 1996 or so. But the time taken for free software to be developed for a new architecture is at least comparable to the time for the architecture to become obsolete; and there's not the concept of generations of backwards-compatible chips that the software world is used to, because there isn't the enormous pool of software without source code. The manufacturer reserves the right to change everything under you; it's not even completely clear to me that Verilog developed with the tools around when the XC3000 appeared would compile to correct hardware if you loaded it into ISE7 and targetted an XC4VSX55. So it's not quite clear to me that, if you'd devoted effort to reverse engineering the bitstream format on the XC3000 series, it would be any use at all for Spartan-3; whilst a compiler targetted to 386 remains a moderately useful artefact even on an Opteron, since the Opteron will run the 386 software at a useful speed. [that 'at a useful speed' is to remove the hideous, though amusingly baroque, spectre of using a Free toolkit targetting XC3000, and running the result in an XC3000 implemented on a large Spartan-3] TomArticle: 76718
Kolja Sulimma (news@sulimma.de) wrote: : rickman wrote: : > This has been discussed : > many, many times here and I still don't see any open source tools that : > are worth using. : You probably use a lot of open source tools allready : - spice : - espresso (which is part of ISE, IIRC) : - gcc (which is part of EDK) : - tcl (which is part of allmos every EDA tool around that does not use a : lisp dialect instead) Also... - make (for when you get fed up with the ISE gui or need more flexibility) - python/perl/... (for when you get bored writing glue hdl or logic etc directly) - cvs et. al. - ghdl - linux - many many more Okay some of the above are very general, but some of them form key parts of many peoples toolchains. Wouldn't it be nice if OSS could one day form a usefull part of the toolchains closer to the FPGAs... --- cdsArticle: 76719
In article <1102617329.116082.44050@c13g2000cwb.googlegroups.com>,
Dave <apple2ebeige@yahoo.com> wrote:
>I'd like to create a sound synthesizer along the lines of a *very*
>simplified Commodore SID chip. Any tips on how to get started?
>Thanks.
The VGA interfaces I've seen all have something of the form
--pin1 -- R --|
|
--pin2 -- 2R --+---monitor
|
--pin3 -- 4R --|
so maybe something like that would produce a really, really cheap
DAC for the output stage.
I'd be tempted to build various circuits of the form
[Ramp generator]
* At each tick, add INPUT_1 to my internal 24-bit register
* If my internal register reaches INPUT_2, set it back to zero
* Put the value of (maybe the top 8 bits of) my internal register on
OUTPUT
[Variable-aspect generator]
If the value of INPUT_1 is more than INPUT_2, output 0, otherwise
output 1
[switch]
If the value of INPUT_1 is more than INPUT_2, output INPUT_3,
otherwise output INPUT_4
(do you want a single-bit or a wide version of this? I don't know yet)
and then try to build some sort of switching fabric for connecting
various constants and the outputs of circuits to the inputs of others
in a programmable way - a sort of field-programmable audio-generation
array inside an FPGA.
I think that's flexible enough to do what I remember the sound chip on
the BBC Micro being capable of: you can use a ramp and a network of
switches to provide an envelope, a ramp and a VAG produce a square
wave of arbitrary aspect ratio, a slow ramp driving INPUT_1 of another
ramp produces a wave of constantly rising frequency.
Have fun!
Tom
Article: 76720In article <N7r*F0IBq@news.chiark.greenend.org.uk>, Thomas Womack <twomack@chiark.greenend.org.uk> wrote: >In article <ljy8g7r1ho.fsf@troy.dt.e-technik.uni-dortmund.de>, >Marius Vollmer <marius.vollmer@uni-dortmund.de> wrote: > >>What is missing, in my opinion, is not 1 million lines of code with a >>half-assed, half-open license. We need complete and unencumbered >>documentation of the hardware, the way we have it for general purpose >>CPUs like IA-32, PowerPC, etc. If there is a need for Free Software, >>it will then appear. Maybe GOSPL provides these docs. > >We had something quite close to that, I _believe_, for the XC4000 >series; I believe that's why those were the chips used in the amazing >evolution-of-hardware experiments in 1996 or so. Sorry, I meant XC6216 here. The December 1996 paper describes the device used as a prototype; I'm not sure what became of that range. http://www.cogs.susx.ac.uk/users/adrianth/ices96/node2.html is the paper, worth reading. TomArticle: 76721
I don't know a specific board that meets your requirement, but there is a list of FPGA boards at www.fpga-faq.com/FPGA_Boards.shtml One or more of those boards may meet your requirement. HendraArticle: 76722
I am trying to combine a 4 bit logic function and a 4-1 mux on the result. For example: wire [3:0] a; wire [3:0] b; wire f; wire [1:0] s; wire out; wire [3:0] t; assign t = f ? (a | b) : (a & b); assign out = t[s]; Where a and b are 4 bit inputs, f selects a function on them, and t[s] selects one of the 4 result bits. Looking at the CLB diagram, I was thinking this would fit in 4 LUTs for the logic, followed by a MUXF5 and a MUXF6 for the selection. Somehow, I end up with 6 LUTs and a MUXF5 (using XST 6.2). Now, I've tried using manual instantiations of the MUXF5/MUXF6. This way I end up with the proper muxes, but they are fed by 1-input LUTs, and the logic is calculated somewhere else. Does anybody know a way to convince XST to fit this in 4 LUTs/MUXF5/MUXF6 ?Article: 76723
I posted the jist of this on the Xilinx forums, but thought I might get a quicker response through here... ________________________________ I recently joined a large company, and my first assignment while familiarizing myself with our imaging algorithm entails drawing a very rough floorplan of a design that ultimately will consist 3 modules of code (code will also be designed by two other companies). The PCB will then be re-laid out around the FPGA (definitely a board spin at this point). I have only received projected estimates on resource usage from the two other companies. I could probably convince them to shoot over more info, but I am certain they aren't close to finished with the coding. My team's code should eat approx. 30% of the resources on a Virtex-II XC2V-6000. I can easily obtain the HDL for this section. To be frank, it's been a while since I worked with FPGAs and from toying around with ISE, I feel like I can only manipulate a floorplan after place and route. However, this doesn't make any sense to me b/c I feel floorplanning ideally should be performed during development. Would someone point me in the direction floorplanning w/o code? Any feedback is appreciated. RoyceArticle: 76724
Allan Herriman wrote: > > On Thu, 09 Dec 2004 10:26:25 -0500, rickman <spamgoeshere4@yahoo.com> > wrote: > >You have a *much* better memory than I do. I think I had looked into > >this, but my idea was rejected by higher ups in favor of a speciallized > >chip that actually used the top N bits of the accumulator to drive an > >ADC. This sine wave was then filtered and fed back to the chip for > >clipping via a comparator. > > That is a sound way of solving the problem. In addition, it's fairly > well understood. It's no surprise that the higher ups liked it. On this design I don't have the luxury of enough space for this chip. I can provide a PLL and put the NCO in the FPGA however. > And now we have groups-beta.google.com. I liked the old interface. > > Here's the missing link (about phase noise in analog plls): > http://groups-beta.google.com/group/sci.electronics.design/browse_frm/thread/9befb6a9959fc07d > Aargh! groups-beta.google.com now uses a variable spaced font for > ascii art. Bad! Bad! Thanks for the link. I found the font to be fixed. But some of the drawings did wrap. Maybe the font can be specified in the browser? > Digital PFDs with charge pump outputs are about as good as it gets. PFD means Phase-Frequency-Detector? I believe you said that the digital phase detectors are not very linear. Are you saying that there are *no* good detectors? What if a digital phase detector were connected to analog current sources so that the pullup and pulldown were balanced? Would that be linear enough? I don't think that would be hard to design. -- 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 FAX
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