FPGA for dummies

[shoggoth]

Saying that FPGA isn't emulation because an FPGA is parallel or isn't programmed the same as a CPU is just plain stupid.

 
You clearly misinterpreted my comments, or didn't read them in their proper context. You have been claiming similarities between FPGAs and CPUs on the basis that they're both programmable devices, programmed using programming languages, and… other things which only makes sense if you disregard all technical facts about this matter. I wouldn't go as far as to call that, quote "plain stupid", but I'd definitely call it ignorant.

I've worked on a couple of very well known emulators, so I know what I'm talking about. Linking to wikipedia is more so I don't have to rewrite what they already said. kthx

I've implemented user land emulators and worked on a number of low level emulation frameworks, including semi-cycle accurate ones, which means I'm not entirely unfamiliar with the inner workings of emulators either. Other posters may very well know what they're talking about, even if their opinions about stuff differ from yours.

Just to make sure we understand each other. I don't claim to be an expert on VHDL and FPGA technology, but I have used it to implement several projects. For real. Now, that doesn't mean I'd use your words ("so I know what I'm talking about"), because that would be, quote, "plain stupid".

Problem here is about belief vs. technical facts, and since I'm not much of a believer I don't think I have anything more to add here, at least not to this particular part of the discussion.

kthx.

[freqmax]

Problem here is about belief vs. technical facts

Thumbs up.

[billt]

VHDL looks like programming but I bet it is a bit pattern when done.

If you are purring your design into an a FPGA, yes. And a bitstream is in no way a "program". It's a "configuration".

And the exact same VHDL can instead end up as a logic gate netlist to become an ASIC instead of an FPGA bitstream.

[billt]

It will be slightly slower than a plain ASIC because the extra circuitry to make it possible to change function on the fly.

Not all FPGAs have the capability of changing on the fly (reconfigurable).

They are slower because of how you make logic be so configurable instead of fixed. Lots and lots of multiplexors and passgates are needed all over the place to give you so many choices of where your signal connections go.

[freqmax]

Not all FPGAs have the capability of changing on the fly (reconfigurable).

I mean the ones with SRAM based configuration. They can usually change configuration in 1/10 - 10 seconds depending on size and interface. Some even manage partial reconfiguration during usage.
Maybe you mean the ones using builting EEPROM that loads the internal SRAM?

They are slower because of how you make logic be so configurable instead of fixed. Lots and lots of multiplexors and passgates are needed all over the place to give you so many choices of where your signal connections go.

Certainly slower, but the key factor is still if it's within the timing specification or not.

[billt]

I mean the ones with SRAM based configuration. They can usually change configuration in 1/10 - 10 seconds depending on size and interface. Some even manage partial reconfiguration during usage.
Maybe you mean the ones using builting EEPROM that loads the internal SRAM?

Your post read that the reason that the capability for reconfiguration is the reason that FPGAs are slower than ASICs of equivalenty circuit. That's not the case, no matter what kind (sram, flash, antifuse, whatever) of FPGA it is. Reconfiguration capability is irrelevant to why FPGA is slower than ASIC. Other things are the reason why FPGAs are slower.

Certainly slower, but the key factor is still if it's within the timing specification or not.

And the capability to reconfigure is irrelevant to meeting timing or not.

[freqmax]

I did not mean that reconfiguration capability implies slowness. But it's a common result with current SRAM reconfigurable gates.

[billt]

I did not mean that reconfiguration capability implies slowness. But it's a common result with current SRAM reconfigurable gates.

Maybe we're thinking somewhat different things around the term reconfigurable.

What makes an FPGA an FPGA, ie. what makes it configurable, is what makes it slow. (All those muxes and passgates are propogation delays in your wire connections)

What makes an FPGA reconfigurable on the fly, to change what it is configured to be while the system is running, is irrelevant to that.

SRAMs don't have any impact to your signal propogation delay. They are not in the path of your logic circuit, they are around it or beside it. Your circuit's signals do not go though any SRAMs, do not go through any FLASH, do not go through any antifuses or whatever other ways there are to make FPGAs themselves.

