FPGA for dummies

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

[psxphill]

I consider emulation when the underlying layer has to use clock cycles to propagate state translations from the guest hardware to the real hardware API.

You need to come up with a different word, because emulation has no such requirement.

[psxphill]

68030 aren't completely identical in every way, yet if you put a 68030 accelerator in an A1200 you can still run your A1200 software.

It's not the same, because there are documented differences and it's easy to write software that works without an accelerator and fails when there is one.
 
What I'm referring to is not being able to simulate observed behaviour because the physical makeup of the chip is different.

[psxphill]

Now, take a look at AGA. Anyone think that was not designed in VHDL or Verilog? Can't be for a proper Amiga those then.

All you've said is that AGA isn't OCS.
 
How commodore made AGA is irrelevant, it's how you make something that behaves like AGA that is important.
 
Neither natami or winuae is a proper amiga.

[psxphill]

To give you an example, in the 6502 some of the "undefined op-codes" are a result of an incomplete decode PLA. What happens is some internal nets are undefined, and we can tell from the design if they are likely to float in one direction (high or low). Then, we get the same behavior. If it is unpredictable then different 6502 devices will also behave in different ways.

In the 6502 case it is mostly predictable, in other chips there may be other entropy that makes it harder to predict. As soon as you have to work out if they are likely to float in one direction or the other & adjust the VHDL accordingly, then you cannot be using the original circuit 1:1.
 
The side effects of an NMOS circuit are going to be different to that of a CMOS circuit. Even an FPGA & ASIC running from the same VHDL don't necessarily behave the same way due to clock skew.

 
It might meet the same documented ratings for timing etc, but that is meaningless when even trying to simulate something so it behaves exactly the same way when operated out of spec (which often is the case for undocumented side effects).
 
It wouldn't suprise me if you hadn't seen any of these issues on the Amiga, it was a pretty simple design that has had very few exploitable undocumented effects. However there are many other platforms where that is not the case and hopefully you'll get to those eventually.
 
Something like the Z80 R register, which is a read/write random register. However it's not really random because it's the ram refresh register. Loading it repeatedly can cause your memory to not be refreshed, so bits randomly drop out if the memory is not read by the CPU. I'd love to see how an accurate FPGA simulation of that would work.

[psxphill]

I knew I shouldn't have taken too many steps at once, so I'll break it down:
 
Is AGA a "proper Amiga" chipset (feel free to define proper so we don't have to go back on that later)?

I'll try to say this in a way that you might understand.
 
The AGA chips that commodore designed and had manufactured are "proper". Anything you design and manufacture are not the same.
 
For example, this:
 
http://en.wikipedia.org/wiki/File:Generic_Cola_Can_Jewel.jpg
 
is not this:
 
http://en.wikipedia.org/wiki/File:CocaColaBottle_background_free.jpg

[psxphill]

And the "legitimate" makers of Amiga also made the Walker, which has an FPGA in it. I understand this implements some new "custom chip" because they couldn't afford the megabucks to get an ASIC (custom chip) manufactured. Is Walker a partial replica, a simulator, an emulator, an actual computer, or something else? Or is Walker not legitimate enough for people here to discuss this way?

The walker is a walker, it's not an a1200 or an a500.
 
The processor and the graphics and sound chips however are the same ones as used in an a1200 or a4000.
 
Having an FPGA in it seems to be confusing you & I'm beginning to think that you're misunderstanding the concepts on purpose.

[psxphill]

I maintain that something like UAE where one computer executes a software program to pretend to be another is "emulation". R

This is the problem, you maintain that but it's incorrect. You don't need a CPU to emulate something. People emulate other peoples behaviour for instance and there is no CPU involved there.
 
So please find some other way to differentiate between the emulation you like and the emulation you don't like.

[psxphill]

What are you smoking? Did I say anything about liking one over the other? Sounds more like you have the prejudice.

How does it sound like that? I've said on more than one occassion that I like both. It's obvious from my question that I like both.
 
Only by saying that software is emulation but fpga is not emulation does it sound like prejudice.
 
At least someone gets it:
 
http://www.syntiac.com/fpga64.html
http://www.syntiac.com/chameleon.html

[psxphill]

Suppose for example we were talking about music players... You can have a casette player and a CD player. Both do the same thing, but in fundamentally different ways.

Using the FPGA isn't emulation argument then the CD player doesn't play music as it is converted from analogue to digital and then back to analogue, while the tape stores an analogue wave.
 
In reality they are both lossy audio storage & reproduction systems, but the loss is in different areas.
 
Using hardware or software for emulation is still emulation, you need to differentiate in another way.
 
A static recompiling emulator is fundamentally different to an interpreting emulator, yet neither is "not an emulator".

[psxphill]

I did say one of the methods, I didn't say the other didn't. You assumed.
A processor unless given an uneconomical performance will have a low probability to adhere to the clock cycle timing of the orignal design.

Depends on the circuit & the processor. There are circuits that are too fast to put into an fpga.

[psxphill]

Loading it repeatedly would cause corrupted memory, but I guarantee no two systems would see the same corruption pattern. An FPGA simulation using the same memory would behave in the same way. Normally we make our lives easier and use memory controllers which work, or SRAM - so you wouldn't have to worry about this particular problem.

Saying that you won't get this particular problem proves my point that what you doing with an FPGA is emulation. You pick the behaviour that you want to implement and produce a simulation of it.
 
Software could use this to detect that it's not running on real hardware, or software could use the random corruption as entropy for a PRNG.
 
You can't implement DRAM in an FPGA that will behave similar to 1980's memory when operated out of spec (i.e. not refreshed).

[psxphill]

Are you claiming using an FPGA is always emulation ? Is an FPGA based Cisco router emulation then ?

No, which is why I said "what you are doing with an fpga"
 

What are they emulating,

An Amiga, the emulation is good enough to run Amiga software.
 

are you also in the league that says this is emulating a fictional hardware implementation that never will be manufactured ?

No, don't know what you're getting at there but it seems irrelevant to the discussion of emulating 68k based Amiga hardware.
 

We could produce a better model of the DRAM by having an access counter per bit, and a pseudo random decay scanner - so yes with enough effort you can do it.

I know you can do it, but that would count as simulation & emulation. Which is my main point.

[psxphill]

ASICs don't run VHDL to function. You obviously don't know what you're talking about, perhaps a book would help. Here are Jeri Ellsworth's recommendations:
https://www.youtube.com/watch?v=kobf8IOB0oA

It's ok, I know about baking an ASIC from VHDL.
 
Running is a perfectly acceptable term for operating a circuit.
 
I guess you misunderstood what I meant, those books might come in useful.

[psxphill]

Likely related to the threeshold of the internal sense amplifiers. Ie before it reaches the thermal noise floor.

Yeah good luck with converting that 1:1 in an FPGA.

[psxphill]

You take the VHDL & it gets turned into an ASIC. I know how that works. Once you have the ASIC you run it when the clock starts. Running doesn't require a CPU style fetch execute mechanism, just a clock.
 
I understand whats going on physically in the FPGA and ASIC & it supports my argument about using an FPGA to recreate an Amiga is simulation/emulation.
 
I am not going to explain everything in minute detail, just so you can't find a way to purposefully misinterpret what I'm saying.
 
"It is difficult to get a man to understand something, when his salary depends upon his not understanding it" Upton Sinclair.