FPGA for dummies

[mikej]

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?

Even a crude VHDL copy of an Amiga ASIC is very likely to be much closer to the function of the original than any software model. Bugs in the design become apparent very quickly.

You have to realise that the chips in the Amiga/Atari are very simple and small by todays standards. By testing the FPGA copy against the original we get nearly 100% functional coverage - the analyser proves the two designs are running in lock step and highlight any difference in them.

Best,
MikeJ

[mikej]

If you make a scan and put that into a custom ASIC, then yes it is an exact 1:1 copy. I was under the impression that the definition of simulation/emulation in this thread included
ASICs that did not come from the original VHDL/schematics.



Analog behavior of the digital gates?! Eh? How does an AND gate behave any differently than an AND gate due to this magical Analog nonsense?
 


You can determine what is a resistor, what is a capacitor, etc. in the die scan. To a little probing to associate resistance/capacitance/etc. values to feature sizes, and implement those values in your custom ASIC remake. Analog clone. Direct from the original die itself.

I'm quite enjoying this thread.

psxphill, note that both billt, myself and a few others on here actually do design ASICs.

Billt's comments are completely correct.
Lets have one more go at explaining this. (Billt, please ignore the simplifications)

An Amiga ASIC is a standard cell part, so it consists of a regular grid of gates, chosen by either a synthesis tool working from a high level language, or directly chosen by the designer. Each gate is a simple logic gate, or flop. These gates are connected together by routing layer(s) in a grid above the gates.

An FPGA is also an ASIC, which consists of a regular grid of configurable gates, overlaid by a fixed routing grid with programmable connections. So, rather than choosing the configuration of each gate, and the routing when you make the top masks for the Amiga chip, we can configure it on the fly.

Now, assuming pure digital circuits then the original ASIC and FPGA configured with the same netlist will behave 100% identically.

You talked about "adding extra gates to get the exact behavior" - well, the strange behavior is purely a result of the logic in the chip.

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.

You also talk about the routing delays being different. This is true, and also true between different batches of the same ASIC. As long as the logic resolves before the next clock cycle, it doesn't matter how long it takes. That is why we have timing analysis to prove the design is stable.

/MikeJ

[mikej]

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.

Well, you are actually - you are more accurately modelling the original circuit. However, any two (original) devices will probably produce different results, so which is correct?

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.

um, yes they would. All devices have clock skew correct, but as long a skew + logic delay + flop set up < clock period they will behave identically. Always.

 

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.

The register you talk about is not random in the slightest, it is a counter used to generate the address for DRAM refresh. 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.

[mikej]

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

Name one?

[mikej]

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

Um, well it depends. If you attached the same DRAM to the FPGA Z80 core, you would get exactly the same behaviour. 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.

My point is, the Amiga core chipset is 1) fully sync so the underlying logic structure matters not one bit, and 2) so small and simple it is easy to get it pretty much totally accurate.

If you were to take the same netlist and produce a modern 65nm ASIC say, then the timing for that would be further off than the FPGA copy - but all three devices would be functionally interchangeable.

/MikeJ

[mikej]

And what makes you think that the internal logic of an FPGA Amiga "re-implementation" is anywhere near the original internal logic of the chips it intends to emulate? These are complex state machines and aren't trivial to implement and test. I'm sure the FPGA emulation magicians here are doing a great job by making qualified and well-informed design guesses based on information that exists about these chips, and black box testing them with the original chips, but I doubt they are making exact copies of them at a gate level.

Not exact, but fairly close actually.
The Amiga chipset is very low gate count by any modern standard, and it's pretty easy to work out how they would have implemented it in logic. Functional testing against the original chipset lets you check the design at cycle level. Going further it is possible to trace the original chip die and extract more complex functionality exactly.
/MikeJ

[mikej]

Coupled with propagation delays, you might have to do things differently in the fpga than the original hardware did it to achieve the same result.

Perhaps, but the difference is rather minor. The register in the Amiga chipset which used to get the memory contents from a DRAM read still gets exactly the same contents on the same clock cycle. The job of the new memory controller is to deliver the data faster that the original implementation so nothing else notices the difference.
 

An fpga is going to be more efficient than a software emulator, cost and availability are more of an issue though. But there is no magic that means it's going to be more accurate.

In theory perhaps, although usually you are not in control of the entire software stack.
I am curious, your 100% accurate software emulation (tricky as hardware is inherently parallel and I assume you are running a single CPU to do your emulation) - how does it actually get audio or vidio data out to an external device in real time?

/MikeJ

[mikej]

No, but that has pro's and con's. You can use any input device (keyboard as joystick or PS3/Xbox 360 gamepad) or any host operating system graphics card or printer driver. But that isn't an emulation accuracy issue.

As somebody who has just written a USB to Amiga mouse/keyboard interface - believe me there are accuracy issues. Perhaps to many they don't matter, and I can minimize them with a local processor running a dedicated USB stack directly connected into the FPGA which is running a secondary processor to reduce latency as much as possible.

 
 

Latency is one of the drawbacks of software emulation. Whether it's noticeable is arguable.
A lot of modern TV's have worse latency in their up scaling and post-processing, some gamers complain and others don't. Even "game mode" on your TV doesn't guarantee you won't have any latency.

I was more thinking how your software actually produces a stream of data which can be injected into a display device? Your off-the-shelf graphics card will never behave quite the same as hardware your software is emulating. Even if you sync at each horizontal blank interrupt you are not going to stay in sync as the pixel clock is not locked to the "hardware" as it is in the real (and FPGA clone) hardware.

So, there is a real measurable difference between a software emulation and an FPGA implementation.
I would challenge you (given there are no obvious bugs) to tell OR MEASURE the difference between a real A500 and the Replay board in a blind test. Put each one in a black box with the IO ports wired up and try. Now try it with a UAE.

/MikeJ

[mikej]

It will never be correctly phase locked to the video generation logic though will it?
Maybe this doesn't matter, you can (and need to) emulate the whole frame buffer and calculate where the output pixel is at all times. Then you can pass this frame out once you have computed each pixel - but it will always be more laggy as you need to hold this to the next vsync. Unless the video clock is locked (it won't be) then you will always get tearing - unless you run each frame emulation a bit faster than you need to ensure you have it ready. But, then what happens with the audio?
It's get's really tricky very quickly. Trust me, I used to work designing broadcast systems.


/MikeJ