FPGA for dummies

[Thorham]

And this is NOT emulation, it is done in real silicon, thanks to the FPGA chip!

It is an emulation in the purest sense of the word because it's not done in silicon but simply by using instructions that are of a lower level than machine language instructions. An FPGA is just a programmable chip just like a CPU, it only serves a different purpose than a CPU.

[Thorham]

If I want a flipflop, that flipflop is a silicon flipflop, not a software or firmware running on some kind of processor to pretend to be a flipflop.

Of course, because that flipflop is a low level entity similar to a machine code instruction. The opcode is simply of a higher level than a flipflop.

I've done silicon layout of FPGA chips

Which is similar to a CPU program, only on a lower level than machine code.

The principle is the same:

With a CPU you describe your functions using high level instructions which are executed serially, while with an FPGA you describe your functions by telling the FPGA how it's gates have to be wired up, which operate in parallel, because you're describing an electronic component.

No hardwiring=emulation.

[Thorham]

You don't know what a flipflop is, do you? Certainly not how a flipflop compares to an opcode. (it doesn't)

When you look at a flipflop as some unit of functionality then it does compare. The difference is the way in which they are used.

An instruction is a collection of circuits that the CPU uses when it fetches an opcode that tells it to use those specific circuits, while in an FPGA things like flipflops and logic gates (and what not) are connected together through user definable wiring.

Uhm, WHAT?! You're saying that silicon layout is similar to writing a computer program?

No, not literally of course. In essence the process is similar, because in both cases you're telling a machine what to do (with an FPGA this is done by telling it 'how to be wired up', so to speak, unless I'm missing something).

Not programmable, all hardwired. It's the same task, the same polygons, as drawing an FPGA.

And in an FPGA it's of course not hardwired, otherwise you'd have to open the FPGA and add and remove tiny little wires.

There's no lower level than machine code running in that transistor telling things what to do

The point is that the transistor IS the lower level. Basically the components in the FPGA that you wire up together are the lower level parts I'm talking about.

An opcode is higher level because it's made of lower level components such as transistors. The lower level of a transistor would then be the components it is made of, and obviously these aren't instructions, but 'bits (NOT computer bits) of silicon and other stuff'.

Those electrons actually are flowing mack and forth, they're not falsely pretending to just because you say so.

Flowing through connections that are, in an FPGA, user definable. There aren't any fixed connections that are user defined (would require the chip to be opened up), and therefore there's no hardwiring.

The programming of a CPU and an FPGA, while done in completely different ways, is both a form of programming. The difference is that a CPU fetches instructions from memory that tell the CPU which parts of it's circuitry to use, while with an FPGA you instead describe those circuits (lower level again).

The whole point is that the function the chips are performing isn't fixed, but user definable, in a CPU it's just done indirectly, because you can't change the circuitry, while with an FPGA you can.

An FPGA emulates a circuit, because while the components are fixed, it's wiring is not, and therefore the circuit isn't fixed. It imitates a circuit's function by providing user definable wiring. Wires are part of a circuit, and these aren't fixed here.

[Thorham]

Just because FPGAs use lookup tables similar to SRAMs instead of fuses or some reprogrammable incarnation of the same thing, doesn't mean it's an emulation of that circuit.

This is fundamental switching theory; the FPGA uses lookup tables for combinatorial logic and logic for interconnects, MUXes etc. These lookup tables are similar to SRAMs, and this is why FPGA contents is volatile.

And there we have it: Lookup tables. This means there's no physical chip, which means it's an emulation (imitation). Or perhaps it's about the meaning of the word 'emulation' being interpreted in different ways.

[Thorham]

So for something to be 'real' and not emulated, it must be hardwired in a permanent form onto a silicon chip? If that's the criteria we're to use, then what does that make the original Amiga 1000? After all, the ROM for the A1000 had to be soft-loaded from floppy disk - it didn't exist in a permanent chip form!

No, not in this case, because it doesn't matter in what kind of memory a program is stored, as long as the CPU can fetch the instructions from it.

Does it make a difference that, for the duration of being powered on and after writing the bitstream into the FPGA configuration memories, that the wiring and everything IS fixed until you power it off?

Yes, it matters, because it can still be changed in a highly flexible manner each time you turn it on. It's all about the changeability.

Crack open my FPGA chip and put the die under a microscope. I'll point to the lookup tables. I'll point to the die. I challenge you to prove that neither is where I'm pointing to. An empty package wouldn't make a very good component for your [insert final product PCB here]...

Sure, but you can't point to any wiring, because it doesn't exist (except for the parts that make the FPGA work as an FPGA).

