FPGA implementation in (V)HDL

[Sebastian Lange]

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...

Sebastian

 

[Philip Freidin]

On 22 Sep 2003 06:26:07 -0700, Sebastian_Lange@gmx.de (Sebastian Lange) wrote:

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...

Sebastian

Eric Crabill's course at SJSU covers this as Lab 5

http://www.engr.sjsu.edu/crabill/





Philip Freidin
Fliptronics

 

[Andras Tantos]

Also take a look at: http://www.opencores.org/projects/fpga/

Regrads,
Andras Tantos

"Philip Freidin" <philip@fliptronics.com> wrote in message
news:ksutmv8keob45q149tk04kb040lu6l8bl5@4ax.com...

On 22 Sep 2003 06:26:07 -0700, Sebastian_Lange@gmx.de (Sebastian Lange)
wrote:
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...

Sebastian

Eric Crabill's course at SJSU covers this as Lab 5

http://www.engr.sjsu.edu/crabill/





Philip Freidin
Fliptronics

 

[jetmarc]

a VHDL or Verilog implementation of an FPGA?

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.

Marc

 

[Brian Drummond]

On 22 Sep 2003 12:15:59 -0700, jetmarc@hotmail.com (jetmarc) wrote:

a VHDL or Verilog implementation of an FPGA?

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.

Marc

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...


- Brian

 

[Neil Franklin]

antti@case2000.com (Antti Lukats) writes:

FYI

MPGA Meta Gate array

pure Xilinx SRL16 oriented design,

1 MPGA cell = 1 Virtex slice

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, ...

bitstream is prepared as ASCII chart that can be directly downloaded!
yes you have ASCII chart you edit it and download to FPGA

Split up into the LUTs, with all the rest of the host-FPGA unchanged?

KRPAN (OC embedded FPGA)

this is very similar to Algotronix CAL1024 with little bit enhanced
1 KRPAN cell is approx 26 Virtex slices

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.

I wonder if your comment is still no comment?
guess it is.
me smiling here

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, neil@franklin.ch.remove http://neil.franklin.ch/
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?