FPGA Journal Article
in [FPGA]
|
Prev: Xilinx Spartan3E Sample Pack 3rd party programing support now available
Next: porting linux on ml403
From: Brian Drummond on 18 Jan 2006 20:39 On 18 Jan 2006 05:19:22 GMT, ptkwt(a)aracnet.com (Phil Tomson) wrote: >In article <9p7ns1pch437c81ln9dunkk34bo5p2k3ab(a)4ax.com>, >Brian Drummond <brian(a)shapes.demon.co.uk> wrote: >>On 15 Jan 2006 21:39:16 GMT, ptkwt(a)aracnet.com (Phil Tomson) wrote: >>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 >>I think it would be big enough to exercise open source development tools >>until something better came along... >> > >Interesting idea. Are you saying that a XC6200 model would be developed in >HDL and then run through synt, p&r, etc. and that could then be used for >downloading the bitstream to? Something like that; though I doubt the XC6200 would be the best starting point. >...but like you say, you would be taking a big performance/area hit. > >If you were going to do that, then why not just create some sort of >higher level Virtual FGPA device (kind of like what a Virtual Machine is to the >software world) that would have lots of nice high-level features (high-level >macros available, etc.) and also be tunable for the underlying architecture >(depending on whether the target was Xilinx, Altera, or Lattice. It looks possible, especially if the basic elements were a common-denominator subset of individual targets like Xilinx; e.g. 4-input LUTs followed by registers, with some sort of carry chain. >Also, just like the Java VM doesn't care what >underlying architecture it's running on, this sort of thing could potentially >make it easier to port designs between FPGA families... But no easier than behavioural VHDL code, in my opinion. >I wonder if it could be >done such that there is a minimal impact on performance and area? ummm, in a sense; if you are willing to use the "native" routing on each target, and allow each company's "native" tools to perform the routing, placement, bitstream generation (because they know the details of that target and its bitstream). And even then, you will lose some performance on at least some targets. But that is a completely different issue than trying to keep every level of the design "open"... IMO the closest you will get to allowing open tools to participate WITHOUT taking a big performance hit is the XDL approach. It's a text version of the NCD format - parseable and even human readable - with converters to/from NCD format. So you could potentially take an EDIF netlist and create open source tools to "map" it to an unplaced XDL, or use the Xilinx mapper and convert its output to XDL. Then create open source tools to floorplan, place and route in XDL format. Those portions of the tool flow are where the challenges are; and if you create something worthwhile, it would be useful to many Xilinx users. You would realistically then have to use Xilinx tools to convert XDL to NCD and translate the completed design into a bitstream format. This is pretty much a straight translation and not very interesting in my book; though it would be a wart on an otherwise complete open source toolchain. - Brian
From: Peter Alfke on 18 Jan 2006 23:12 Tobias, we love universities and their students and faculty for their uninhibited free thinking, unburdened by mundane practicality. But beware that some of your sentences sound not just enthusiastic and uninhibited, but also ill informed. Life would be easy if the world were a simple as you see it. Of course we have evaluated non-volatile storage on an FPGA, and we offer a decryption engine in every Virtex-4 device that we ship. With battery-backed-up SRAM key storage, because we know that Flash storage offers no security worth talking about. And several smart people at Xilinx (and surely also in Altera) are still thinking very hard about a technically and economically viable solution. We gladly take advice. But it has to be more substantial than what you seem to offer. Peter Alfke
From: Phil Tomson on 19 Jan 2006 01:45 In article <p1rts1ldm6fh1safm8an5hincq0tv5vfcm(a)4ax.com>, Brian Drummond <brian(a)shapes.demon.co.uk> wrote: >On 18 Jan 2006 05:19:22 GMT, ptkwt(a)aracnet.com (Phil Tomson) wrote: > >>In article <9p7ns1pch437c81ln9dunkk34bo5p2k3ab(a)4ax.com>, >>Brian Drummond <brian(a)shapes.demon.co.uk> wrote: >>>On 15 Jan 2006 21:39:16 GMT, ptkwt(a)aracnet.com (Phil Tomson) wrote: > >>>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 >>>I think it would be big enough to exercise open source development tools >>>until something better came along... >>> >> >>Interesting idea. Are you saying that a XC6200 model would be developed in >>HDL and then run through synt, p&r, etc. and that could then be used for >>downloading the bitstream to? > >Something like that; though I doubt the XC6200 would be the best >starting point. > >>...but like you say, you would be taking a big performance/area hit. >> >>If you were going to do that, then why not just create some sort of >>higher level Virtual FGPA device (kind of like what a Virtual Machine is to the >>software world) that would have lots of nice high-level features (high-level >>macros available, etc.) and also be tunable for the underlying architecture >>(depending on whether the target was Xilinx, Altera, or Lattice. > >It looks possible, especially if the basic elements were a >common-denominator subset of individual targets like Xilinx; e.g. >4-input LUTs followed by registers, with some sort of carry chain. > >>Also, just like the Java VM doesn't care what >>underlying architecture it's running on, this sort of thing could potentially >>make it easier to port designs between FPGA families... > >But no easier than behavioural VHDL code, in my opinion. True. The only gains might come when describing memories and other larger blocks which tend to be different from family to family... but there are other easier ways of 'genericisizing' those things too. > >>I wonder if it could be >>done such that there is a minimal impact on performance and area? > >ummm, in a sense; if you are willing to use the "native" routing on each >target, and allow each company's "native" tools to perform the routing, >placement, bitstream generation (because they know the details of that >target and its bitstream). And even then, you will lose some performance >on at least some targets. > >But that is a completely different issue than trying to keep every level >of the design "open"... > > >IMO the closest you will get to allowing open tools to participate >WITHOUT taking a big performance hit is the XDL approach. It's a text >version of the NCD format - parseable and even human readable - with >converters to/from NCD format. So you could potentially take an EDIF >netlist and create open source tools to "map" it to an unplaced XDL, or >use the Xilinx mapper and convert its output to XDL. Then create open >source tools to floorplan, place and route in XDL format. Those portions >of the tool flow are where the challenges are; and if you create >something worthwhile, it would be useful to many Xilinx users. > Is XDL described anywhere? Grammar or BNF? Or is it based on XML? (probably not likely, but one can wish) >You would realistically then have to use Xilinx tools to convert XDL to >NCD and translate the completed design into a bitstream format. This is >pretty much a straight translation and not very interesting in my book; >though it would be a wart on an otherwise complete open source >toolchain. Well, you have to start somewhere. Phil
From: fpga_toys on 19 Jan 2006 09:11 Piotr Wyderski wrote: > Now the SMD components in TQFP/SO/TSSOP are no longer a > problem. But we still don't know how to solder BGAs and QFNs... I showed my homebrew club how to reball and attach Xilinx BG560's here in my wifes digital convection oven well over a year ago. It takes a small amount of practice, which gets manageable when you also are willing to bake and reball. There are lots of trash FPGA's to be had on boards for a few dollars, and Solderquik preforms make reballing easy. KISS projects can frequently be pulled off with double sided boards, which are cheap from a number of sources. If doing BGA, they need to be solder mask over bare copper (SMOBC) to prevent the balls from wicking under the mask. There should not be ANY expensive home project from a parts perspective, as recycling motherboards, industrial boards, disk drives, graphics cards, etc are a wealth of nearly zero cost parts. Design with what you can salvage, and that is a lot. I strongly suggest forming a home brew club locally, or even across the net, and pooling designs onto a PCB panel ... especially when 4, 6, and 8 layer projects are needed. Most of the budget pcb shops refused panelled designs, but you can lower your individual costs by sharing NRE's and setup charges across 3-10 project boards on the same panel. Just be sure that you can cut them apart :) > Hmm, really? ;-) As far as I know the only "pure" hobbyists > here are Antti and myself, the rest is more or less professional. I'm pretty sure there are a LOT more than just a few of us. I made PCB's in high school (1967) with masking tape for resist, and stoped making them at home when the pcb program showed up for my MacIntosh 128 from Douglas Electronics. I even stopped wirewrapping about that time because it was just quicker and easier to turn one PCB with data paths and most control paths in place, and finish the design with point to point wiring and PAL's. My first BIG hobby project was a Z80 based 9-track tape formatter for the TMS100 tape drive I had on my LSI11/23 Unix home computer, which I had to go buy a TRS-80 to write the firmware for. My current home computer project is a couple thousand FPGA home super computer, which I've been working toward for a couple years now, mostly because I like big fast computers, it's one hell of a challenge, and I needed retraining in building state of the art computer systems after being a Unix systems programmer for too many years. I do knock off flat fee contract hardware and software designs from time to time, and I'm also currently looking for projects. I will also be turning some of the smaller spare fpga's from my home computer project into low cost student boards - using environmentally friendly recycled parts. John
From: fpga_toys on 19 Jan 2006 09:40
Piotr Wyderski wrote: > But they do not provide free simulators, so they are virtually useless for > hobbyists. I should probably add that Steve's Icarus Verilog (IV) solves that problem in the low cost open source tools department. And it works well targeting fairly good sized XC4K's and Spartan chips which are easy to design with since they only require a 3.3V supply. Pick off an older Seagate drive, and you will have a dual 1a linear regulator, 2MB SDRAM, EEPROM with boot sector, cap's, and a few other parts to build an interesting robot controller, stomp box effects processor, home controller, or other project with a 5V recycled wall wart. And FpgaC for open source reconfigurable computing (read executing C code as circuits) is getting off the ground to do the same for C coders not interested in learning VHDL/Verilog as their only way to program fpgas. You will find both FpgaC and IV on sourceforge. |