This post may seem a bit awkward, but has anyone ever come across a VHDL or Verilog implementation of an FPGA? It would be very instructional to have a look at it. IMHO, it should be at any rate possible to implement a small FPGA as a bit file sitting on top of another FPGA. Our group is currently working on some ideas for minimizing the reconfiguration data in dynamically reconfigurable FPGA applications. It would be very kind if anyone could point me to any resources... Thank you so much in advance...
I know that somebody started one about 2 years ago, but I can't find the bookmark anymore. The main problem was that the custom FPGA needs a custom toolchain, and that makes it a really huge project.
The logical thing to do would be to combine this with the previous thread, implement a XC6216 on top of a Virtex-II, use the XC6200 tools that still exist, and satisfy those folks who can no longer get the XC6200 for research purposes...
this is something, I mean if someone (like you) doesnt hold it back to say 'no comments' it means something, need to figure out what :)
FYI
MPGA Meta Gate array
pure Xilinx SRL16 oriented design,
1 MPGA cell = 1 Virtex slice bitstream is prepared as ASCII chart that can be directly downloaded! yes you have ASCII chart you edit it and download to FPGA
KRPAN (OC embedded FPGA)
this is very similar to Algotronix CAL1024 with little bit enhanced interconnect and cell architecture
1 KRPAN cell is approx 26 Virtex slices
KRPAN comes with verilog to bitstream tool that does map place and route (simulated annealing), it also has some Floorplanner, software is written
100% in Java and does work.
both the cell sized indicated for fpga-fpga include bitstream programmin interface.
snipped-for-privacy@openchip.org
I wonder if your comment is still no comment? guess it is. me smiling here :)
It just meant that I had read Neil's wide-ranging posting and found it meaningless to answer, because that would just lead to further outbursts. The subjects he brought up have been discussed in this newsgroup ad nauseam... Peter
Web page of openchip.org is still empty, so I can only speculate what you are doing. Hmm, only 2 LUTs per cell can only be roughly such an design:
N-E-W-S inputs (no far ones) into one 4LUT, function there, out direct and out via FF both to an 2nd 4LUT (what with its other 2 inputs?) and output of that identical in all 4 directions (no space for Nout Eout Sout Wout muxes, hmm, how do signals cross each other?).
That would be an minimal SoG-FPGA in LUT+PIP FPGA implementation.
SoG = Sea of Gates, FPGA with no specific LUT logic vs PIP routing split, like Algotronix CAL1024 or Xilinx XC6200 or Atmel AT6000.
LUT+PIP = the oposite, few luts (10% of chip) and 90% PIP based routing in between, like XC2000, XC3000, XC3100, XV4000, XC5200, Virtex, ...
Split up into the LUTs, with all the rest of the host-FPGA unchanged?
That is what most FPGA-in-FPGA designs seem to be like. Emulate CAL1024 or Cal2/XC6200 style designs.
In particular an XC6200 bit compatible design will waste a lot of space (them 3 8-Muxes (each 4 LUTs, 2 F5, 1 F6) per cell are expensive, add then 4 4-Muxes for output (each 2 LUTs with F5), add then a few LUTs for the function unit, and then somehow enough FFs for them 24 config bits per cell). So 26 slices is large but believeable.
An XC6200 feature-alike (translate XC6200 bitstream to lut values and write them per SLR16) would be smaller (only 2 LUTs per 8-Mux, as selection bits come from the LUTs content) and allow additional features (8-Mux -> 2 LUTs and F5-OR, so offer 16+16 functions instead of just 8 Mux states).
Making an optimize for implement-in-Virtex SoG would be massively more space saving, but not compatible (or even translatable) with the XC6200 toolschains. But one can make ones own tools, possibly derived from the many outside-Xilinx ones that are available from universities.
Problem is that I dislike SoG style FPGAs. Their "no routing" architecture, which is sold as advantage by the proponents (it is more "elegant", because less details), ends up in real designs being "emulate routing using logic or out muxes", which uses more chip space (wasted cells just for routing) and is slower (even in full-custom chips it is
1 NAND-NAND Mux per cell, instead of one PIP transistors gate per CLB.
And the 24bit/cell of an XC6200 compared with the 864bit/CLB of Virtex gives us 36cells at cost of one CLB (assuming SRAM costs dominate). So 9cells at cost of LUT. But an 6x6 grid of cells gives max 6 lines of data traversing it and costs 6 NAND-NAND hops, and so is way inferior to an CLB with 24 lines traversing it and one single PIP stage of delay.
Also SoG loses the "1 bit per LUT row" data path design, making hardwired efficient carry chains impossible. So the result is massively slower arithmetic (3 Muxes for bit generating cell (each NAND-NAND) + 2 transfer Muxes per bit, as opposed to the 1 NAND-NAND
2bit lookahead per 2bits, if I reconstruct the Virtex chips layout properly). So that is (3+2*1)*2=10 vs (1/2)*2=1 in propagation delay.
Perhaps he knows that SoG has no future. XC6200 did not die because someone at Xilinx disliked its name. It was an commercial faillure. IMHO because it is/was an SoG. An design which ist technologically inferior. And can not be made better.
Only academia liked it, because its one advantage (bitstream documented), inherited from CAL1032, outweighted performance for their types of jobs (research and test students).
But anyone who wants performance, needs an LUT+PIP design, with its space/speed optimal routing by PIPs and 1-LUT-per-bit data paths with fast dedicated carry. At least DSP and soft-CPU people need this, badly.
That is IMHO why all the large vendors (X, A, Lucent/Lattice) are all LUT+PIP based. And that is why people like me and Casselmann keep on hammering on Xilinx to open up Virtex or V2 documentation.
Only alternative is to either reverse engineer Xilinx, make own FPGAs with documanted bitstream, at least on base of an ASIC to get speed (no FPGA-in-FPGA double speed/density loss). Both cost a lot of time.
Of course any successfull OpenFPGA (outside of academia) is therefore going to also have an LUT+PIP structure. All projects I have seen so far do not have it, because they are SoG.
-- Neil Franklin, snipped-for-privacy@franklin.ch.remove
formatting link
Hacker, Unix Guru, El Eng HTL/BSc, Programmer, Archer, Blacksmith
- hardware runs the world, software controls the hardware code generates the software, have you coded today?
Prof. Steve Wilton's group at the University of British Columbia is doing work on a Programmable Sytem-on-a-Chip. They generate HDL for an arbitrary sized FPGA core, and implement it in Standard Cells on a ASIC. The tool also spits out a compiler for the core (p & r + bitstream generator). They published a paper at CICC on it, and have some other publications.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.