FPGA for dummies

[psxphill]

I do not consider FPGA implementations to be "emulation".

 
An FPGA Amiga is not an Amiga, so it must either simulate or emulate one. Whether you consider it such is irrelevant & is more related to you preferring an FPGA over an emulator.
 
"emulation: The low-level simulation of equipment or phenomena by artificial means, such as by software modeling. Note that simulation may also allow an abstract high-level model."
 
"simulation: Simulation is the imitation of some real thing available, state of affairs, or process. The act of simulating something generally entails representing certain key characteristics or behaviours of a selected physical or abstract system."
 
The major difference between an FPGA and a software emulator is you don't have to work round operating system limitations on an FPGA. However the FPGA is still an emulator.
 
Similar to a software emulator, the actual chips are simulated. To emulate a 68000 you'd have to dump the microcode and use that to run opcodes, using the same logic as the original chip. Nobody does that (at least not yet).
 
All we have is an emulation of the environment that the software runs in. Whether that is produced by software or an FPGA.
 

Uhm, WHAT?! You're saying that silicon layout is similar to writing a computer program? You're on some pretty wacky weed there dude.

FPGA appears to be pretty similar to writing a computer program.
 
http://en.wikipedia.org/wiki/Verilog
http://en.wikipedia.org/wiki/VHDL
 
And you can bake your FPGA to a mass production chip.
 
There has been work to make it even more like writing computer programs.
 
http://sourceforge.net/projects/fpgac/
 
You could also go the other way and come up with a way of drawing all your different coloured polygons and turning them into a program.

[psxphill]