I think you're right there. It seems my definition of "implementation" and your definition of "emulation" are stepping on each other.

That sounds about right.

By your definition most of the routing on the internet is done through emulation; or does one think Xilinx makes >$1k FPGAs for the hobbyists around here ?

Why not? Does it matter? Only the problem of sending information around has to be solved, and as long as it's done in a convenient way that's also efficient, then it just doesn't matter.

Given that most of these designs will never be put in an ASIC what are they then actually emulating ?

Devices that don't exist completely physically.

Most of PCB designs are often done first with some parts done in programmable hardware and then later when it is really succesful a cost reduced version is made with the programmable part replaced with an ASIC. This means that an ASIC is emulation.

Yes, it does. Until the circuit is physically built using wires, like in CPUs, it can be said to be an imitation of that actual circuit.

From what I've read in th thread, I've also noticed how the gate building blocks in an FPGA use more transistors than you'd actually need in a full, non-Asic, hard implementation, or am I wrong here? If I'm not, then that would mean that if you actually implemented a circuit the hard way, you'd end up using fewer transistors than then the FPGA equivalent. Sounds like an imitation to me.

[Thorham]

Sure I can. There's a LOT of wires in there which are not part of the FPGA configuration controls.

Yes, but these wires are electronically connected and not directly, that's really what I meant, my bad.

When not configured, they are floating, not connected to anything.

Exactly. In a fixed circuit the wires go directly from one component to the next.

There aren't any ghosts lurking around in these things... Do you think that the LUTS talk to each other by telepathy or something? They need wires, very very real-life wires.

Ha ha, of course there's no magic involved (if only , but the connections still aren't hard, like in a CPU.

[Thorham]

How do you feel about breadboards, a pile of 74* logic chips, and a bag of wire?

Not the same. A bag of wires isn't the same as a lookup table, but enables you to build the actual circuit completely physically.

In essence, the lookup tables could be said to tell the FPGA the connection points for the wires (so to speak). The FPGA then electronically connects the wires to those points (so to speak). With a breadboard the connection is completely mechanical, and that makes the big difference.

[Thorham]

I guess part of the debate here is "what does al that stuff actually do" in the FPGA when the design is running, and does or does not that define emulation.

Exactly. In an emulation there's all kinds of things happening in the background to just to enable to make what is being emulated work. The real thing doesn't require any of this overhead at all.

It's like a software emulation: An emulated computer needs a computer and software, while the actual computer works fine by itself.

[Thorham]

The LUT does not do that. The Configuration memories tell the muxes which connections to make. The LUT stores/implements your logic truth table , and has no knowledge of or influence on the wire connections or control of anything.

Sorry for being an obvious layman here. It should still be true that you store data in the FPGA that configures the wiring, though?

The point is that you don't have, say, two transistors which are directly, mechanically connected (such as using a printed circuit board that's custom made, which the components are soldered onto). In an FPGA you have configurable components in between the wires (or am I missing something again?).

[Thorham]

OK, how about this. All those wires do actually connect multiplexers and/or passgates together. wire to transistor to wire to transistor and so on.

Sure, but don't those components connect the wires electronically? In a hard implementation of the same circuit, you'd leave those extra components out.

Now, consider the memory controller in an 8640 PPC processor, which is "fixed" enough for you, and I imagine that the memory chips are too. There are two memory channels. There are several banks (DIMM slots) per channel. When the processor wants to access a particular memory location, there are multiplexers to choose which channel it talks to, and passgates in the RAM chips to make sure only the correct one talks back on the bus. Passgates and multiplexers...

Here those same components aren't extra components that you can leave out, because they are part of the circuit design. If you'd do such a design in an FPGA, you'd end  up using more of said components then are needed by the actual circuit itself.

[Thorham]

Hmmm. What do you think is "happening" in the background of an FPGA design? Once it's configured, all that is fixed. Configuration 1's stay 1's, and configuration 0's stay 0's.

Don't have a clue, but the fact that there is a background in the first place is what matters. For a circuit in an FPGA to work, extra components are needed, and whether they are as active as a software emulation or not isn't important.

In an ASIC, does it make a difference if I use a library cell carrying the name D flipflop which serves the function of a D flipflop, or if I do an ECO design change, have no empty spaces to put another "real" D flipflop library cell that I somehow forgot, and have to combine a handful of NAND gates that I do have room for here and there, in order to effect a D flipflop function instead? Or, oh crap, that NAND gate should have been an AND gate. The AND (6 transistors) is too big to directly replace the NAND gate (4 transistors), but I have room over there for an inverter.

Can't say much about ASICs, but if they have overhead components needed for a circuit to work, while those components aren't part of the circuit design, then perhaps an ASIC is an emulation as well.