The LUT SRAM doesn't even impact your speed. When the LUT is configured, it then outputs static 1's and 0's. Your logic design selects which 1 or which 0 coming out of the LUT SRAM to put on the wire. You are not going through a LUT SRAM for anything, so it does not affect speed in any way. The multiplexors that choose which but of the LUT to connect to at that moment are propogation delays. The inputs of your logic are what selects things on these particular multiplexors. Changing which LUT bit is passed to the output is not a reconfiguration, it is simply the operation of your logic circuit.

[psxphill]

Problem here is about belief vs. technical facts, and since I'm not much of a believer I don't think I have anything more to add here, at least not to this particular part of the discussion.

I agree, it is belief vs technical fact.
 
For some reason there are people who believe that an FPGA simulating an Amiga chipset, isn't actually simulating it. When the technical fact is that the FPGA turns up from the factory waiting to be programmed and when it is, it simulates an Amiga chipset. There is nothing you can do that will turn it into a real Amiga chipset, even if your VHDL is as close as you can make it to the original gate layout.
 
They do this because they believe there is something magically better about a simulation in VHDL on an FPGA than C on a PC.
 
There are advantages to simulating using an FPGA, both cost and determinability. However a bug in your VHDL is going to make your simulation as innaccurate as a bug in your C code.
 
While on a PC you may struggle with latency issues, because the video, sound and i/o are abstracted. Some of these can be worked around by using DOS, others by sacrificing some efficiency.
 
I understand the difference between writing VHDL & C and the difference between how a CPU and a FPGA work. However there are alot of common concepts.

[billt]

There are advantages to simulating using an FPGA, both cost and determinability. However a bug in your VHDL is going to make your simulation as innaccurate as a bug in your C code.

A bug in your VHDL also makes the simulation running inside your ASIC inaccurate.

[psxphill]

A bug in your VHDL also makes the simulation running inside your ASIC inaccurate.

yes, it doesn't matter whether you run your VHDL through an FPGA simulator, bake an ASIC or compile it to executable code for a CPU. A bug is going to have the same effect.
 
You have to know how the hardware really works and then convert that into something you can express in VHDL before you can simulate the hardware in all circumstances accurately.
 
As some demos (and to some extent games) use undocumented behaviour then this is tricky. It's made even harder if you use non deterministic behaviour, or behaviour that relies on capacitance when nothing is driving the bus, or what happens if two things try and drive it.
 
Anything that relies on side effects of the gates in the original chips is going to be very different when expressed as VHDL than the original layout was (even if the original layout was designed in VHDL).

[Thorham]

When it's about doing Amiga hardware in an FPGA it's simple: Only the chipset's functionality is replicated and not the original chipset blueprints. This means that you have an imitation and not the real thing. Saying that it's the real deal, is like saying that a replica of a car is the same as the original.

[billt]

When it's about doing Amiga hardware in an FPGA it's simple: Only the chipset's functionality is replicated and not the original chipset blueprints. This means that you have an imitation and not the real thing. Saying that it's the real deal, is like saying that a replica of a car is the same as the original.

Yea, like how ECS is a simulation of OCS, because it didn't come from those original blueprints, it came from some later design spec.

[Thorham]

Yea, like how ECS is a simulation of OCS, because it didn't come from those original blueprints, it came from some later design spec.

OCS, ECS and AGA are simply different revisions of the Amiga custom chipset. FPGA implementations are blatant imitations, nothing more, and it's also doubtful that FPGA implementations show exactly the same behavior as the OCS, ECS and AGA chipsets (same goes for WinUae).

[freqmax]

Yeah the Amiga chipset emulates Amiga.

[billt]

OCS, ECS and AGA are simply different revisions of the Amiga custom chipset. FPGA implementations are blatant imitations, nothing more, and it's also doubtful that FPGA implementations show exactly the same behavior as the OCS, ECS and AGA chipsets (same goes for WinUae).

But AGA, like ECS Natami and Minimig, come from something other than the original chipset blueprints. They are all nothing more than imitations of OCS with some new enhancements beyond that, and are not in all ways timing identical to the really original OCS hardwired chips.  They cannot be anything other than ghostly simulations when running OCS software. I just don't see why a new implementation in an ASIC (custom chip, whatever you call it) that somehow differs from the really original thing is different than doing the same in an FPGA. But we may never come to agreement on that philosophy.