(which by the definitions in this threads are "not emulations" of the "real" thing - because they're hardwared).

Just because it's hardwired is irrelevant. Using a cpu with an emulator stored in rom is also hardwired.
 
An FPGA just removes a layer of abstraction, otherwise it's largely the same.
 
Yes an FPGA is hugely parallel, but you can get hugely parallel processors (think GPGPU).
 
I don't mind using software or hardware (i.e. FPGA) for emulation, both have their uses.
 
But to say that emulation is bad and FPGA is good is missing the point that it is itself an emulation.
 
Even if you cloned the gates 100% using an FPGA it would still be an emulation (because the original didn't run on an FPGA).

[psxphill]

You don't "have to" use microcode in any microprocessor implementation, be it ASIC or FPGA. (Consider that a custom microprocessor design such as Motorola's original 68000, Intel's Core i7, AMD's FX, etc. are the same class as ASIC, ie very fixed hardwired stuff)

The 68000 uses microcode, therefore to emulate it you would have to use the microcode. If you don't use the microcode you are only simulating it. Just because the microcode is in mask rom is irrelevant.

[psxphill]

Please describe the layer which has been removed. Are there any additional layers below? Please describe any that remain as well as the one removed. I've tried to give as detailed an explanation of my understanding of FPGAs as I can in a lunch hour. Please do the same.

With software emulation you have some form of operating system, general purpose CPU etc that are used to simulate gates. While on the FPGA you have gates. Everything else is the same concept.

[psxphill]

But with claims like "FPGAs are essentially CPUs" just because they can be programmed to perform a function is... awkward. No offense.

I didn't say FPGA's were essentially CPU's, just that they have alot in common. With regards to emulation they perform the same function.
 
Saying that FPGA isn't emulation because an FPGA is parallel or isn't programmed the same as a CPU is just plain stupid.
 
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

[psxphill]

FPGA's are nothing like CPU's. And certainly nothing like software emulation using a CPU.
 
Software emulation is a re-creation of the hardware in an abstract model. Whereas FPGA's can re-create the logic of the original 1:1 (if the original logic definitions are available).

An FPGA and a CPU are more similar than you suggest (you specify 0% similarity). How similar would depend on what CPU, or GPGPU etc that you pick.
 
They both take a program, although VHDL/Verilog have more in common with with functional programming languages than older langues like C.
 
Think http://en.wikipedia.org/wiki/Concurrent_computing with a couple of million cpu's.
 
It's not really possible to do a 1:1 mapping of a custom chip to VHDL. You're going to end up doing some things slightly differently.
 
What it comes down to though, simulation and emulation is about recreating something. If you took a VHDL 68000 simulator and put it on a DIP carrier so it could plug into an Amiga then what would it be:
 
1. A 68000.
2. A simulation of a 68000.
 
This thread isn't the only place where simulation/emulation in hardware is mentioned. It has been common to use the terms even in fixed purpose hardware that behaves similar to other hardware.

[psxphill]

Freecale, if they wanted to, could make a 68000 chip, hardwired on silicon, that does not use microcode to implement the 68000 instruction set. Motorola chose to use the microcode method, they did not have to. If they had chosen not to back in the 1970's, would their product running out Amiga 1000, 500, 2000, etc. computers have only been a simulator of a processor, not a real processor?

It's unlikely that freescale would do that and still call it a 68000, they have managed to avoid reusing the same number up until now at least.
 
As for the second part, you can't rewrite history. However if in 1970 the 68000 didn't use microcode then the 68000's would still be real 68000's. If you made one that worked differently (i.e. used microcode) then it would be a simulation.
 

An FPGA does NOT take a program. The bitstream data is essentially a netlist. A software executable is absolutely not essentially a netlist.

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.
 

The guy that made the custom chip can, and most likely already did, as that's how you design chips these days in the first place.

We're talking Amiga custom chips here, which predate VHDL by a long shot.

[psxphill]

But VHDL is NOT a "programming language". It IS a "hardware description language". VHDL is an acronym for VHSIC Hardware Description Language. (VHSIC is an acronym for Very High Speed Integrated Circuit)

It is a programming language (released in 1987, way after the Amiga).
 
Even IEEE call it a program, http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=386221
 
Plus books http://users.ece.gatech.edu/~sudha/book/starters-guide/
 
It might not be like other programming languages you've used, but it was based on ADA & there are other concurrent languages that are similar.
 
Not sure about any of the Amiga chips, but definately the C64 cannot be 1:1 mapped to an FPGA because of analogue components used in SID & VIC.

[psxphill]

FPGA programming can't be compared to CPU programming at all.

It can be as VHDL is just one of many functional programming languages that are designed for parallel processing. There are many other very similar languages used on PC's.
 
Whether your program is converted to X86, ARM, 68000 or FPGA is irrlevant to the process of writing the program.

[psxphill]

I think you are getting confused, hardware description languages are not programming languages, despite their similar appearance... Both myself and Karlos had a look at one a few years back and struggled to follow what was going on... Very different conceptually!
 
-edit- I should add that both myself and Karlos are quite experienced with a number of programming languages, but neither of us have done any FPGA work (though I do a lot of electronics hobby work).

VHDL is not C, but I didn't say it was. VHDL is a concurrent programming language, there are others that can be used to write applications for windows/linux etc. If you only have experience of sequential programming languages then I could see why you would struggle to follow VHDL but you'll struggle with other concurrent programming languages too.
 
Pick one out of this list and see how you get on.
 
http://en.wikipedia.org/wiki/Concurrent_computing#Concurrent_programming_languages
 
(notice that VHDL is on the list).

[psxphill]

It won't emulate, simulate, run any code or anything else. All that is plain misunderstanding.

It doesn't run code, but you can emulate or simulate something with an fpga. Emulation/simulation doesn't require you to use a sequential programming language running on a cpu.

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

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

[psxphill]

Let me ask a question.
 
We are now scanning dies of some 1980 ASICs. From this, we can do polygon extraction - then transistor extraction and then reduce to gates.
 
This netlist can be synthesised back into an FPGA, or a modern ASIC.
They would be functionally identical.
 
Is one "emulating" the other?

Yes. It's the behaviour you are emulating. You didn't (and can't) just do a 1:1 copy of the gates. For example, if you scanned the die of your asic then it wouldn't look anything like the original chip.
 
Alot of the chips you wouldn't even be able to just take functionality and convert it. For a c64 you'd have to add extra logic to take care of the undocumented behaviour, because your new ASIC won't have the same side effects (and the FPGA and ASIC wouldn't behave the same either).

[psxphill]

He just described one method to get the exact gates netlist from the original chip die. Ie, to use the original custom chip as it's own blueprint. So yes, using that is by definition a 1:1 copy of the gates. If you've done a correct job of scanning the original die, then you cannot possibly end up with something different from it. As it is exactly the same logic circuit, then any undocumented registers, values, modes, whatever are indeed there, exactly as the original die implements them. Any logic bugs in the original chip are there exactly the same in your scan.

It's not 1:1 because the cell in the FPGA is nothing like the gates in an ASIC.
 
http://en.wikipedia.org/wiki/Field-programmable_gate_array#Architecture
 
The cells are configured in different ways to produce the logic that you want. In an ASIC you wouldn't build something as complex to make a single and/nand/or/nor gate. Even if the VHDL is based on an ASIC die the result is as far from the original as a C simulation (you could build a C simulation from a die scan as well).
 
undocumented behaviour is not the same because alot of them rely on the analogue behaviour of digital gates and the cells in the FPGA aren't going to behave like that at all.
 
when you build an asic from VHDL you would just put the gates in, but electronically they are still going to be different than the original. So any analogue effects (resistance/capacitance etc of the circuit) may differ just because of different lengths and the gate chemistry.
 
If you take a look at resid then you'll see how difficult it is to simulate a sid chip using digital concepts.
The colour generation in vic is analogue based, because it operates in NTSC/PAL colour space.
 
The c64dtv started as an fpga and turned into an asic & the emulation in vice is so much better. The DTV doesn't even simulate the filters AFAIK.