Do a NAND plus an inverter emulate an AND gate, or implement it in an ASIC?

Well, you can do an AND gate using a single relay or two transistors. Using two components made of transistors to make another that can actually be made of fewer transistors seems like imitating the behavior of that made part.

An emulated computer needs software. Some group of instructions that are continuously fetched from one of several types/levels of storage somewhere, decoded, ALUed, reading values from parameters and writing values to register or memory destinations, in order to effect the target opcode format, ALU, instruction decode, registers, memory map, etc. In what way do you think this activity is continuously occurring in the FPGA underneath your logic circuit?

In that way? Not at all. Don't ask me how it does work, but it should be obvious that FPGAs and computers do things very differently.

And another thought about "fixing" an FPGA. We'd once looked into but never sold a metal mask fixation option for our FPGAs, which would replace the configuration SRAMS and the LUT memory with metal hardwired 1's and 0's, should a security concerned customer want to do that to get a fixed die design instead of going through the effort of ASIC conversion. If I had a Minimig core designed to work well in my FPGA, and I did this metal mask replecement, most of the die is the same as the reprogammable FPGA, all those multiplexors are still there exactly the same way, but I can no longer change their controls, have I de-emulaterified this metal hardwired thing?

No, because there are more parts to replace with metal than just the SRAMS and LUT memory.

Thorham, what about CPLDs and ASICs. Are those also considered emulations of the real thing? I mean, in a CPLD, you don't have, say, two transistors which are directly, mechanically connected (such as using a printed circuit board that's custom made, which the components are soldered onto).

Don't know about CPLDs, but in general, if you have a programmable device in which you can make a circuit design actually work, then it's an emulation (also because of extra components needed which aren't part of the design).

[Thorham]

So the ULA chip in Spectrum was "emulating" all other gates different from the basic type available?!? :rolleyes:

Ha ha, you're right, that's taking it a little far. It's just some purist style thinking, perhaps.

[Thorham]

Thanks for trying to correct those of who do the topic of this thread every day for over a decade.

Just trying to get the emulation point across. If I made it look as if I was trying to argue over the functioning of an FPGA, then that wasn't my intention at all.

I have to admit you have some weird definition of emulation. And I can only agree with your definition if you also consider MS Word running in Windows a simulation of a (virtual) fully mechanical machine doing the same thing.

I think this is the base of the misunderstanding. You claim that soft-wired circuits == emulation, hard-wired circuits == no emulation.
So then you also have to claim software == simulation, hardware == no simulation.

I hadn't thought of that, but it sounds good to me. A program is just a fully functioning model of a data processing system, where the physical implementation is undefined.

I, and probably most people, would claim that hard-wired circuits can still be emulation of another device, e.g, the C64 in a joystick of Jeri Ellsworth

If it's not the original chipset, then yes.

There are no shortage of members here that like to post messages on how things work, when they have almost zero experience or knowledge on the topic.

And what does any of this have to do with what emulation is? Because that's what it boils down to.

You can ask this question about hardware (where my layman level doesn't help), and as someone has shown, you can ask it about software, as well.

It's not about the details of how an FPGA or whatever programmable chip works, it's about the fact that it's programmable, anything else just gets in the way.

[Thorham]

Is Super Buster rev 11 then an emulation of Super Buster rev 1 because it wasn't the first? Is 6582 an emulator of the 6581? Is 68060 mask 1e41j an emulator of 68060 mask 1F43G?

If Tramiel's Commodore had put the C64 into a single chip, would it be less of an emulator than Jeri's single chip?

That's a good point. Perhaps that is pushing it, but this is a gray area, as you said.

[Thorham]

I didn't say software was a netlist, but VHDL is a programming language. It even mentions it on http://en.wikipedia.org/wiki/Concurrent_computing
 
and here http://www.mlab.ice.uec.ac.jp/mit/text/JyoTsuEnsyu/VHDL_Language_Reference.pdf
 
If VHDL is a programming language then what you write is a program.
 
An FPGA is more efficient than using software on a CPU, but it's essentially doing the same thing.

From what I've learned from my arguing, this is not the case at all.

As you know, when writing a program in a higher level language than assembly language, you compile the program to an assembler program, and this is assembled into a binary containing the machine code instructions.

With VHDL, the program isn't translated into something like machine code at all. There is no program of any kind running on the FPGA, and although the VHDL has to be translated, it's translated into something completely different than what an assembler program would be translated into to.

While it's true that the basic idea is the same, namely programmability, FPGAs and CPUs achieve this is fundamentally entirely different ways. The word 'programmable' doesn't necessarily imply 'program'.