FPGA for dummies

[billt]

As far as classic Amigas are concerned, it is.  

As far as the guy who designed it, Id be surprised if Mikej comes over and tells us that, ues, his primary intention for doing the board was so he could make a Classic Amiga, and that anything else people use it for is just bonus. I'm sure he's happy that so many of us Amigans are excited about his product, but I can't imagine this was the purpose for making it.

[billt]

There's a post at aw.net about reconfiguring the FPGA on the SAM boards.

It takes around 13-17 secs to reprogram the FPGA on a Sam440ep.

http://amigaworld.net/modules/newbb/viewtopic.php?topic_id=34723&start=0&post_id=641977&order=0&viewmode=flat&pid=641594&forum=33#641902

I'd mentioned that reconfiguration is a significant event. You don't want to do it very often, as can be seen above. I'm sure other system designs can do it faster than that, but it's always going to be a significant "context switch" to swap out your hardware with something different. Even if only a partial reconfig.

[billt]

Indeed. I've certainly learned not to dive in when not knowing enough about the subject. It's something I'm not going to do anymore.

Well, the discussion lead to me understanding things a little better than I had. One way to increase your understanding of something is to teach it, or in whatever way explain it to someone else. It also helps improve how I try to explain things, let alone what I understand of that.

[billt]

With the few people in this thread that understand FPGA's better than the average bear, this is a good place to ask what the differences are between FPGA's and the XMOS programmable chips.

I don't have a great understanding of XMOS chips, so I'll defer to an expert there rather than risk talking about a wrong assumption.

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

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

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

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

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

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

[billt]

And things get really crazy if you consider a Meta-FPGA. I saw a project somewhere called Meta-FPGA that is an FPGA design, in both contexts of talking about an FPGA. it IS an FPGA, in that it implements a programmable logic architecture. It's Meta, in that it's a core intended to be configured inside of a silicon FPGA. It's an FPGA to exist inside of an FPGA. Though the project I knew of seems to have vanished, it was a student web page that is now a 404 error.

[billt]

That simply means AGA is a new version of the Amiga chipset.
Wait a minute, are the Amiga custom chips done in ASICs? Aren't ASICs chips that can be programmed once?
Indeed. As long as it's clear that it's a philosophy and not necessarily set in stone.

The Commodore custom chips were probably GateArrays. (I think I even saw/heard somewhere that the name for the Gary chip is simply an abbreviation for "GateArray") But this is again symantics, as marketing people at chip companies make up new words for essentially the same thing when an old word becomes to sound as if it must represent old technology to their customers.

An ASIC is a hard-wired chip. Application-Specific Integrated Circuit. The circuit design is turned into a gate level letlist (OR gates, AND gates, inverters, passgates, muxes, etc) and they are placed onto the die and then connected by metal wires and vias. That's a "Custom chip". It's custom manufactured to be exactly what the customer wants, and nothing else.

GateArray was a word to describe one way to complete an ASIC. In GateArray, there are different sizes of die, so smaller customer designs don't waste a horrible amount of die space, and large designs can be put into a large die. The logic area is a "sea of gates", in that a very regular pattern of transistors are laid down, available for use, and wafers are likely already manufactured up to that point. Then the customer design is really just a custom set of metal and via masks to connect things together. Where an OR gate was placed, the transistors on the wafer are connected by metal to complete that OR gate. If that location was an AND gate, then those transistors are connected by metal to complete an AND gate. Any gate locations not used will have transistor silicon p[resent, but tied off to be non-functional, and instead will likely become capacitors on the power bus. (gate to the source/drain area under the gate is essentially a capacitor in all CMOS transistors) It's a metal-programmable method, in that no particular circuit of any kind exists until metal wiring is fabbed to define one.

Then there is Standard Cell, the word that came after GateArray sounded "old". In Standard Cell, things are really only a minor difference to GateArray. Standard Cells have more customization per logic gate layout, and they do not have the very regular structure underneath. but you can lay down rows of logic gates, and include some extra things beyond the actual design, in case an error is found then you might (hopefully) be able to use some of those extras to fix things with a metal-mask only change later. While logic gate placement in Standard Cell doesn't give the super-generic underlayer structure that Gate-Array does, it can still be considered a metal-programmable technique. As far as what we chip designers do to make a Standard Cell ASIC die design, it's exactly the same thing(s) we do to make a GateArray style ASIC.

ASSP, or Application Specific Standard Product, is another term for ASIC, with some particular marketing meaning to it. it, like an ASIC by name, is a custom chip designed for one and only one application. The marketing terminology difference is that a customer may not be abel to afford to have his design made exclusively for himself and no one else. But it's important he gets it. So he can get the ASIC made, but the fab house is able to sell it to other customers in addition to the original customer. The original customer gets a discount this way, and is one way for a smaller company to get a custom chip made when he otherwise cannot afford such a thing.

SoC, System On a Chip, is an ASIC. It'll go through the same design steps and go through the same kind of fabrication as any other ASIC/custom chip using that fab process. The SoC ARM processors in your cell phones are ASICs.

Flash memories are ASICs, at least at my employer. It only adds a few layers to the wafer manufacturing process. SRAM chips are ASICs. FPGAs are even ASICs. The last FPGA silicon designs we did here were using the ASIC group design flow. Even before that, the more custom layout was also an ASIC, in that the specific application the integrated circuit was to be, was an SRAM-based FPGA. Then we added a microcontroller on the same die, and had a programmable System On Chip, and that itself was an ASIC too.

An ASIC does not get "programmed". It gets manufactured. And as soon as the last layer of the wafer is manufactured onto it, it gets cut into individual die, put in a package, and that's your final complete chip. Nothing comes after that except testing, shipping, and PCB assembly.

[billt]

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

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.

[billt]

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.

That's not a requirement of an FPGA implementation.You can do truely combinational logic in an FPGA, select the final mux to pass the non-flipflopped signal instead of the flipflopped signal. No flipflop, no clock. Only passgates, multiplexers, and buffers, and none of those need a clock to be present for them to work. None of them even have clock pins to connect one to.

If your own circuit is a sequential thing, such as a state machine, then you will need to use flipflops to implement that, same as you need to do in a custom ASIC. You can't do sequential without a clock. And the clock involved in the FPGA here is the one for your own circuit design, not some FPGA "background" clock. There is no FPGA "background" clock driving the FPGA silicon to act like your own circuit.

Regarding the Meta-FPGA, it's an interesting project because it eliminates the vendor-lock-in of synthesation software. In fact one could order a basic FPGA ASIC with plain fabric if enough money could collected to cover startup costs. Every extra chips is as expensive as a postage stamp..

@billt, url of that 404-site?

http://ce.et.tudelft.nl/~reinoud/mpga/README.html

[billt]

It's not 1:1 because the cell in the FPGA is nothing like the gates in an ASIC.

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.

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.

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?
 

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.

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.