FPGA Journal Article
in [FPGA]
|
Prev: Xilinx Spartan3E Sample Pack 3rd party programing support now available
Next: porting linux on ml403
From: Antti Lukats on 16 Jan 2006 04:45 "Peter Alfke" <alfke(a)sbcglobal.net> schrieb im Newsbeitrag news:1137368392.011329.301720(a)g47g2000cwa.googlegroups.com... > 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: fpgaarcade on 16 Jan 2006 04:59 Thank you for the kind words Eric. P.S. has everyone read Eric's article about FPGA Gaming in XCELL? http://www.xilinx.com/publications/xcellonline/xcell_54/xc_pdf/xc_atari54.pdf
From: Brian Drummond on 16 Jan 2006 08:27 On 15 Jan 2006 21:39:16 GMT, ptkwt(a)aracnet.com (Phil Tomson) wrote: >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. Last really open system was the XC6200. But it failed commercially, at least in part, because it was a finer grained architecture. FPGA capacities should now be big enough to support a "virtual FPGA" layer on top of a real FPGA, using only the "public" parts of the bitstream (e.g BRAM and SRL16 contents, possibly a subset of the routing) to give a completely open format. Possibly a virtual XC6200, but probably a coarser grained architecture (mini-Spartan perhaps). I wonder what size Spartan-3 you would need for a virtual XC6264? This would lose a lot of capacity and performance (you may need several LUTs dedicated to routing for every one you can use for logic) but the result is likely to be at least competitive with the sort of technology a startup or small player has on offer. I think it would be big enough to exercise open source development tools until something better came along... - Brian
From: Antti Lukats on 16 Jan 2006 08:33 Brian Drummond" <brian_drummond(a)btconnect.com> schrieb im Newsbeitrag news:9p7ns1pch437c81ln9dunkk34bo5p2k3ab(a)4ax.com... > On 15 Jan 2006 21:39:16 GMT, ptkwt(a)aracnet.com (Phil Tomson) wrote: > >>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. > > Last really open system was the XC6200. But it failed commercially, at > least in part, because it was a finer grained architecture. > > FPGA capacities should now be big enough to support a "virtual FPGA" > layer on top of a real FPGA, using only the "public" parts of the > bitstream (e.g BRAM and SRL16 contents, possibly a subset of the > routing) to give a completely open format. Possibly a virtual XC6200, > but probably a coarser grained architecture (mini-Spartan perhaps). > I wonder what size Spartan-3 you would need for a virtual XC6264? > > This would lose a lot of capacity and performance (you may need several > LUTs dedicated to routing for every one you can use for logic) but the > result is likely to be at least competitive with the sort of technology > a startup or small player has on offer. > > I think it would be big enough to exercise open source development tools > until something better came along... > > - Brian > > it has already been done there was MPGA project that implemented a virtual "Meta" FPGA the project is dead vanished/vanishing but its a nice a example of the use of SRL16 for virtual FPGA loading its however far more interessant to implement dynamic bitstream generator that patches some parts of the ready made bitstream to modify the algorithm this needs to no resources to be vasted for the download of the new config. -- Antti Lukats http://www.xilant.com
From: Tobias Weingartner on 16 Jan 2006 13:13
In article <dqflq9$sfp$01$1(a)news.t-online.com>, Antti Lukats wrote: > > 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 :) Hmm... will google show me this? :) > As of BIG FPGA companies making their bitstream format public - do not hope! > > second there are factory test bits and settings, again something that the > end user should not mess up All the better to have documentation, no? > so there are reasons for keeping the bitstream non public. I happen to disagree. We are all entitled to our opinions of course. If the vendors would have a well defined format to "compile" to, and a good library/port for a program to be able to take this format and then generate a bitstream, that would be a start. Note, I'd want to have the source available to be so that I could port this last bit of "technology" to my favourite OS (by choice or necessity). I can't believe that these things are anything but simple portable ANSI C (or some derivative)... -- [100~Plax]sb16i0A2172656B63616820636420726568746F6E61207473754A[dZ1!=b]salax |