FPGA Journal Article
in [FPGA]
|
Prev: Xilinx Spartan3E Sample Pack 3rd party programing support now available
Next: porting linux on ml403
From: Peter Alfke on 15 Jan 2006 18:39 Jim, beware, you are hitting a hot-button ! Jim Granville wrote: >> Digits of precision & granularity ? 10 decimal digits fixed-point display, but 2 ppm accuracy. Above 1 MHz limited by time base accuracy, below 1 MHz by display (just because we are too lazy to make the display floating point...) > > > A tad outside the average hobbiest resource pool ? I think so. > > > Yes, scopes are dominated by things other than the FPGA, so are not > ideal demo-examples. Yes and no. For low-performance, most complexity would be in FPGA, DRAM, and PC. > > My favourites would be for Xilinx to do a split > a) Freq Ctr & Signal Generator - Smallest/Cheapest FPGA version Wait for the S3Eeval board. It includes a freq.gen design based on my box. Ken Chapman did the control for both of them (PicoBlaze-based), so you can be convinced it is good. But it only goes to 80 MHz (?) and the jitter may be more than 100 ps, since he has no PLL to clean it up further. > > b) Freq Ctr & Signal Generator - Money-no-object version I am going for 2.5 GHz square wave, 1 Hz resolution, and lowest jitter. But no arbitrary function, adjustable amplitude or duty cycle. All those things are possible, but clutter up the design. Maybe there will also come a USB-controlled derivative that offers more freedom. Please tell me what people need a frequency counter for. I have thought of a design for years, including reciprocal counting at low frequency for high resolution with short capture time. But it died for lack of interest. We could of course include something in the S3E eval board. > > FreqCtr's can become quite complex - so a series of designs would show > users more and more, but still have a HW platform that is > i) FPGA dominated > ii) Clearly ahead of any uC alternative The S3E eval board accuracy will be limited by its 50 ppm xtal, and the resolution might be pushed to almost 1 GHz. Display is no problem @ 2 x 16 digits. A 20 times more accurate time base would cost <$20 extra. I warned you, this is a hot button with me. My thesis project, looong ago, was a frequency counter. It's deep in my genes. Peter
From: Jim Granville on 15 Jan 2006 20:59 Peter Alfke wrote: > Jim, beware, you are hitting a hot-button ! > Jim Granville wrote: > >>>Digits of precision & granularity ? > > 10 decimal digits fixed-point display, but 2 ppm accuracy. > Above 1 MHz limited by time base accuracy, below 1 MHz by display > (just because we are too lazy to make the display floating point...) > >>>A tad outside the average hobbiest resource pool ? > > I think so. > >>Yes, scopes are dominated by things other than the FPGA, so are not >>ideal demo-examples. > > Yes and no. For low-performance, most complexity would be in FPGA, > DRAM, and PC. > >>My favourites would be for Xilinx to do a split >>a) Freq Ctr & Signal Generator - Smallest/Cheapest FPGA version > > Wait for the S3Eeval board. It includes a freq.gen design based on my > box. Ken Chapman did the control for both of them (PicoBlaze-based), so > you can be convinced it is good. > But it only goes to 80 MHz (?) and the jitter may be more than 100 ps, > since he has no PLL to clean it up further. > >>b) Freq Ctr & Signal Generator - Money-no-object version > > I am going for 2.5 GHz square wave, 1 Hz resolution, and lowest jitter. > But no arbitrary function, adjustable amplitude or duty cycle. All > those things are possible, but clutter up the design. Maybe there will > also come a USB-controlled derivative that offers more freedom. Those do sound like the Smallest/Cheapest and 'other end' I was talking about. Why stop at 1Hz ? > Please tell me what people need a frequency counter for. I have thought > of a design for years, including reciprocal counting at low frequency > for high resolution with short capture time. But it died for lack of > interest. We could of course include something in the S3E eval board. When I say 'Freq Ctr' that is short hand for the higher end Freq Ctrs. The better ones ( we use a venerable PM6672 here... ) can do much besides simple frequency. I'd start with the simplest gated counter designs, and then work up to Reciprocal and Time-Interval counters, ..maybe Phase too. A small nudge, and you can make a SigmaDelta ADC display section, as that's really a % counter. One idea I have, is for a Dual Readout Recip Counter : A fast update readout, where the precision is the normal trade off of update speed. The second would accumulate precision, so the longer the probe is held there, the more digits you get. That gets a little tricky, as the whole system has to never drop any edges. Uses: As a software development tool, to verify correct settings. Common errors are the off-by-one in divisiors etc. Mostly 2 channel Time-interval, but also frequency. > >>FreqCtr's can become quite complex - so a series of designs would show >>users more and more, but still have a HW platform that is >>i) FPGA dominated >>ii) Clearly ahead of any uC alternative > > The S3E eval board accuracy will be limited by its 50 ppm xtal, and the > resolution might be pushed to almost 1 GHz. Display is no problem @ 2 x > 16 digits. > A 20 times more accurate time base would cost <$20 extra. That's fine. It should NOT be limited by the FPGA. Users would be happy to add timebases as needed - yes, even to atomic ones :) For higher end examples, how about calibrate/correct via GPS timebase (still using the low cost xtal) That expands further, to give an absolute time reference - wider audience, and with 2 lines, one could show 'human' time, and the other the snapshot of the 1 sec time pulse from the GPS, probably to better than 5ns. > I warned you, this is a hot button with me. > My thesis project, looong ago, was a frequency counter. It's deep in my > genes. Talking of looong ago, I think my first film-processed project was a compact 8 digit Freq Ctr, with many old fairchild part numbers. That was before rubylith.... -jg
From: Peter Alfke on 15 Jan 2006 22:05 Jim Granville wrote: > > Why stop at 1Hz ? It is easy to go to mHz, just make the accumulator longer, but why? With 1 ppm absolute accuracy, even the Hz is dubious above 1 MHz. Who is interested in frequencies below 1 MHz? That also goes for the counter. Jim, you seem to overestimate the time and energy we here can expend on sophisticated and increasingly specialized appliations. That's why I stay with a basic, but extreme design that gives us some real usefulness and also some bragging rights. There are always more urgent projects breathing down our necks: Verifying, testing, finding problems and work-arounds, write documentation, plan the next generation, prove SEU hardness, deal with unhappy postings on the newsgroup, give seminars, attend conferences, analyze the features and find the shortcomings of the "other guy", support Markeing, but prevent them from exaggerating... Life is never dull, often challenging, and rarely really frustrating. Peter Alfke
From: Hal Murray on 16 Jan 2006 00:59 >So, I wonder, how many people here are exclusively logic designers, >and how many are more general EEs, who deal with the analog, power, >thermal, and other aspects of electronic design? I've never worked with any "exclusively logic designers". (At least I don't think I have. Maybe one snuck in that I didn't notice.) There is also the other end of the spectrum: firmware/drivers/software. For most projects that I've worked on, that's a cricital part of the big picture. You could also expend up to system architecture and stuff like that. -- 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.
From: Antti Lukats on 16 Jan 2006 03:34
"Phil Tomson" <ptkwt(a)aracnet.com> schrieb im Newsbeitrag news:dqefe401nol(a)enews4.newsguy.com... > In article <slrndsgqr4.i5.weingart(a)irricana.cs.ualberta.ca>, > Tobias Weingartner <weingart(a)cs.ualberta.ca> wrote: >>Kevin Morris wrote: >>> >>> Any takers? >> >>Real/Complete programming information would be a very good start to a new >>hobby phase. But I think that all the FPGA vendors are too scared to give >>out this information. Come on, xilinx, altera, etc, etc. What could >>there >>possibly be so secret in the format for how to program your parts? :) >> > > Indeed. I don't get it either. How much can be reverse engineered from a > bitstream format? This closedness is a real hindrance to the development > of > an open source eco-system around FPGAs. > > Any university open FPGA architectures being developed out there? While > it's > probably too late in the game for a new FPGA company to enter the race, > it's > possible that one of the smaller, hungier players might be able to > differentiate themselves by opening up their bitstream formats. > > Phil Phil, Atmel AT40K/AT94K bitstream format is almost open eg it is available under NDA from Atmel, and open source reverse engineered documentation is also available - no NDA :) As of BIG FPGA companies making their bitstream format public - do not hope! because the bitstream holds not only the 'known' bits like routing and LUT, but also factory stuff bits that compensate against technology changes, those are 'figured out' by actual measurement by the FPGA companies AFTER wafers are manufactured that is the FPGA companies makes their chips to have a little 'fine tuning' to be done, this fixing is done by bitgen and is totally invisible for the normal user. second there are factory test bits and settings, again something that the end user should not mess up there are some hidden FPGA primitives that are partially visible for the end user but not useable by end user, like PMV primitive in V4 and S3 there are probably hidden features and primitives that are totally invisble for the end user as well. so there are reasons for keeping the bitstream non public. for Xilinx and Lattice the main bitstream info is in NeoCad "BFD" files, those are simple ordered lists of bit names, bitgen uses that info to convert an NCD to bitstream NCD file is almost 1:1 the same as the XDL file would be so actually pretty much of the bit info is visible for those who want to see -- Antti Lukats http://www.xilant.com |