Amiga.org
Amiga computer related discussion => Amiga Hardware Issues and discussion => Topic started by: b41d3r on December 05, 2011, 07:06:42 PM
-
Hi,
I'm really noob in Amiga, and I watch all this excitement around FPGA with double dutch terms for me as I'm more into software than hardware. As a matter of fact, not at all in hardware.
Can someone tell a poor ignorant what it implies for us ?
Is it something really so marvelous for the future of our platform ?
Why ? Does it concern only the game field ?
-
Using FPGAs makes it possible to develop hardware with the same sort of investment as software. Once you have a basic platform like the minimig, FPGAarcade Replay, or the Natami, you can redesign the hardware at will by "recompiling" the design and reloading. You're not tied down to obsolete hardware. The folk working on the AGA minimig and the Natami are optimising the CPU - something Motorola (Freescale) is unlikely to do, as well as updating the Amiga chipset.
-
Thanks.
What I don't still get is that if I can configure my hardware in a software fashion, what about my Amiga ?
Can it, with only help of new drivers, work in a new hardware environment ?
I thought these monolithic machines were quite impossible to separate from their initial specification. Will it work only for new Amiga OS or for the classics too ?
-
An existing classic Amiga, probably not... The FPGA amigas are about recreating the existing Amiga hardware - with extensions - inside an FPGA chip. How well that works depends on the skill of the people doing the design. Frankly, it amazes me that it works at all, much less as well as it does. ;-)
You can add new hardware beyond what the the original spec defined.. then you have to have some sort of software... or the new hardware could emulate some existing classic hardware that already has software. The AGA amiga core has a "gfx card" built into it that's compatible with an existing workbench extension made for the cards used in "real amigas".
-
The 680X0 CPU in your Amiga, as well as the various ECS/AGA chips, are silicon chips which are fixed in a permanent state. They were custom chips, designed for a specific purpose.
The FPGAs of today are like 'blank chips'. There's nothing at all in them. What you do, is at boot-time, you 'select' which 'soft core' you want 'loaded' into that FPGA chip. It (the FPGA chip) then becomes whatever you need it to become. In the case of Minimig and FPGA Replay etc, the 'soft core' contains the instructions necessary to turn that FPGA into a 68K CPU, complete with ECS, AGA chips etc.
So it goes from being a machine with a blank chip, to being a machine with a 680X0 CPU and AGA! And this is NOT emulation, it is done in real silicon, thanks to the FPGA chip! So now, when you run Amiga software, all it sees is the 68K CPU, the AGA chips, etc. and they will run no differently than if it was a 'real' Amiga, because it IS a 'real Amiga'. The FPGA reacts to Amiga software in much the same way as the 68K, Lisa, etc. chips in an A1200 would do.
With the FPGA Arcade Replay, you'll eventually have a choice of hardware platforms to choose from at boot-up: Amiga, Atari ST (gasp!), Commodore 64, Arcade machines, etc. The FPGA 'becomes' what you need it to become, and hey presto! You have a custom computer system created at boot time :) The beauty of the FPGA is, however, that unlike 'real' chips, the FPGA code can be enhanced and improved, added to. AGA can become SuperAGA. You can eventually have a CPU with the compatibility of an 68020 but running software faster than a real 68040 or 68060 could, etc.
I hope this clears things up for you?
-
Yes, very much.
But I suppose there's a bonus compared to using the original machine itself apart from the capacity of changing my system at will.
If I have a classic Amiga, is there any interest for me to get this thing ?
It seems so by reading posts about it,but I don't see why.
Will it for example allow me to connect to modern printer or network card by some trick ?
-
For me I'd pick say, an Arcade FPGA because it comes with:
A 030 or even faster equivalent CPU
A DVI connector (built in scandoubler!)
64 MB of RAM
All that of the fraction of the price should I get a similar gear with real Amiga parts... Sure, it may not be 100% compatible but its still damn good.
Oh and its all brand new.
-
Hi,
I'm really noob in Amiga, and I watch all this excitement around FPGA with double dutch terms for me as I'm more into software than hardware. As a matter of fact, not at all in hardware.
Can someone tell a poor ignorant what it implies for us ?
Is it something really so marvelous for the future of our platform ?
Why ? Does it concern only the game field ?
I've not used FPGAs before, but I've done a lot of silicon layout to make FPGA chips. I'm this spring taking a VHDL course at university using FPGAs. I hope to learn how to do some of my ideas. :)
An FPGA is a generic logic chip, which can be programmed to become a specific logic chip. You can make it become nearly any logic circuit you want. ASIC chip designers use FPGAs to prototype and debug their cictuits before spendign huge amounts of monty on ASIC fabrication masks. (kindof like camera film negatives, it's a similar usage) People cho cannot afford an ASIC production can use FPGAs in their product instead, since they are cheaper for a small quantity need. (for very large quantity needs, ASICs are far cheaper than FPGAs)
Most FPGAs today are reconfigurable while running, which means you can change part of the circuit they are behaving as. This has a benefit in that some things won't always run at the same time as each other, and you can have only one of those things loaded into the chip as it is needed, and change to the other as needed.
There are limitations, as each FPGA has a certain capacity, a circuit requiring more than a chip has to offer won't fit and needs a larger chip. But today FPGAs can hold quite a lot of things. And you can use multiple FPGAs together to increase total capacity. The other limitation is performance. It takes a lot of overhead to make an FPGA as generic and programmable as it is. To act as a simple AND gate, it will run slower than an ASIC that can simply place a single AND gate and nothing else around it. The FPGA needs to control routing through passgates and multiplexors, which slow things down compared to a simple wire in an ASIC.
To "program" an FPGA (the technically correct term is "configure") you load a bitstream file, which tells which passgates to go on or off, which way for multiplexors to select, what logic each segment will behave as (this programs a small RAM to act like logic, logic inputs go to the address bits, the output of the RAM is the logic output), and selects which flipflops are or are not used in the path, etc. Then the FPGA "is" your desired logic circuit. Some people think this is "emulation", I disagree. It's "implementation". It's not running software. It's not pretending to be an AND gate, it is an and gate. Or an Amiga500. or an Atari. Or a Commodore64. Or a Zorro to PCI bridge. Or a graphics chip. Or an ethernet controller. Or an IDE controller. Or a SCSI controller. Or an AC97 audio controller. Or...
The two big languages for FPGA designers to use are VHDL (popular in europe and US military/aerospace indsutries) and Verilog (popular in commercial US industries). You don't "compile" it, you "synthesize" it into a logic gate netlist. The gates netlist is then placed and routed into the FPGA fabric to become your desired logic chip. The FPGA does not "run" the netlist, it "becomes" the netlist. The chip does not normally change the netlist it "is" while running, the circuit it implements is what runs. Any change to the FPGA netlist is called a "reconfiguration", and once that is done, it now "is" the new circuit.
As for games, I'm not sure how it would best improve things there. It could be an FPU if you otherwise lack one. I've toyed with the idea of making an Altivec unit on a PCI card for PowerPC chips that lack one. (Sam4** for example) I'm not sure how well that would perform compared to software emulation of Altivec on a non-Altivec CPU, as things need to exit the chip, cross PCI, get into the FPGA, run at whatever speed the FPGA can give me, and go back through PCI into the CPU again. All that overhead may ruin the idea. And I have a lot to learn about microprocessor design before I try.
As for other ways we can benefit from it, we can use it as an accelerator for various things. I had an idea way back in the day to make an FPGA on a Zorro card to be a multimedia hardware codec. A reconfigurable one, so it would be a hardware MP3 decoder or encoder, or an mpeg2 video decoder or encoder, or mpeg4, or ogg vorbis, etc. for Classic machines whose 68060 just wasn't fast enough to keep up. Never made it of course, but could have been. need an encryption chip? FPGA can. There's a lot of things it can be used for.
I do think that FPGA offers a lot. I would love to see a big and fast one on a motherboard. Some Sams have a small FPGA. It's not big enough for my taste. Not does it have connections to do a lot of things. I'd like to see it multiplexed with audio connectors on the back, so it can be an audio chip. (HD Audio/Azalia anyone?) I'd like to be able to multiplex whatever VGA card I have through it, so the monitor can take the VGA card or can take something video out of the FPGA. (AGA anyone?) I'd like a lot of pins for connecting stuff up. (SCSI anyone? or Ethernet? or what else can you imagine?) I'd have done for the X1000 Xorro slot an FPGA instead of an Xmos chip, but you can probably do a lot in Xmos that you can in FPGA. But in a big fast FPGA, you could do so much more than an Xmos. (IMHO of course, as I know far more about FPGAs and only a little about Xmos. Everything I imagine using Xmos for, I could do in FPGA. Some things I imagine using FPGA for I don't think I could do in Xmos)
But for a PC-alike thing like X1000, XE, Sam460, etc. I think we'll get more use out of PCI/PCI-Express slots. Most things I'd put into FPGA are already on store shelves as PCI or PCI-Express cards.
Things like Minimig or natami or CloneA or AOocs are made for FPGAs. With enough unused space in there, you can add more. Minimig with its own native SCSI bus. Minimig with its own native SVGA (as Yaqube is doing already for FPGA-Arcade board) Minimig with FPU. Minimig with native PCI slot. Whatever you want to add, if there is capacity and usable connections, you can. (If there are not usable connections or capacity, make a new board with those connections and larger FPGA)
-
And no legal infringement ?
If I need a new system, I assume I must already have it.
So, it could only provide a cheap spare system but not a way of commercializing new Amiga on the market, right ?
-
Yes, very much.
But I suppose there's a bonus compared to using the original machine itself apart from the capacity of changing my system at will.
If I have a classic Amiga, is there any interest for me to get this thing ?
It seems so by reading posts about it,but I don't see why.
Will it for example allow me to connect to modern printer or network card by some trick ?
If you already have a classic Amiga you're happy with, I'm not sure Minimig etc. will change anything for you. The biggest thing you might see is performance improvement. Because FPGAs today can run a pretty fast system, you can see FPGA-Arcade or Natami implementing a CPU faster than your dedicated 680x0 chip. While some will have 68060 hard chip to start with, that is to be useful in making sure the AGA chipset and other things work well before making the internal 680x0 core. Easier to know where a bug in your design is that way, compared to "is that in my graphics chip or in my CPU?". Once the chipset cores are good, then make and debug the 680x0 core. It's expected that these internal 680x0 cores will perform faster than any hard 680x0 from Motorola/Freescale.
Also, if you don't have the fastest 68060 in your classic, then an FPGA-Arcade when it has a Minimig port including internal 680x0 may be a cheaper performance upgrade than a real classic 68060 board. it might hold more RAM than a Classic as well, though I'm not sure what the plans are for that on FPGA-Arcade or other FPGA boards.
-
Well, it depends on what you're looking to do. In my case, I need a replacement for my Amiga 4000, which sadly died some time ago :(
I need something which is cheap, yet which can outperform the older Amigas, and offers me something new. I'm not really interested in something expensive, or bulky. I want something which is relatively cheap, yet powerful and expandable - and small. For me, FPGA Replay fits the bill perfectly!
Not only can it run at 030/040 speeds, but they're working on making the core perform as well as an 060 CPU. The Chip RAM limitation has also been removed - the Replay supports upto 50MB(!) of Chip RAM. This makes entirely new video modes possible. AGA can perform functions much faster, and there's no need to buy a graphics card since one's essentially included in the FPGA Replay's core. I also like the idea of being able to use a SD Card as my hard disk. Something about that is just really neat - and convenient too! :)
As for connecting to printers or network cards - well, there are USB connectors, and a slot for a daughter board expansion on the Replay. There are plans for a daughter board which will contain a socket for a 68060 CPU, as well as ethernet and USB ports, etc. so networking should be possible if provided with compatible drivers. I'm not really sure about printers, I'm afraid. This isn't something I've looked into as it's enough of a problem just trying to get my printer to work with the MacBook! :lol:
-
Thank you all, especially Billt.
Now I can graduate in a computer course thanks to you ! :)
-
I'd like to ask a question ;) .... is the Amiga core for Arcade FPGA (and minimig?) based on UAE or its reverse-engineered?
-
Well, it depends on what you're looking to do. In my case, I need a replacement for my Amiga 4000, which sadly died some time ago :(
I need something which is cheap, yet which can outperform the older Amigas, and offers me something new. I'm not really interested in something expensive, or bulky. I want something which is relatively cheap, yet powerful and expandable - and small. For me, FPGA Replay fits the bill perfectly!
Not only can it run at 030/040 speeds, but they're working on making the core perform as well as an 060 CPU. The Chip RAM limitation has also been removed - the Replay supports upto 50MB(!) of Chip RAM. This makes entirely new video modes possible. AGA can perform functions much faster, and there's no need to buy a graphics card since one's essentially included in the FPGA Replay's core. I also like the idea of being able to use a SD Card as my hard disk. Something about that is just really neat - and convenient too! :)
As for connecting to printers or network cards - well, there are USB connectors, and a slot for a daughter board expansion on the Replay. There are plans for a daughter board which will contain a socket for a 68060 CPU, as well as ethernet and USB ports, etc. so networking should be possible if provided with compatible drivers. I'm not really sure about printers, I'm afraid. This isn't something I've looked into as it's enough of a problem just trying to get my printer to work with the MacBook! :lol:
Ok, so I can get into something new thanks to this hard. So Amiga would become a viable modern system. And in fact, it could compete with new Amiga if not outclass them.:hammer: This could lead to an internal competition in Amiga world or a quick adaptation in the current Amiga.
But something troubles me, how the hell can I transmit my "real" Amiga to the FPGA ? Can I do it myself or do I need a prebuilt software ?
-
Ummm you can't? You just buy an FPGA motherboard with all the parts populated. Put the kickstarts on the SDCard and more or less you are good to go. Maybe, technically, you could dump your own Kickstart from real Amiga HW :)
-
My question is since this is emulation in hardware how is it closer to or further way from Amiga hardware than UAE?
-
Is it emulation in hardware? I'm confused =)
A common question I see (not sure what it means) when it regards to FPGA is "is it cycle-exact?"
-
FPGA is not emulation. It's the recreation of the physical chips under a reconfigurable chip.
-
Is it emulation in hardware? I'm confused =)
A common question I see (not sure what it means) when it regards to FPGA is "is it cycle-exact?"
I do not consider FPGA implementations to be "emulation".
When you load the FPGA bitstream file, you are opening or closing routing connections, you are selecting inputs to multiplexors, you are telling each LUT which logic circuit it is to be (for this input value give that output value). When configuration is done, the FPGA is nto "processing" anything, it is not running software to do any of what the bitstream said. When configuration is done, the FPGA now "is" the defined circuit. All those passgates and multiplexors are now really just wires to the defined circuit. The LUTs are logic circuits. The flipflops are flipflops. There is no "emulation" which is "running" There only is a logic circuit which "is".
And the only thing that is happening is whatever your circuit is defined to do. Flipflops are flopflopping. Logic circuits are giving outputs appropriate to their inputs. Routes are wires. That's it. And there's no software or anything else operating above, below, or beside that.
If you have defined a 680x0 processor, then the 68000 processor is running 68000 software or waiting to do so. If you have defined a Zorro to PCI bus bridge, then it is converting bus cycles. If you have defined a SCSI controller, then it is controlling SCSI peripherals according to commands it receives from the host bus. If you've defined a DDR memory controller, then it is controlling DDR memory according to the host bus. That's it. If you have defined it to be an Amiga 500 with 68000 and PCI and DDR2, then it is running 68000 software, talking to PCI cards, and talking to DDR2 memory chips. Wires will clear flipflops the same way that wires clear flip-flops in custom ASIC chips. Clock signals tell flipflops to take in new values from their inputs the same way as they do in Custom ASIC chips. And gates give 1 when all inputs are 1 and otherwise 0 the same way that AND gates do in Custom ASIC chips. OR gates give a 1 output when any input is 1 value otherwise 0, same as in an ASIC. Wires conduct signals the same way as wires do in Custom ASIC chips. A 32bit CPU register is made up of 32 FPGA silicon flipflops, same as in an ASIC. Multiplexors to select datapaths in an ALU are made up of FPGA silicon multiplexors. This is hardware being routed to wire up silicon, same as logic gates are wired up in an ASIC.
It's just that the FPGA lets you change your wiring around, while an ASIC is fixed. FPGA provides a flipflop on silicon in every section. Maybe two. But it lets you skip over them if you don't want them. An FPGA can have this particular NOR gate here, or reroute and put it over there, etc. by changing which passgates are closed and which way multiplexors go. An ASIC wire is fixed by the production masks.
That's it.
In an ASIC, to connect the output of an OR gate to an inverter, you draw a wire. All silicon. In an FPGA, there are things to be OR gates and inverters on the silicon, and there's a lot of wires all over the place, which can potentially connect just about anything to anything, or disconnect anything from anything. The bitstream is read into static memory elements which control the connect or disconnect at each point, and are used to connect the various bits of silicon-level wire between your OR gate and your inverter. All hardware, all silicon.
That's it. And maybe the best way I've said it so far in this last bit.
-
And this is NOT emulation, it is done in real silicon, thanks to the FPGA chip!
It is an emulation in the purest sense of the word because it's not done in silicon but simply by using instructions that are of a lower level than machine language instructions. An FPGA is just a programmable chip just like a CPU, it only serves a different purpose than a CPU.
-
It is not emulation as we've come to understand that term because there is no software playing 'translator' between the Amiga software designed for one architecture (68K+AGA), and the radically different host hardware (Intel+Nvidia) it must function under. Software emulation involves on-the-fly translation from one architecture to another. The FPGA on the Replay, OTOH, simply 'becomes' the hardware of a real Amiga. There's no translation. The FPGA 'becomes' the 68K CPU, the Lisa chip, and so on.
The hardware on the Replay, when functioning with the Minimig AGA soft core, is the hardware equivalent of a real AGA chipset with a 68K CPU. You won't physically see a 68K CPU and Lisa chip inside the system, but they're there - implemented within the FPGA itself.
This is why the Replay's motto is, very appropriately enough, "No Emulation. No Compromise." :)
Of course, the FPGA core is not based on original Commodore code because that's not available to us. But the Minimig AGA soft core on the FPGA is designed to respond to the same instructions in as similar a way as possible to a 'real' Amiga, and so it has a high degree of compatibility.
It is an emulation in the purest sense of the word because it's not done in silicon but simply by using instructions that are of a lower level than machine language instructions. An FPGA is just a programmable chip just like a CPU, it only serves a different purpose than a CPU.
When most people think of emulation, they think of something akin to a real-life translator, sitting in the middle of the 'Amiga' and the host hardware. I think if I were to search for an appropriate word to describe what the Replay is doing, I would go for the word 'cloning' over emulation. It's kind of like how the original IBM PC was cloned - or how the AMD functions the same as an Intel CPU. Yes, in a technical sense they may be 'emulating' the hardware they're designed to copy/replace. But I don't think we'd use the word emulation to describe what they're doing. The Replay is only 'emulating' an Amiga to the same extent an AMD 'emulates' an Intel CPU.
-
It is an emulation in the purest sense of the word because it's not done in silicon but simply by using instructions that are of a lower level than machine language instructions. An FPGA is just a programmable chip just like a CPU, it only serves a different purpose than a CPU.
This is a common misconception due to the fact that you use a "language" to define the circuit. It's really an "hardware description language", not a "programming language".
The program is not executed, it is synthesized. VHDL is inherently parallel (unless you tell it to do otherwise), up to the point you could use most of the chip resources at the same time, in the same clock cycle.
Which is not unusual for massively dataflow designs: consider an array of FIR filters, then you have combinatiorial and sequential logic (and an internal state), but not necessarily a state machine, a sequencer, or a microcode ROM. Hence no CPU.
The short answer was: "what billt said". :)
-
Interesting, so it is or isn't emulation depending on how you define emulation, sort of emulation in a cheshire cat or perhaps a Schrödinger's cat sort of way.
-
Interesting, so it is or isn't emulation depending on how you define emulation, sort of emulation in a cheshire cat or perhaps a Schrödinger's cat sort of way.
Exactly! :)
The English language can often be fuzzy, but what's not fuzzy is what we tech-heads typically mean when we refer to emulation. We're referring to software which has been written to enable programs written for a completely different architecture to operate under an alien host system, via an on-the-fly translation process.
Which has absolutely nothing to do with what the Replay and other FPGA devices are doing. They no more 'emulate' an Amiga chipset /CPU than an AMD CPU 'emulates' an Intel CPU. We're simply talking about a different way of implementing the Amiga chipset and CPU in hardware. In that sense, these FPGA systems are more like Amiga clones.
-
It is an emulation in the purest sense of the word because it's not done in silicon but simply by using instructions that are of a lower level than machine language instructions. An FPGA is just a programmable chip just like a CPU, it only serves a different purpose than a CPU.
No, it is not like a CPU. It is silicon. If I want a flipflop, that flipflop is a silicon flipflop, not a software or firmware running on some kind of processor to pretend to be a flipflop. There are not zillions of little processors laying around running some kind of code telling them how to be And gates, OR gates, Inverters or whatever. It's all silicon. I've done silicon layout of FPGA chips, I know what they look like inside, how things connect to each other, and how it all works.
Now, to decide you want an AND gate, you are not necessarily connecting to a 4-set of transistors that are exactly an AND gate and nothing else. You're connecting to a LUT, which is a small memory. The address bits of this memory are the inputs to whatever logic gate you do want, and the output of the memory is the desired output for each input set. This still is not emulation, as there is no code running. You decide what your logic truth table for this gate is, and program the output values of that truth table into this memory. Then your logic inputs select which output bit your logic demands for the current input. There's no processing there, only multiplexing to select the desired value. And after configuration, each bit is fixed. Everywhere. Back in the day it was one method of doing hardware design to use a ROM chip for a complex logic gate with lots of inputs. A ROM chip does not have a processor in it to do any emulation, it's just one way for something to "be" some logic circuit. The FPGA uses an SRAM or a fuse instead of a ROM, but it's the same principle. The LUT is a progammable logic gate, and it acts as a logic gate, and once programmed it is fixed as that logic gate until it is reprogrammed as something else or loses power. It does not have something looping on the inputs, considering what they are, and going somewhere else to look up how to respond. The LUT knows what the LUT needs to do, and it IS that. It IS logic, and it IS silicon.
Calling an FPGA an emulator is like calling a ROM chip an emulation of a ROM chip. Sounds weird huh? It makes more sense to say that a ROM chip IS a ROM chip, no? Someone might come up with a very nitpicky debate about AMD emulating an Intel chip. (going into what is x86 and what does microcode mean or do, but that also means that Intel itself makes x86 emulators, not x86 chips, and you could make an FPGA implementation of x86 that is less "emulation" than a Core i7 is)
-
If I want a flipflop, that flipflop is a silicon flipflop, not a software or firmware running on some kind of processor to pretend to be a flipflop.
Of course, because that flipflop is a low level entity similar to a machine code instruction. The opcode is simply of a higher level than a flipflop.
I've done silicon layout of FPGA chips
Which is similar to a CPU program, only on a lower level than machine code.
The principle is the same:
With a CPU you describe your functions using high level instructions which are executed serially, while with an FPGA you describe your functions by telling the FPGA how it's gates have to be wired up, which operate in parallel, because you're describing an electronic component.
No hardwiring=emulation.
-
Calling an FPGA an emulator is like calling a ROM chip an emulation of a ROM chip. Sounds weird huh? It makes more sense to say that a ROM chip IS a ROM chip, no?
It's funny you bring up ROMs. I was trying to come up with a similar analogy - that FPGAs are to fixed-code chips like Lisa, what RAM is to ROM.
Both these pairs can hold programming, it's just that one pair is empty at boot-up and capable of being rewritten (RAM/FPGA); whilst the other (ROM/Lisa) has programming which is fixed and read-only, but is immediately accessible on power-up (ROM/Lisa).
If I have a 1.3 ROM machine, and I boot up and then soft-kick it with Kickstart 3.1 (into RAM), am I now 'emulating' 3.1, or actually running the real thing? Of course, I am running the real thing; it's no different to an Amiga with a 3.1 soldered to the circuit board (except I've used up a little RAM). It's immaterial whether the kernel is present in ROM or RAM to the Amiga. The operation is pretty identical either way, and the speed and performance is much the same however it's loaded.
If it helps people to understand the concept, just think of using FPGAs to implement AGA as being like the equivalent of using RAM to soft-load a Kickstart (much as the A1000 did). Except instead of putting Kickstart into RAM, we're loading AGA chips into FPGAs. FPGAs, like RAM, lose their contents upon power-down, but they have the advantage they can be programmed. That doesn't make it any less a 'real Amiga' than one with fixed AGA chips, any more than a machine soft-kicked into 3.1 isn't really running Kickstart 3.1.
-
When I try to explain this to non-tech types, I mention the 100 in one project board I had as a kid. It was a pile of components mounted on a masonite board with springs on the leads. It also had a pile of wires.... put the wires in the right places and you could make all kinds of stuff... Multipliy by about a billion and you have an FPGA. ;-)
-
In the end UAE or FPGA, you are still running on silicon and silicon that is different to the original hardware. I have no problem with that, it's all Amiga to me, I was just wondering how you justify one over the other.
-
Most chips digital chips consists of a bunch of transistors wired in a way that makes them used in a way where they are either fully on or off. Wires can't be changed inside a chip. But a bigger bunch of transistors can be wired to give the same function where the function is dependent on transistor states instead of wires. This makes the ground for FPGAs.
The penalty is that transistor configurations that depend on more transistors is slower but will still be fast enough to respond properly. The other penalties are the configuration complexity and heat.
So in essence a few transistors with wiring is replaced with more transistors and wiring but where the function depends on the state of some transistors used as memory instead of hard wired cables.
These FPGA Amigas are essentially a clone just like AMD CPU is a Intel clone. Or an implementation of the original schematic.
Information sources are UAE, and testing of real hardware to get the function.
The devices you need can either be implemented with the FPGA provided there's enough "free" configuration transistors or via USB. The original hardware gets broken by time and there's no replacement for the original chips.
-
Information sources are UAE, and testing of real hardware to get the function.
So, if there is an "error" in UAE, it will be reproduced on FPGA?
-
Of course, because that flipflop is a low level entity similar to a machine code instruction. The opcode is simply of a higher level than a flipflop.
You don't know what a flipflop is, do you? Certainly not how a flipflop compares to an opcode. (it doesn't) A flipflop is a bit. A 1 or a 0. It's held at the same value between clock edges, and only at the defined clock edge does it pass the input value to output, and hold it until next clock edge. That's 3 wires (4 if you have the negated output value as well), and maybe 6 transistors. It's a single bit storage unit. An opcode is a code, a particular value made up of 1s and 0s. It's not a storage unit. It's a command. I don't listen to my lunchbox ordering me around, do you? And the words coming out of a drill sergeant's mouth are not very useful for putting your stuff inside of are they?
I've done silicon layout of FPGA chips
Which is similar to a CPU program, only on a lower level than machine code.
The principle is the same:
With a CPU you describe your functions using high level instructions which are executed serially, while with an FPGA you describe your functions by telling the FPGA how it's gates have to be wired up, which operate in parallel, because you're describing an electronic component.
No hardwiring=emulation.
Uhm, WHAT?! You're saying that silicon layout is similar to writing a computer program? You're on some pretty wacky weed there dude. Layout is the drawing of what the silicon looks like. Drawing transistors, made up of nwell, active, P+implant, N+implant, active, poly, contacts and wires. Drawing wires between them for connections. Drawing resistors, diodes, etc. and connecting them with metal layers wiring. Red polygons, green polygons, blue polygons, tan polygons, and a variety of other colors and shades for different layers. How is that in any way comparable to writing a program? What does your crayola language do when it sees blue? Red? Yellow? I've recently been doing analog layout for an automotive chip. Not programmable, all hardwired. It's the same task, the same polygons, as drawing an FPGA. And this analog chip has no processing capability whatsoever. There's no program of any level running inside that picture of a diode. It just IS a picture of a diode. There's no program running inside a PFET. It just is a PFET. It doesn't need to go look up how to respond when the gate is a 0, it just is something that has a conncetion between the source and drain when that gates is 0. And when the gate is 1, it just is an open connection. There's no lower level than machine code running in that transistor telling things what to do, it just does.
Whether you have a single shape of blue metal1 connecting two things together, or if you have a passgate (one or two transistors) and a multiplexor (two or 4 transistors) in between, connected with metal1, metal2, metal3, metal4, etc. jumpign all over the place, it's still a connection. Electrons conduct from point A to point B. Anything in the middle is just stuff for the electron to conduct through. They get to point B and charge up the gate to a 1, or they all flow back the other direction and discharge the gate to a 0. Those electrons actually are flowing mack and forth, they're not falsely pretending to just because you say so.
-
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 (http://en.wikipedia.org/wiki/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/ (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.
-
"emulation: The low-level simulation (http://en.wikipedia.org/wiki/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."
Applying these rules strictly, a 68000 is just an "emulator" (or "simulator") of the same circuit made with discrete logic, which in turn is a simulation of transistor gates, and so on down to the electron flow level... hmmm yes, this might be true, any Amiga is just "emulating" the original Lorraine boards made out of TTL chips! ;)
FPGA appears to be pretty similar to writing a computer program.
It appears, but it's not. Abstracting the circuit with a program-like listing it's just a convenient human representation.
The only parts of a VHDL (or verilog) design matching your description are testbenches, written in purely behavioural style.
AFAIK it's not possible to produce a working (complex) FPGA design out of purely behavioural description (i.e. like translating a software algorithms and constructs).
Structural VHDL is much more similar to circuit schematic entry and PCB layout, than to a programming language. Despite resembling the latter more.
And you can bake your FPGA to a mass production chip.
Unfortunately it's not that simple. If it was, producing custom ASICs running at 500MHz and more would be one order of magnitude cheaper.
-
The FPGA isn't a 68K chip, it's emulating one. A different FPGA emulates the custom chips. Amiga OS runs on top of this emulated hardware. UAE emulates a 68K in a program, this same program emulates the custom chips. Amiga OS runs on top of this emulated hardware.
-
@billt
You're throwing pearls before swine. Some obstinate folks on here just aren't going to believe you no matter what facts you present to them. Just add them to your list of ignorant, argumentative, SOBs and move on.
-
The FPGA*replay doesn't emulate, it RECREATES the cpu and custom chipsets of the Amiga. Is this hard to understand?. Also for the people who say is the same to program as well as designing a chip, what are you smoking guys?.
-
In other words FPGAs are "set it and forget it" emulation whilst software emulation is not. It's a much purer form of emulation.
But if you tell the FPGA to create a gate, how does it do that? What is the FPGAs actual method of creating a gate inside itself? How does it remember that gate? What is actually going on at the physical level? Surely there aren't a lot of nano-bots building and tearing down hardware inside the FPGA.
-
So, if there is an "error" in UAE, it will be reproduced on FPGA?
From what i know, none of the fpga amigas uses uae in it cores, so i don't know how you reach to that conclusion...
-
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.
No, it's actually related to what I know an FPGA to be before anyone puts anything at all into it.
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.
I guess some people really want to believe that.
[/quote]FPGA appears to be pretty similar to writing a computer program.[/quote]
An older way to do FPGA design is to use a schematic diagram, which was the way before HDLs came along. Is drawing a schematic diagram really the same thing as writing C or assembly code?
After the Minimig is working to satisfaction, and the very exact same Verilog or VHDL (or schematic) is dumped into an ASIC, which is a fixed wiring design of the exact same circuit, is that ASIC still an emulation? Is the C64DTV less of an emulator than the CommodoreOne is, since the C64DTV is a fixed ASIC compared to CommodoreOne's FPGA?
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.
I'd like to see how you'd define a language based on colored shapes and their overlap interactions with each other, and how you'd have the compiler turn them into machine code.
I understand that an FPGA is a different sort of chip, and it does come closer to the idea of emulation, and I realize that some people want to embrace it as an emulation no matter what is inside of it. I am steadfast in my believe that an FPGA is "implementation" rather than "emulation". It seems a few of you are steadfast the other way around, and I guess maybe it's best to leave it at that.
-
You don't know what a flipflop is, do you? Certainly not how a flipflop compares to an opcode. (it doesn't)
When you look at a flipflop as some unit of functionality then it does compare. The difference is the way in which they are used.
An instruction is a collection of circuits that the CPU uses when it fetches an opcode that tells it to use those specific circuits, while in an FPGA things like flipflops and logic gates (and what not) are connected together through user definable wiring.
Uhm, WHAT?! You're saying that silicon layout is similar to writing a computer program?
No, not literally of course. In essence the process is similar, because in both cases you're telling a machine what to do (with an FPGA this is done by telling it 'how to be wired up', so to speak, unless I'm missing something).
Not programmable, all hardwired. It's the same task, the same polygons, as drawing an FPGA.
And in an FPGA it's of course not hardwired, otherwise you'd have to open the FPGA and add and remove tiny little wires.
There's no lower level than machine code running in that transistor telling things what to do
The point is that the transistor IS the lower level. Basically the components in the FPGA that you wire up together are the lower level parts I'm talking about.
An opcode is higher level because it's made of lower level components such as transistors. The lower level of a transistor would then be the components it is made of, and obviously these aren't instructions, but 'bits (NOT computer bits) of silicon and other stuff'.
Those electrons actually are flowing mack and forth, they're not falsely pretending to just because you say so.
Flowing through connections that are, in an FPGA, user definable. There aren't any fixed connections that are user defined (would require the chip to be opened up), and therefore there's no hardwiring.
The programming of a CPU and an FPGA, while done in completely different ways, is both a form of programming. The difference is that a CPU fetches instructions from memory that tell the CPU which parts of it's circuitry to use, while with an FPGA you instead describe those circuits (lower level again).
The whole point is that the function the chips are performing isn't fixed, but user definable, in a CPU it's just done indirectly, because you can't change the circuitry, while with an FPGA you can.
An FPGA emulates a circuit, because while the components are fixed, it's wiring is not, and therefore the circuit isn't fixed. It imitates a circuit's function by providing user definable wiring. Wires are part of a circuit, and these aren't fixed here.
-
I find this philosophical argument about Emulation vs Real hardware equity funny.
Either via a software emulator or an FPGA, there is a recreation of the original functionality of the old chips. Neither is more "real" than the other and both "emulate" (meaning: appear to be like the original hardware from a user and software perspective) the Amiga.
For those unsure about FPGA chips, think of them as thousands of little 74xx chips in one package that can be connected anyway desired by software.
An FPGA allows a hardware designer to build his circuits in a single chip, rather than use lots of separate components all soldered together on a circuit board :)
-
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).
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) It's one way to do things, and quite common, but not the only one. In a lot of processors the programmer won't have any visibility of the microcode and won't know what it looks like. Some CPUs allow access there, but others it's an invisible thing that we'll only know is even present or not if the designer tells us so.
-
But if you tell the FPGA to create a gate, how does it do that? What is the FPGAs actual method of creating a gate inside itself? How does it remember that gate? What is actually going on at the physical level? Surely there aren't a lot of nano-bots building and tearing down hardware inside the FPGA.
The gates and other logic elements are already there. The connections between them are what gets loaded to "wire up" whatever circuit the designer defines. Check out the first chapter of this http://www.xess.com/appnotes/FpgasNowWhatBook.pdf
-
I find this philosophical argument about Emulation vs Real hardware equity funny.
Either via a software emulator or an FPGA, there is a recreation of the original functionality of the old chips. Neither is more "real" than the other and both "emulate" (meaning: appear to be like the original hardware from a user and software perspective) the Amiga.
I've thought that this emulation vs "real" argument amusing at times as well. I'm more concerned about semantics here. There is a difference between the two, from the technical viewpoint. That has nothing to do with which is "better" or which is a "real Amiga".
For those unsure about FPGA chips, think of them as thousands of little 74xx chips in one package that can be connected anyway desired by software.
An FPGA allows a hardware designer to build his circuits in a single chip, rather than use lots of separate components all soldered together on a circuit board :)
I visualize the original Lorraine wire wrapped prototype here. ;-)
-
It should be noted that VHDL and Verilog are languages which are technology-independent, and are used to implement logic on a wide range of hardware, including ASICS (which by the definitions in this threads are "not emulations" of the "real" thing - because they're hardwared).
FPGA appears to be pretty similar to writing a computer program.
http://en.wikipedia.org/wiki/Verilog
http://en.wikipedia.org/wiki/VHDL
The VHDL language is used to describe the logic function of a circuit; it's not a sequencial program which emulates that circuit. The result is synthesized for the target technology - ASIC, FPGA, CPLD, PLD etc. If you're crazy enough you can even print a schematic of result of the synthesis and implement it yourself using 74-circuit.
This raises a question: If I do this. I design a circuit using the VHDL language, and implement the result of the synthesis using 74-circuits. Would this still be an emulation?
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.
FPGAs are inherently parallel and perform logic functions just like a (huge) bunch of 74-circuits would. A software emulator is inherently sequencial since it's executed by a CPU. FPGAs don't execute anything. You could have a software emulator running on a system without an operating system. This would still be extremely different from a hardware implementation on an FPGA.
All this is (very) clear to people who work with this stuff, or who has at *least* taken some rudimentary courses on this subject. There are good books about this too.
An FPGA emulates a circuit, because while the components are fixed, it's wiring is not, and therefore the circuit isn't fixed. It imitates a circuit's function by providing user definable wiring. Wires are part of a circuit, and these aren't fixed here.
By this definition, all programmable logic are emulations of "real" circuits.
There are many types of programmable logic circuits, all of which the function is described using the VHDL (or Verilog) language. Just because FPGAs use lookup tables similar to SRAMs instead of fuses or some reprogrammable incarnation of the same thing, doesn't mean it's an emulation of that circuit.
-
But if you tell the FPGA to create a gate, how does it do that? What is the FPGAs actual method of creating a gate inside itself? How does it remember that gate? What is actually going on at the physical level? Surely there aren't a lot of nano-bots building and tearing down hardware inside the FPGA.
This is fundamental switching theory; the FPGA uses lookup tables for combinatorial logic and logic for interconnects, MUXes etc. These lookup tables are similar to SRAMs, and this is why FPGA contents is volatile.
-
Just because FPGAs use lookup tables similar to SRAMs instead of fuses or some reprogrammable incarnation of the same thing, doesn't mean it's an emulation of that circuit.
This is fundamental switching theory; the FPGA uses lookup tables for combinatorial logic and logic for interconnects, MUXes etc. These lookup tables are similar to SRAMs, and this is why FPGA contents is volatile.
And there we have it: Lookup tables. This means there's no physical chip, which means it's an emulation (imitation). Or perhaps it's about the meaning of the word 'emulation' being interpreted in different ways.
-
And there we have it: Lookup tables. This means there's no physical chip, which means it's an emulation (imitation). Or perhaps it's about the meaning of the word 'emulation' being interpreted in different ways.
No, this is again fundamental switching theory. Lookup tables is a common way to describe a combinatorial logic function, it's not unique for FPGAs at all. The only difference in that case is that the tables are volatile in the case of the FPGA, and that their state has to be defined after power up. But apart from that, LUTs are used in all programmable logic circuits afaik, and I wouldn't be surprised if a considerable part of any ASIC design also ends up being synthesized into some kind of lookup table.
EDIT: Of course it's not an emulation of a "real" chip. It's a medium for programmable logic, nothing else. The same code can be put into an ASIC as well, giving the exact same function and timing.
-
(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).
-
An FPGA just removes a layer of abstraction, otherwise it's largely the same.
This is so untrue I don't know where to begin. FPGAs are the equivalent of a huge number of 74 logic gates. It's a programmable device, but so is a CPLD, or even a flash memory (which can be used as a programmable logic chip, btw). An FPGA is not even similar to a CPU.
Yes an FPGA is hugely parallel, but you can get hugely parallel processors (think GPGPU).[/quote]
There are multi-core CPUs, but each of these cores are inherently sequential and execute code. FPGAs does not execute code. They're merely a representation of a bunch of logic gates and flipflops, which can be *made* to execute code by implementing a softcore CPU.
Argumentation based on "I heard that" and random links to wikipedia without sound background knowledge makes it really difficult to discuss things. I understand that you'd like to make a point, and there is nothing wrong with that. But with claims like "FPGAs are essentially CPUs" just because they can be programmed to perform a function is... awkward. No offense.
-
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).
So for something to be 'real' and not emulated, it must be hardwired in a permanent form onto a silicon chip? If that's the criteria we're to use, then what does that make the original Amiga 1000? After all, the ROM for the A1000 had to be soft-loaded from floppy disk - it didn't exist in a permanent chip form!
Does this mean the original Amiga 1000 wasn't a fully-real Amiga? Or are future Amigas the emulated ones, because they didn't copy the exact method used on the original Amiga and were using a different, hardware approach?
If the FPGA Replay is 'emulating' an Amiga simply because it uses a different approach to configure the chips, then so is the Amiga 1000, or anyone else who soft-kicks a Kickstart on their Amiga for whatever reason (e.g. to upgrade/downgrade their machine without replacing the physical ROMs.)
My point here is there's more than one way to achieve the same result. If you can recreate 100% the operation of the original Amiga chips, in hardware, and without any need for real-time translation, then that qualifies as a clone system, in my view. Software emulation is something very different, and involves real-time translation from one system architecture to another.
I must admit, though, this entire topic seems to be devolving into a debate over semantics. I think we all know where each other is coming from, and that most of this discussion seems to hinge on how each individual poster interprets the meaning of the word 'emulation'. We're debating different meanings of the same term, whilst agreeing for the most part on how the different technologies work. Can't we declare a truce? ;)
-
But if you tell the FPGA to create a gate, how does it do that? What is the FPGAs actual method of creating a gate inside itself? How does it remember that gate? What is actually going on at the physical level? Surely there aren't a lot of nano-bots building and tearing down hardware inside the FPGA.
OK, but you asked for it. :p This is a bigger question that you may have realized, but fasten your seatbelts for a quick & dirty lesson in the digital logic design that an "empty" FPGA chip actually is.
I seem to have surpassed the single post character limit, so I'll try and split this into two posts.
I'll use terms such as passgate (sometimes also called transmission gate), multiplexer, LUT (lookup table), flipflop, and maybe a couple other terms which I will not define here. For those that do not already understand their definitions, I'll leave them as research topics for you, but I'll give a little description of how they are built. Read elsewhere for more in-depth descriptions. But they are very basic digital design elements.
A passgate for example can be made from a single transistor, but they are often made from two transistors in CMOS technologies. It's a very simple switch, and either connects input directly to the output, or it separates the two ends from each other. To compare with other digital logic gates, a CMOS 2-input NAND gate is made of 4 transistors. A 2-input AND gate is likely made up of 6 transistors (basically a 4-transistor NAND followed by a 2-transistor inverter).
http://www.csee.umbc.edu/courses/graduate/CMPE640/Spring07/cpatel2/lectures/lect16_combo3.pdf
A multiplexor can be made from a group of passgates, to make a sortof passive implementation, or it can be a stack of AND and OR and interter gates to make a more active output drive implementation.
http://en.wikipedia.org/wiki/Multiplexer
A flipflop (slightly more complicated than a latch) is often a loop of storage elements with passgates in between, and when the clock sets the input side passgate to open or closed, this allows the flipflop input value to overdrive a different stored value in order to have the flipflop replace its previously stored value with the current input value.
http://en.wikipedia.org/wiki/Flip-flop_(electronics)
FPGA silicon is a fixes silicon array of logic elements with a lot of fixed wires between them. Each wire is a segment, not a complete path, but it is a length of metal drawn across the silicon.
A logic element is made up of a LookUp Table (commonly shortened to LUT for less typing), one or more flipflops, and a bunch of multiplexors and passgates, and SRAMS which store your design configuration.
The LUT is a small memory with some multiplexors on the output side. When the FPGA is configured on powerup, this memory is programmed to contain the output 1 and 0 values of the logic gate you want it to become. The inputs to your logic gate control multiplexors which select a particular bit of the memory, and the value of that memory bit is your 1 or 0 output value of your logic gate. I may have said in a previous post that the address bus of this LUT memory make up your logic gate inputs. If I didn't already correct that, the address to your memory is only used during configuration of what is held inside the memory. After configuration, the contents of this LUT memory are "fixed". Most FPGAs today are made from SRAM based LUTs, so they can be reprogrammed from one power cycle to the next to do different things, and this also allows possibility of reconfiguration while the system is on and running. (see Reconfigurable Computing) Older FPGA silicon designs used fuses (or anti-fuses which close when told to do so) to set the 1 and 0 logic values, and they were typically NOT changable. If you found a bug in your circuit design, you put that buggy chip in the trash and bought a new chip. A FLASH based FPGA may have small flash memory inside your LUT instead of SRAM, or it may have a FLASH storage on-die to contain your design bitstream file to be written to SRAM based LUTs.
The inputs of your LUT logic gate control the multiplexers on the output side of the LUT memory. They select which bit of the LUT memory is connected to the ouptut signal of your overall "logic gate". The bitstream configuration determines if bit 0 contains a 1 value or a 0 value, of bit 1 contains a 1 or 0 value, if bit 2 contains a 1 or 0 value, etc. The multiplexers do not know the contents of the LUT memory, they only connect the desired LUT memory bit to the output wire.
The output of your "logic gate" LUT goes to a flipflop, perhaps directly to more than one if you want to decide between rising edge clocking or falling edge clocking or perhaps other versions of flipflops that have clear or reset controls or not. Another multiplexor will select if the direct LUT output value is the ultimate output here, or if (one of) the flipflop output is the ultimate output of this logic element. If you have clear and/or reset controls on your flipflops, then even more multiplexors are used to select which wire connects to those signals. And even other multiplexors to select which wire connects to the clock of the flipflop, and perhaps if there is an inverter to the clock or not.
The various input bits of your logic gate are connected to multiplexors which make connections to the mass of wire endpoints available to your logic element. Lets say we have a 4-bit SRAM memory as our LUT memory.
To make your logic element (LUT + multiplexors + flipflop) "become" a 2-input AND gate, which has input wires A and B, and output wire D,
multiplexer 1 chooses between bits 0 and 1 of the LUT
multiplexor 2 chooses between bits 2 and 3 of the LUT.
multiplexor 3 chooses between the outputs of multiplexwrs 1 and 2. (I wish I could draw that schematic here)
write a 0 value into bit 0 of your LUT
write a 0 value into bit 1 of your LUT
write a 0 value into bit 2 of your LUT
write a 1 value into bit 3 of your LUT
a fixed 0 value is set to control multiplexor 1, so it is fixed to connect bit 0 to its own output.
select wire A to control multiplexer 2.
select wire B to control multiplexer 3. The inputs to multiplexer 3 are the outputs from multiplexers 1 and 2.
The digital logic truth table for a 2-input AND gate is:
A B | D
0 0 | 0
0 1 | 0
1 0 | 0
1 1 | 1
Multiplexer 1 is fixed to output the value of LUT bit 0.
When wire A is a 1 value input to multiplexer2 1, then it connects bit 3 to the output of multiplexer 1. If wire A is a 0 value, then it connects bit 3 to the output of multiplexer2.
When wire B has a value of 1, it connects multiplexer 2 output to the LUT output wire C. When wire B is a 0 value, then multiplexer 3 connects the output of multiplexer 1 to wire C.
So, if wire B is 0, then the value on wire A is irrelevant. B as a 0 tells multiplexer 3 to pass multiplexer 1 to output wire C, and multiplexer wire can only select LUT bit 0, which is contains value 0. This acrees with our truth table. (we could even set LUT bit 1 to a 1 and the truth table would still be correct, since bit 1 can never get out of multiplexer 1)
If wire B is a 1, then wire A can have an affect as multiplexer 2 is connected to output wire C. If wire A is value 0, then multiplexer connects bit 2 to output wire C, meaning it connects to bit 2 value of 0 to C. If A is value 1, then multiplexer 2 connects bit 3 to output wire C, meaning it is connected to the bit 3 value of 1 to C.
(to be continued)
-
(continued form previous post)
Now, we're at point C, not the AND gate D pin. So where are we exactly? We are at a point before the flipflop, which may or may not be used. And C is actually the value input to the flipflop, and is connected to that. There is another multiplexer, let's call it multiplexer 4, which decides which signal our final D wire connects to. One input of multiplexer 4 is our C wire. The other input to multiplexer 4 is the output of the flipflop, which I'll call wire Q. For our truth table, we do not see anything like a storage element, so we will use multiplexer 4 to connect wire C to final output wire D. Wire Q coming out of the flipflop may still toggle different 1 and 0 values, but it is not connected to anything useful, and so has no noticeable affect on our logic element truth table.
Now, how do we tell multiplexer 1 that it will only ever connect bit 0 and never bit 1? How do we tell multiplexer 2 that it is controlled by wire A instead of by wire G? Or that multiplexer 3 is controlled by wire B? Or that multiplexer 4 will only ever connect wire C to wire D, and never wire Q to wire D? And how do we tell the LUT memory to contain binary value 1000 (ie [bit3,bit2,bit1,bit0])?
This is what the bitstream configuration file does. There are other SRAM memories whose outputs control the multiplexer selections. The bits of these "configuration memories" go to the select control signals on even other multiplexers. The inputs of these multiplexers are wires A, B, G, Z, W, etc. and also a fixed 1 value and a fixed 0 value, from each direction that wires come from on the chip. And one each for every input to the LUT (remember, these LUT inputs control multiplexers 1 2 and 3 for this example) And for each A, B, G, Z, W wire coning from direction N, there is a multiplexer to select which one of those sets (ie. the top side set, the bottom side set, the right side or left side set version of wire A here)
The outputs of these multiplexers are the control wires connected to multiplexers 1, 2, 3, 4, and anything else that might be in there. If you want wire A from the left side set, then you have a left side multiplexer selecting A, and you have another multiplexer selecting left side, so this signal goes through two multiplexers in order to connect to the select control on multiplexer 2 in our example. One configuration memory will tell left side multiplexer to choose A, and another configuration memory will tell the side multiplexer to choose left side. (The FPGAs I did layout for had 8-sided elements as things came diagonally as well as orthoginally.) And of course you have another chain of multiplexers to get top side wire B as the B input to our AND gate.
And the LUT memory value is written in at configuration time, same as when the other "configuration memories" are written to.
If you are not doing reconfiguration, then your design is fixed until power is lost. The configuration memory values do not change. The LUT memory values do not change. You've set your LUT to be your desired truth table, and you've set all those lots and lots of multiplexers to connect the wires how you want them connected, and now it's just an AND gate with two wires coming in and one wire going out.
The reason an ASIC will perform better than an FPGA is, well, an ASIC only needs three wires and six transistors to make an AND gate. (Ignoring the wires inside the AND gate itself to connect up those four transistors) The FPGA implementation of the AND gate has 4 big multiplexers to get A and B to the logic gate. It has two levels of multiplexers to get the desired truth table logic value on a wire, and a third level of multiplexer to say we do not want a flipflop involved. That's 5 levels of multiplexers, compared to ASIC's one level of exact AND gate. The configuration memories are static values, and they do not affect timing or performance through here. But they do take up a lot of space. As do all those multiplexers and that LUT. That's how an ASIC die can hold so much more logic than an FPGA die of the same size.
A lot of FPGA chips today are SRAM based LUT design. Not all are though. Some are antifuse, which is a permanent configuration. But other than the method to store the configuration (both LUT and multiplexer etc. selections), there's not a lot different between the two styles.
Hopefully I didn't typo anything. Let me know if there are any questions. Discuss...
-
An FPGA emulates a circuit, because while the components are fixed, it's wiring is not, and therefore the circuit isn't fixed. It imitates a circuit's function by providing user definable wiring. Wires are part of a circuit, and these aren't fixed here.
Does it make a difference that, for the duration of being powered on and after writing the bitstream into the FPGA configuration memories, that the wiring and everything IS fixed until you power it off?
(ignore reconfiguration for now, as Minimig does not, the bus and memory controller on CSPPC does not, Prometheus PCI bridge, etc does not do this)
-
An FPGA just removes a layer of abstraction, otherwise it's largely the same.
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.
-
These lookup tables are similar to SRAMs, and this is why FPGA contents is volatile.
Please discuss this detail in reference to antifuse based FPGAs.
-
The FPGA isn't a 68K chip, it's emulating one. A different FPGA emulates the custom chips. Amiga OS runs on top of this emulated hardware. UAE emulates a 68K in a program, this same program emulates the custom chips. Amiga OS runs on top of this emulated hardware.
And an A4000 is an emulation of a A1000 with some extensions added :)
Staf.
-
And there we have it: Lookup tables. This means there's no physical chip, which means it's an emulation (imitation).
Crack open my FPGA chip and put the die under a microscope. I'll point to the lookup tables. I'll point to the die. I challenge you to prove that neither is where I'm pointing to. An empty package wouldn't make a very good component for your [insert final product PCB here]...
Or perhaps it's about the meaning of the word 'emulation' being interpreted in different ways.
I think you're right there. It seems my definition of "implementation" and your definition of "emulation" are stepping on each other.
-
Please discuss this detail in reference to antifuse based FPGAs.
I just mentioned SRAM-based devices because one of the posters used this to support his/her claim about FPGAs being an emulation of "real" hardware, due to their volatile nature. There are of course other non-volatile technologies as well. Apart from this I don't know what kind of answer you're fishing for here :)
-
And there we have it: Lookup tables. This means there's no physical chip, which means it's an emulation (imitation). Or perhaps it's about the meaning of the word 'emulation' being interpreted in different ways.
Now some more philosophical questions.
By your definition most of the routing on the internet is done through emulation; or does one think Xilinx makes >$1k FPGAs for the hobbyists around here ?
Given that most of these designs will never be put in an ASIC what are they then actually emulating ?
Most of PCB designs are often done first with some parts done in programmable hardware and then later when it is really succesful a cost reduced version is made with the programmable part replaced with an ASIC. This means that an ASIC is emulation.
I am looking forward to the discussion ... ;)
greets,
Staf.
PS: I think there is an all explaining theory which doesn't conflict with anybody's view here. Try to find it !
-
I just mentioned SRAM-based devices because one of the posters used this to support his/her claim about FPGAs being an emulation of "real" hardware, due to their volatile nature. There are of course other non-volatile technologies as well. Apart from this I don't know what kind of answer you're fishing for here :)
I may have clicked reply to your message containing the original comment, rather than going in search of the original comment post to click reply to that. Mine was in response to those using SRAM as the basis of their emulation definition. If you're not that guy, sorry I got the reply wrong. Actually, i may have copy/pasted the wrong thing even. I swear I was pasting something that was more overtly SRAM == emulation than my post you refer to. Sorry, don't know how I did that.
To whoever does make the SRAM == emulation claim,
Does the lack of an SRAM in an antifuse FPGA make it less of an emulation than an SRAM FPGA, when everything other than the storage medium is pretty much the same thing?
(A blank antifuse FPGA has the potential to be just about anything. But once programmed, it really is fixed. If you want to change it, you throw that chip in the trash and buy a new blank to put the changed design into. Kindof like how some of us were changing chips on our PicassoIV graphics cards way back when)
-
So for something to be 'real' and not emulated, it must be hardwired in a permanent form onto a silicon chip? If that's the criteria we're to use, then what does that make the original Amiga 1000? After all, the ROM for the A1000 had to be soft-loaded from floppy disk - it didn't exist in a permanent chip form!
No, not in this case, because it doesn't matter in what kind of memory a program is stored, as long as the CPU can fetch the instructions from it.
Does it make a difference that, for the duration of being powered on and after writing the bitstream into the FPGA configuration memories, that the wiring and everything IS fixed until you power it off?
Yes, it matters, because it can still be changed in a highly flexible manner each time you turn it on. It's all about the changeability.
Crack open my FPGA chip and put the die under a microscope. I'll point to the lookup tables. I'll point to the die. I challenge you to prove that neither is where I'm pointing to. An empty package wouldn't make a very good component for your [insert final product PCB here]...
Sure, but you can't point to any wiring, because it doesn't exist (except for the parts that make the FPGA work as an FPGA).
I think you're right there. It seems my definition of "implementation" and your definition of "emulation" are stepping on each other.
That sounds about right.
By your definition most of the routing on the internet is done through emulation; or does one think Xilinx makes >$1k FPGAs for the hobbyists around here ?
Why not? Does it matter? Only the problem of sending information around has to be solved, and as long as it's done in a convenient way that's also efficient, then it just doesn't matter.
Given that most of these designs will never be put in an ASIC what are they then actually emulating ?
Devices that don't exist completely physically.
Most of PCB designs are often done first with some parts done in programmable hardware and then later when it is really succesful a cost reduced version is made with the programmable part replaced with an ASIC. This means that an ASIC is emulation.
Yes, it does. Until the circuit is physically built using wires, like in CPUs, it can be said to be an imitation of that actual circuit.
From what I've read in th thread, I've also noticed how the gate building blocks in an FPGA use more transistors than you'd actually need in a full, non-Asic, hard implementation, or am I wrong here? If I'm not, then that would mean that if you actually implemented a circuit the hard way, you'd end up using fewer transistors than then the FPGA equivalent. Sounds like an imitation to me.
-
Sure, but you can't point to any wiring, because it doesn't exist (except for the parts that make the FPGA work as an FPGA).
Sure I can. There's a LOT of wires in there which are not part of the FPGA configuration controls. They exist only to get a signal from an output over here to an input over there. When not configured, they are floating, not connected to anything. The FPGA place and rout tool knows exactly which bits of metal are conducting each and every signal in YOUR design. The PnR tool looks at teh gates netlist for your design, and decides which bits of metal real life to connect to each other to carry YOUR signals around. There are tools for humans to see these connections and stuff too, but they tend to live only inside FPGA companies for fear that a competitor will reverse engineer their FPGA silicon design with such knowledge. If I had that tool, then we could sit down with a microscope and point to each and every bit of metal on the die that carries each and ever signal you design into it. Very real wires, very real metal atoms, very real electrons moving around in them. There aren't any ghosts lurking around in these things... Do you think that the LUTS talk to each other by telepathy or something? They need wires, very very real-life wires.
-
Yes, it does. Until the circuit is physically built using wires, like in CPUs, it can be said to be an imitation of that actual circuit.
How do you feel about breadboards, a pile of 74* logic chips, and a bag of wire?
-
Is it not possible that this it is in the middle? Is it between Emulation and Implementation?
emulation -> fpga -> asic(implementation)
-
Sure I can. There's a LOT of wires in there which are not part of the FPGA configuration controls.
Yes, but these wires are electronically connected and not directly, that's really what I meant, my bad.
When not configured, they are floating, not connected to anything.
Exactly. In a fixed circuit the wires go directly from one component to the next.
There aren't any ghosts lurking around in these things... Do you think that the LUTS talk to each other by telepathy or something? They need wires, very very real-life wires.
Ha ha, of course there's no magic involved (if only :)), but the connections still aren't hard, like in a CPU.
-
From what I've read in th thread, I've also noticed how the gate building blocks in an FPGA use more transistors than you'd actually need in a full, non-Asic, hard implementation, or am I wrong here? If I'm not, then that would mean that if you actually implemented a circuit the hard way, you'd end up using fewer transistors than then the FPGA equivalent.
There is a lot of overhead to make an FPGA be so versatile, yes. You might be able to fit 100 ASIC AND gates in the same space as one FPGA logic element takes. The LUT can do more complicated stuff than an AND gate though, and can serve as a handful of different combinatorial gates together, but ASIC would still be smaller.
I guess part of the debate here is "what does al that stuff actually do" in the FPGA when the design is running, and does or does not that define emulation. You and a couple others see the result as soemthing "pretending to be" X, while I and a coupel others see something "being X, but not pretending".
-
How do you feel about breadboards, a pile of 74* logic chips, and a bag of wire?
Not the same. A bag of wires isn't the same as a lookup table, but enables you to build the actual circuit completely physically.
In essence, the lookup tables could be said to tell the FPGA the connection points for the wires (so to speak). The FPGA then electronically connects the wires to those points (so to speak). With a breadboard the connection is completely mechanical, and that makes the big difference.
-
Yes, but these wires are electronically connected and not directly, that's really what I meant, my bad.
Quote:
Originally Posted by billt View Post
When not configured, they are floating, not connected to anything.
Exactly. In a fixed circuit the wires go directly from one component to the next.
OK, how about this. All those wires do actually connect multiplexers and/or passgates together. wire to transistor to wire to transistor and so on. The place and route tool chooses which metal wires to use for which signals in your design, and tells the passgates and multiplexers to make that path connection between the chosen bits of metal.
Now, consider the memory controller in an 8640 PPC processor, which is "fixed" enough for you, and I imagine that the memory chips are too. There are two memory channels. There are several banks (DIMM slots) per channel. When the processor wants to access a particular memory location, there are multiplexers to choose which channel it talks to, and passgates in the RAM chips to make sure only the correct one talks back on the bus. Passgates and multiplexers...
And, on a motherboard, you may have several PCI-Express slots. These are not connected to each other, they are a separate channel each. The Northbridge chip looks at the address the processor wants to read from, and demultiplexes the access down the corret channel to its peripheral destination. The response comes back, and the Northbridge now multiplexes this response onto the north bus to the CPU. Again, multiplexors, not some unshared, only this and nothing else goes there pathway segment. If I change which slots my different PCI-Express cards are plugged into, I have at he next powerup reconfigured my system design, the processor and northbridge need to use a different path to send the same request and get the same response. Is my PC emulating the idea of being a PC? Or is it simply just being a PC?
-
I guess part of the debate here is "what does al that stuff actually do" in the FPGA when the design is running, and does or does not that define emulation.
Exactly. In an emulation there's all kinds of things happening in the background to just to enable to make what is being emulated work. The real thing doesn't require any of this overhead at all.
It's like a software emulation: An emulated computer needs a computer and software, while the actual computer works fine by itself.
-
In essence, the lookup tables could be said to tell the FPGA the connection points for the wires (so to speak). The FPGA then electronically connects the wires to those points (so to speak). With a breadboard the connection is completely mechanical, and that makes the big difference.
The LUT does not do that. The Configuration memories tell the muxes which connections to make. The LUT stores/implements your logic truth table , and has no knowledge of or influence on the wire connections or control of anything.
-
Exactly. In an emulation there's all kinds of things happening in the background to just to enable to make what is being emulated work. The real thing doesn't require any of this overhead at all.
It's like a software emulation: An emulated computer needs a computer and software, while the actual computer works fine by itself.
Hmmm. What do you think is "happening" in the background of an FPGA design? Once it's configured, all that is fixed. Configuration 1's stay 1's, and configuration 0's stay 0's. The configuration memories to not change. There is no controller going down the address bus doing read or write accesses, not changing any values. The multiplexer settings which control the signal routing are fixed, they do not change and move wire connections around while the system is on. There's overhead stuff "present" and taking up space, but it's not "doing anything", or "nothing is happening there". It's "just there" at that point.
In an ASIC, does it make a difference if I use a library cell carrying the name D flipflop which serves the function of a D flipflop, or if I do an ECO design change, have no empty spaces to put another "real" D flipflop library cell that I somehow forgot, and have to combine a handful of NAND gates that I do have room for here and there, in order to effect a D flipflop function instead? Or, oh crap, that NAND gate should have been an AND gate. The AND (6 transistors) is too big to directly replace the NAND gate (4 transistors), but I have room over there for an inverter. Do a NAND plus an inverter emulate an AND gate, or implement it in an ASIC?
It's like a software emulation: An emulated computer needs a computer and software, while the actual computer works fine by itself.
An emulated computer needs software. Some group of instructions that are continuously fetched from one of several types/levels of storage somewhere, decoded, ALUed, reading values from parameters and writing values to register or memory destinations, in order to effect the target opcode format, ALU, instruction decode, registers, memory map, etc. In what way do you think this activity is continuously occurring in the FPGA underneath your logic circuit?
And another thought about "fixing" an FPGA. We'd once looked into but never sold a metal mask fixation option for our FPGAs, which would replace the configuration SRAMS and the LUT memory with metal hardwired 1's and 0's, should a security concerned customer want to do that to get a fixed die design instead of going through the effort of ASIC conversion. If I had a Minimig core designed to work well in my FPGA, and I did this metal mask replecement, most of the die is the same as the reprogammable FPGA, all those multiplexors are still there exactly the same way, but I can no longer change their controls, have I de-emulaterified this metal hardwired thing?
-
The LUT does not do that. The Configuration memories tell the muxes which connections to make. The LUT stores/implements your logic truth table , and has no knowledge of or influence on the wire connections or control of anything.
Sorry for being an obvious layman here. It should still be true that you store data in the FPGA that configures the wiring, though?
The point is that you don't have, say, two transistors which are directly, mechanically connected (such as using a printed circuit board that's custom made, which the components are soldered onto). In an FPGA you have configurable components in between the wires (or am I missing something again?).
-
The point is that you don't have, say, two transistors which are directly, mechanically connected (such as using a printed circuit board that's custom made, which the components are soldered onto). In an FPGA you have configurable components in between the wires (or am I missing something again?).
Thorham, what about CPLDs and ASICs. Are those also considered emulations of the real thing? I mean, in a CPLD, you don't have, say, two transistors which are directly, mechanically connected (such as using a printed circuit board that's custom made, which the components are soldered onto).
-
OK, how about this. All those wires do actually connect multiplexers and/or passgates together. wire to transistor to wire to transistor and so on.
Sure, but don't those components connect the wires electronically? In a hard implementation of the same circuit, you'd leave those extra components out.
Now, consider the memory controller in an 8640 PPC processor, which is "fixed" enough for you, and I imagine that the memory chips are too. There are two memory channels. There are several banks (DIMM slots) per channel. When the processor wants to access a particular memory location, there are multiplexers to choose which channel it talks to, and passgates in the RAM chips to make sure only the correct one talks back on the bus. Passgates and multiplexers...
Here those same components aren't extra components that you can leave out, because they are part of the circuit design. If you'd do such a design in an FPGA, you'd end up using more of said components then are needed by the actual circuit itself.
-
Hmmm. What do you think is "happening" in the background of an FPGA design? Once it's configured, all that is fixed. Configuration 1's stay 1's, and configuration 0's stay 0's.
Don't have a clue, but the fact that there is a background in the first place is what matters. For a circuit in an FPGA to work, extra components are needed, and whether they are as active as a software emulation or not isn't important.
In an ASIC, does it make a difference if I use a library cell carrying the name D flipflop which serves the function of a D flipflop, or if I do an ECO design change, have no empty spaces to put another "real" D flipflop library cell that I somehow forgot, and have to combine a handful of NAND gates that I do have room for here and there, in order to effect a D flipflop function instead? Or, oh crap, that NAND gate should have been an AND gate. The AND (6 transistors) is too big to directly replace the NAND gate (4 transistors), but I have room over there for an inverter.
Can't say much about ASICs, but if they have overhead components needed for a circuit to work, while those components aren't part of the circuit design, then perhaps an ASIC is an emulation as well.
Do a NAND plus an inverter emulate an AND gate, or implement it in an ASIC?
Well, you can do an AND gate using a single relay or two transistors. Using two components made of transistors to make another that can actually be made of fewer transistors seems like imitating the behavior of that made part.
An emulated computer needs software. Some group of instructions that are continuously fetched from one of several types/levels of storage somewhere, decoded, ALUed, reading values from parameters and writing values to register or memory destinations, in order to effect the target opcode format, ALU, instruction decode, registers, memory map, etc. In what way do you think this activity is continuously occurring in the FPGA underneath your logic circuit?
In that way? Not at all. Don't ask me how it does work, but it should be obvious that FPGAs and computers do things very differently.
And another thought about "fixing" an FPGA. We'd once looked into but never sold a metal mask fixation option for our FPGAs, which would replace the configuration SRAMS and the LUT memory with metal hardwired 1's and 0's, should a security concerned customer want to do that to get a fixed die design instead of going through the effort of ASIC conversion. If I had a Minimig core designed to work well in my FPGA, and I did this metal mask replecement, most of the die is the same as the reprogammable FPGA, all those multiplexors are still there exactly the same way, but I can no longer change their controls, have I de-emulaterified this metal hardwired thing?
No, because there are more parts to replace with metal than just the SRAMS and LUT memory.
Thorham, what about CPLDs and ASICs. Are those also considered emulations of the real thing? I mean, in a CPLD, you don't have, say, two transistors which are directly, mechanically connected (such as using a printed circuit board that's custom made, which the components are soldered onto).
Don't know about CPLDs, but in general, if you have a programmable device in which you can make a circuit design actually work, then it's an emulation (also because of extra components needed which aren't part of the design).
-
Well, you can do an AND gate using a single relay or two transistors. Using two components made of transistors to make another that can actually be made of fewer transistors seems like imitating the behavior of that made part.
So the ULA chip in Spectrum was "emulating" all other gates different from the basic type available?!? :rolleyes:
-
So the ULA chip in Spectrum was "emulating" all other gates different from the basic type available?!? :rolleyes:
Ha ha, you're right, that's taking it a little far. It's just some purist style thinking, perhaps.
-
Given that most of these designs will never be put in an ASIC what are they then actually emulating ?
Devices that don't exist completely physically.
I have to admit you have some weird definition of emulation. And I can only agree with your definition if you also consider MS Word running in Windows a simulation of a (virtual) fully mechanical machine doing the same thing.
I think this is the base of the misunderstanding. You claim that soft-wired circuits == emulation, hard-wired circuits == no emulation.
So then you also have to claim software == simulation, hardware == no simulation.
I, and probably most people, would claim that hard-wired circuits can still be emulation of another device, e.g, the C64 in a joystick of Jeri Ellsworth, and soft-wired circuits can be unique designs not emulating anything. Hardwired/programmable devices are just two terms orthogonal to emulation/no emulation.
greets,
Staf.
-
Sorry for being an obvious layman here. It should still be true that you store data in the FPGA that configures the wiring, though?
The point is that you don't have, say, two transistors which are directly, mechanically connected (such as using a printed circuit board that's custom made, which the components are soldered onto). In an FPGA you have configurable components in between the wires (or am I missing something again?).
The LUT is a connection point to a route. It has an output that goes to some other LUT's input. (Or to an IO pin outside the chip) The LUT input is a connection point routed to some other LUT's output, or coming into a chip IO pin. Every wire has a contact (same purpose as a via, but specific name for a connection between metal and poly (transistor gate) or metal and active (transistor source or drain) or likely several contacts to various transistors at each end.
Every wire touches a transistor at each end. At least two on each end (a PFET and an NFET, maybe more than one of each). Every wire has to connect to SOMETHING, or there's no reason for it to be there. (Not completely true, but I won't go into the reasons for planarization fill metal, it has nothing to do with routing or functionality of any kind of chip, it's a manufacturing reliability thing)
The passgates and multiplexers may come from the sale cell library that an ASIC uses. When I started doing this for FPGAs as my daily job 13 years ago (will be in a few weeks), we had a full custom library especially for the FPGAs, in order to pack everything as small and tight together as possible. The last few FPGA chips we designed we moved to using the standard ASIC library, instead of anything custom. We were then using ASIC passgates and ASIC muxes at the ends of our routing wires. The FPGA itself, for all intents and purposes, was an ASIC chip.
-
Don't have a clue, ...
Don't ask me how it does work, ...
Don't know about CPLDs,
...
Sorry for being an obvious layman here....
Thanks for trying to correct those of who do the topic of this thread every day for over a decade. :)
-
Don't know about CPLDs, but in general, if you have a programmable device in which you can make a circuit design actually work, then it's an emulation (also because of extra components needed which aren't part of the design).
So... by definition it's emulating... what exactly? A (fairly large) bunch of 74-circuits? Transistors? I have a different theory: it implements a logic function. That logic function could be implemented in other ways as well. The technology used to implement that logic function has no impact on functionality whatsoever as long as the technology is able to sustain timing requirements etc.
-
Thanks for trying to correct those of who do the topic of this thread every day for over a decade. :)
There are no shortage of members here that like to post messages on how things work, when they have almost zero experience or knowledge on the topic. I think I have even jumped into a thread or two to offer an opinion when I really should not have. Something I didn't really know anything about, but just had to post an opinion on. Just human nature when a thread is really interesting and we want to add our 2 cents.
Unfortunately, some people get so sucked into an argument and trying to express their opinions, they won't stop even after they realize they don't know what they are writing about. These are the guys I don't understand. I guess they just like to hear the sound of their own voices.
-
Well, it is interesting to see that some people do see this as a gray area for definition, or that the way an FPGA does what it does is something other than a genuine method of "implementation". I've been fixed on how I see this for a long time for very technical reasons. People on the other side I imagine have felt their way for a long time too. Both sides are having trouble grasping way people on the other feel the way they do, for whatever reasons that is. It's interesting to try and see this through someone else's eyes who have a different experience with it all.
-
Thanks for trying to correct those of who do the topic of this thread every day for over a decade. :)
Just trying to get the emulation point across. If I made it look as if I was trying to argue over the functioning of an FPGA, then that wasn't my intention at all.
I have to admit you have some weird definition of emulation. And I can only agree with your definition if you also consider MS Word running in Windows a simulation of a (virtual) fully mechanical machine doing the same thing.
I think this is the base of the misunderstanding. You claim that soft-wired circuits == emulation, hard-wired circuits == no emulation.
So then you also have to claim software == simulation, hardware == no simulation.
I hadn't thought of that, but it sounds good to me. A program is just a fully functioning model of a data processing system, where the physical implementation is undefined.
I, and probably most people, would claim that hard-wired circuits can still be emulation of another device, e.g, the C64 in a joystick of Jeri Ellsworth
If it's not the original chipset, then yes.
There are no shortage of members here that like to post messages on how things work, when they have almost zero experience or knowledge on the topic.
And what does any of this have to do with what emulation is? Because that's what it boils down to.
You can ask this question about hardware (where my layman level doesn't help), and as someone has shown, you can ask it about software, as well.
It's not about the details of how an FPGA or whatever programmable chip works, it's about the fact that it's programmable, anything else just gets in the way.
-
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.
-
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.
-
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
-
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).
The similarities between what has been done with FPGA's and what has been done with software emulation stems from in both cases the original logic definitions were NOT available and so had to be reverse engineered and re-created (often with mistakes due to largely undocumented features.)
-
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.
-
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.
It actually wouldn't matter... You could call it a purple teapot and claim that it orbits the sun somewhere between mars and Jupiter...
I fact how would you know if Freescale sold you a 68k, which worked fine in your A500... Was either an ASIC or an FPGA?
-
If it's not the original chipset, then yes.
Is Super Buster rev 11 then an emulation of Super Buster rev 1 because it wasn't the first? Is 6582 an emulator of the 6581? Is 68060 mask 1e41j an emulator of 68060 mask 1F43G?
If Tramiel's Commodore had put the C64 into a single chip, would it be less of an emulator than Jeri's single chip?
-
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.
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?
-
I didn't say FPGA's were essentially CPU's, just that they have alot in common.
I very strongly disagree with that.
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.
OK, pick the most similar FPGA and CPU pair out there, and describe the details that make them so similar.
They both take a program, although VHDL/Verilog have more in common with with functional programming languages than older langues like C.
An FPGA does NOT take a program. The bitstream data is essentially a netlist. A software executable is absolutely not essentially a netlist.
In Verilog:
assign mux_out = mux_select ? input_1 : input 0;
Is one way to write a multiplexor gate. This is the same as connecting three wires to a mux symbol in a schematic drawing. no difference whatsoever, and the synthesis tool will give you a mux gate from teh cell library, just like it would from a schematic. This verilog code needs about four transistors, two input wires, and one output wire to exist in the real world.
In C:
mux_out = mux_select ? input_1 : input_0;
let's say I compiled that on my XE, which is a 32bit CPU. mux_out, mux_select, input_1, and input_0 a re each a 32bit value. If they are all in CPU registers, that is 32 * 4 = 128 flipflops, and each flipflop is maybe a dozen transistors. Then we need a 32bit comparator to choose which of the inputs goes into our result, and a 32 2:1 muxes (can be done in transistors each) to bring the correct input value back to the result register. We need an opcode to tell the thing that we want to do a comparison, we need opcodes to load in the instruction opcode and to load in the input_1 and input_0 values, we need a decoder to determine that the instruction opcode we fetched says to do a comparison, we need a clock to drive the state machines and to latch values into the register flipflops.
Call me goofy if you like, but I do find it difficult to equate those two situations to each other.
Think http://en.wikipedia.org/wiki/Concurrent_computing with a couple of million cpu's.
That implies that there is a couple of million processing entities, each continuously running through sequences of commands telling it what to do, after the program is loaded. Each proccessing entity is doing fetches, decodes, ALUs, register reads and writes, etc. In an FPGA, after you load the design, the stuff that makes up the FPGA itself goes static, it is fixed until you turn it off. There are no fetches, decodes, ALUs, registers being read and written to, etc. (Reconfiguration while the system is running is a significant operation, takes significant time, and really should only be used to INFREQUENTLY swap between very different modes that do not have any dependencies on each other, and it really is a recent phenomena. FPGAs that could do it long ago weren't used that way, or very very rarely.)
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.
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 use Verilog where I work, but same thing. If someone were to make a TG68 ASIC, the VHDL we already know about is synthesized into a gates netlist, and the ASIC place/route tool uses silicon cells from a library and puts them together to draw the die. It's pretty uncommon to design digital chips any other way than VHDL or Verilog today. Schematics are antiquated for digital, though they are still relevant for analog silicon. There's analog extensions to VHDL and Verilog though, and they'll take over at some point.
You can also license the VHDL or Verilog. That's what ARM does for example. They license their HDL code. TI, ST, Atmel, and all the others are using the same HDL code written by ARM. They add different peripherals to it, choose the fab tech they want to build it in, to try and make their product uniquely useful for a certain market, but a CoretexM4 is a CoretexM4 is a CoretexM4... AppliedMciro licenses the PowerPC core from IBM, that's IBM's VHDL code (or Verilog, whichever is the case). PA Semi did make their own new implementation of the PowerPC instruction set, and had no intention of trying to clone any existing PPC processor core, they worked from the instruction set spec with a different philosophy (minimize power consumption at the target performance level, compared to IBM's really freakin hot G5 design), the same doc an assembly programmer would learn assembly language programming from. Is the X1000 a PowerPC computer, or a simulation or emulation of a PowerPC computer?
-
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.
-
Is Super Buster rev 11 then an emulation of Super Buster rev 1 because it wasn't the first? Is 6582 an emulator of the 6581? Is 68060 mask 1e41j an emulator of 68060 mask 1F43G?
If Tramiel's Commodore had put the C64 into a single chip, would it be less of an emulator than Jeri's single chip?
That's a good point. Perhaps that is pushing it, but this is a gray area, as you said.
-
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.
From what I've learned from my arguing, this is not the case at all.
As you know, when writing a program in a higher level language than assembly language, you compile the program to an assembler program, and this is assembled into a binary containing the machine code instructions.
With VHDL, the program isn't translated into something like machine code at all. There is no program of any kind running on the FPGA, and although the VHDL has to be translated, it's translated into something completely different than what an assembler program would be translated into to.
While it's true that the basic idea is the same, namely programmability, FPGAs and CPUs achieve this is fundamentally entirely different ways. The word 'programmable' doesn't necessarily imply 'program'.
-
I didn't say software was a netlist, but VHDL is a programming language. It even mentions it on ...
If VHDL is a programming language then what you write is a program.
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)
When you are coding in VHDL or Verilog, you are not writing a program. You are writing a circuit. You do not "call" a module, you "connect to it". Modules and leaf/library cells connected in your code ARE A NETLIST.
An FPGA is more efficient than using software on a CPU, but it's essentially doing the same thing.
No, they are not essentially doing the same thing. I say that as someone who knows how they both work on a highly technical level, and thus how they both do things, and how those two ways are not comparable. If you believe that FPGA architecture is so similar to microprocessor architecture that they essentially do the same thing, and you are not willing to learn the technical stuff about them, how they are made, or what is happening inside them, then this debate is highly flawed.
We're talking Amiga custom chips here, which predate VHDL by a long shot.
VHDL was defined in 1981. It's evolved since then, but... I remember seeing something about the Amiga chip guys using an HDL named M, I think from Mentor Graphics (a leading vendor in chip design tools for a very long time). If we had the M code, then same thing. Maybe this was regarding Hombre, I don't remember for sure.
And we're not talking Amiga custom chips to the exclusion of anything else here. This thread talks about a lot of different kinds of chips.
-
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.
-
http://en.wikipedia.org/wiki/Hardware_description_language
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.
Well, the C64 was likely a schematic diagram design. That schematic diagram surely had digital logic gates all over the place. Those schematic gate symbols and the wires drawn between them CAH indeed be directly mapped to VHDL or Verilog, as both of these languages, as a subset of their features, are netlist languages. (They are of course a lot more than simply netlist languages, but that is one capability amongst those many others)
For that analog componetns, surely there re schematics with those as well. verilog-A and -AMS is the "Analog Verilog" (AMS is both analog and digital Mixed together), and VHDL-AMS is the analog VHDL. Someone knows how those analog schematic symbols behave, which is why those particular symbols and characteristics are there instead of other ones. This knowledge means that yes, someone can write those analog schematics in Verilog-AMS or VHDL-AMS. So yes, it is possible to make an exact 1:1 implementation of the Commodore64 (or any other schematics) in these HDL languages.
If the analog components are not available on an FPGA, and they likely are not, then, yea, a 1:1 in FPGA isn't what you'll get. I can imagine a programmable analog chip, I'm not sure if such a thing exists for sale or not. Combine such a thing with an FPGA on the same die, then there you go. But I don't know that this is anything more than a hypothetical device.
-
So why is this important again?
As I understand it an FPGA is a simulation or mock up of hardware, there is both a hardware and software component whilst with UAE is a pure software solution. Further FPGA could easily be made into a hardware solution (but not at all likely in this case). They represent opposite ends of the emulation spectrum.
-
As I understand it an FPGA is a simulation or mock up of hardware, there is both a hardware and software component
The software part is actually the design software, such as a VHDL system. There's no actual software running on the FPGA at all. There is a 'soft' side on FPGAs, but it's not a program. FPGA programming can't be compared to CPU programming at all.
-
thread:
So lets build a x86pc core for the Replay, then run UAE on it. What's that... simulation or emulation. ;-)
-
thread:
So lets build a x86pc core for the Replay, then run UAE on it. What's that... simulation or emulation. ;-)
You know, I rather think that's a fun idea :)
-
You know, I rather think that's a fun idea :)
Reminds me of back when I worked in an Amiga store and showed off by running AmigaDOS, Mac 68k, and msDOS simultaneously. ;D
-
Done it - but couldn't get a screen grabber to work ...
-
thread:
So lets build a x86pc core for the Replay, then run UAE on it. What's that... simulation or emulation. ;-)
That's a waste of time and money. It defeats the entire purpose of the Replay board which is to inexpensively recreate in hardware the classic Amigas that are so hard to come by anymore these days.
-
The same could be said about x86-pc with VGA boards and the demos coded in assembler for them. It's just to load a different bitfile into the FPGA so it doesn't lessen the original objective.
-
That's a waste of time and money. It defeats the entire purpose of the Replay board which is to inexpensively recreate in hardware the classic Amigas that are so hard to come by anymore these days.
That is not the entire purpose of the Replay board.
-
That is not the entire purpose of the Replay board.
As far as classic Amigas are concerned, it is.
And I'm well aware of the other systems that the Replay board is designed to replace, such as Ataris and various arcade boards thank you very much.
-
That's a waste of time and money. It defeats the entire purpose of the Replay board which is to inexpensively recreate in hardware the classic Amigas that are so hard to come by anymore these days.
Didya miss the smiley at the end of that comment? I was mocking the more pedantic folk in this thread... What do do when faced with a synthesized PC running an emulated computer. OK, maybe not the funniest gag... but that's my emulated sense of humor. :-)
-
Didya miss the smiley at the end of that comment? I was mocking the more pedantic folk in this thread... What do do when faced with a synthesized PC running an emulated computer. OK, maybe not the funniest gag... but that's my emulated sense of humor. :-)
Sorry. Missed your smiley earlier. Humor noted :-)
I do want to add that I'm very impressed with billt's patience here. He's almost written a dissertation on FPGAs here. Very unimpressed by those who insist on arguing with him.
-
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.
-
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.
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).
-
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).
-
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.
-
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.
-
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.
I meant to say that FPGAs in general are "it" as far as recreating classic Amigas are concerned. It isn't like anyone will start manufacturing classic systems or parts for them again. So FPGA based systems such as the Minimig, Replay and Natami are the only alternatives out there for people who can't get their hands on classic systems.
I know that Mike's Replay board didn't originally start out as a classic Amiga recreation project, but that's the beauty of FPGAs. They're versatile enough to recreate just about any system that you can define in VHDL.
-
I do want to add that I'm very impressed with billt's patience here. He's almost written a dissertation on FPGAs here. Very unimpressed by those who insist on arguing with him.
Same here... I've been wanting to get one of the dev boards out there and learn some VHDL. So listening to people with actual real-world experience with the tech is helpful.
-
I do want to add that I'm very impressed with billt's patience here. He's almost written a dissertation on FPGAs here. Very unimpressed by those who insist on arguing with him.
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.
-
There's some real good experts on FPGA here. Please listen to them..
The amount of persistence of unknowledge is amazing ;)
FPGAs differ from an ordinary CPU and other circuits in so many ways that you will have to rethink most assumptions.
-
There's some real good experts on FPGA here. Please listen to them..
The amount of persistence of unknowledge is amazing ;)
FPGAs differ from an ordinary CPU and other circuits in so many ways that you will have to rethink most assumptions.
Except for the notion that FPGAs emulate circuits.
The same can even be said for software: A program is a model of an information processing system whose physical implementation is undefined. Don't know how to say it properly about FPGAs, though (layman level).
-
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.
-
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.
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 know that the XMOS chips are programmed using the C programming language, or what they call XC, which I understand to be the C programming language with specific "X" extensions to it. This differs with FPGA that use VHDL, or Verilog to program the gates in the FPGA.
Maybe someone here can explain in "Layman" terms that everyone can understand, what some of the differences are between FPGA and XMOS chips.
Now that I am getting an X1000, I have become more interested in learning more about XMOS and what they are doing and what is possible to accomplish with the XMOS chip and Xena slot that has been provided on the X1000. There are some very interesting videos on their site, but I am still in need of more understanding of what XMOS is and what might be possible with it in the future.
I know a lot of people have criticized the inclusion of the XMOS chip as a gimmick on the X1000, but I don't see it that way at all. I see it as a real opportunity for some innovation to occur in the near future and a possibility for some creative person to write software that will allow the X1000 and OS4 stand out from the mundane crowd of Windows PC's.
It is potential that can be tapped, or it can be just a useless addition to the X1000, but after looking at the XMOS site more, I am excited about the potential uses in the future. I have always been interested in computer control of household devices, like lighting, automated use of other electronic devices, environment control, such as heating and cooling systems, and many other similar ideas. The X1000 with the XMOS chip appears to be ideally suited to such control software.
-
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.
-
Maybe someone here can explain in "Layman" terms that everyone can understand, what some of the differences are between FPGA and XMOS 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.
You can read about it on the XMOS site, which says XMOS chips combine the functionality of CPUs, FPGAs and some other technologies.
-
If it's just a combination of already established technologies, it might be less confusing to not include it in the discussion ;)
-
If I made a parallel switch emulator, where you have two kinds of switches (normal and inverted), that behave like relays and have four pins, then how difficult would it be to translate such virtual circuitry to FPGA circuitry?
The emulation doesn't emulate electricity and simply uses 0 and 1 as signals, and signals are never amplified in any way.
-
My roof lamp emulates light..
-
Very informative thread once a guy sorts out the arguing and dick waving, hehe.
Didn't know a heck of a lot about FPGA implementations before this read.
-
Since there were so many members here and elsewhere that were so quick to jump at criticizing A-Eon and Varisys's decision to include the XMOS chip on the Nemo motherboard for the X1000, I thought some of those same people would be able to comment on how they work and what the differences are between them and an FPGA.
Not saying that anyone in this thread was one of those people, but very likely that one or more of those critics is reading this thread.
From what I read at the XMOS site, there chips seem very interesting and the decision to make part of their work Open Source makes it even more interesting.
-
My roof lamp emulates light..
That was actually a question...
Very informative thread once a guy sorts out the arguing and dick waving, hehe.
I don't wave dicks, thank you very much, and if you think it's about that, then you're wrong... AND you're missing the point I was trying to make.
It's all too easy to get sidetracked by the details. You want to get a point across, but you look up information thinking it will help explain your point better. Well, NOT! Should have been obvious that that has ended now.
-
Since there were so many members here and elsewhere that were so quick to jump at criticizing A-Eon and Varisys's decision to include the XMOS chip on the Nemo motherboard for the X1000, I thought some of those same people would be able to comment on how they work and what the differences are between them and an FPGA.
Not saying that anyone in this thread was one of those people, but very likely that one or more of those critics is reading this thread.
From what I read at the XMOS site, there chips seem very interesting and the decision to make part of their work Open Source makes it even more interesting.
amigadave,
IMHO the inclusion of the XMOS chip it's not a bad thing per se, what I criticize is:
1) The decision to create an "aura" of magical expectations around its inclusion. It's a poweful chip, but don't expect it to made "the difference" like custom chips did wrt other architectures back in 1985.
2) If you're going to sell the X1000 at *THAT* price, at least be gracious enough to include the top of range XMOS chip available.
As freqmax said, it's probably better to start a new thread because (oh, the shock! :)) the term "emulation" as it was used at the start of the thread (i.e. "algorithmic emulation") it's not only applicable, but better fitting the XMOS chips.
So it could lead to confusion to say that, "yes, it's sort of in between a microcontroller and an FPGA" and on the other hand "one it's emulating, the other is not".
-
As freqmax said, it's probably better to start a new thread
I did not say that.
However some people should pay attention to people working with FPGAs in depth.
-
Oh, sorry! I misunderstood. :)
I thought you intended that when you said "it might be less confusing to not include it in the discussion".
-
Not include != Make new thread.
-
Hi,
At least you gave it a perfect title for the people on Amiga.org
"FPGA for dummies"
smerf
-
Not include != Make new thread.
You're absolutely right. A discussion about different forms of emulation, and what is and what is not emulation, definitely belongs in another thread (it's just too easy to get sidetracked sometimes, but no offense intended :)).
-
No, XMOS jus complicates the subject of the thread.
-
Sorry, I did not read the whole thread.
I look at it this way. It is between emulation and an Asic.
Emulation -> Reconfigurable Logic -> Asic
VHDL looks like programming but I bet it is a bit pattern when done.
After looking at the difference between Hard Wired and Microcode on the web, I feel it is more toward being hardware than software.
Having the Amiga OS on hardware without a software layer below it is the whole idea to me. The software layer being another Os.
-
Some have used an eeprom to act like a pla. An eeprom can fall behind in speed when trying to keep up with ttl counterparts. It would be cool to use a 10 ns sram that would get loaded with a pattern and run much faster than the 70 ns eeprom.
I wonder if anyone has made a descrete component version of a fpga?
I looked up micro-code on Wikipedia, there goes my credibility. It talked about how it is horizontal and vertical. I did not know that some cpu's still had the ability to have is mcode changed.( core2 duo and game cube ) It seemed to revolutionized the building of cpus.
Edit:
It would be interesting to see a computer boot up in a 16 bit mode and then load micro-code to run 32 bit apps.
-
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 follow EE Journal (http://www.eejournal.com/) they often discuss newest development in ASIC, FPGA and embedded. They have also an article on XMOS from a year or two ago here (http://www.eejournal.com/archives/articles/20090728_xmos/).
greets,
Staf.
-
Anyone else sees the irony that a thread called "FPGA for dummies" ended up like this (jargon fest)?
-
Anyone up for answering this question? It has nothing to do with any kind of emulation debate, and the only emulation I'm talking about here is a software based switch logic emulator (probably in 680x0 on the Amiga).
If I made a parallel switch emulator, where you have two kinds of switches (normal and inverted), that behave like relays and have four pins, then how difficult would it be to translate such virtual circuitry to FPGA circuitry?
The emulation doesn't emulate electricity and simply uses 0 and 1 as signals, and signals are never amplified in any way.
Anyone else sees the irony that a thread called "FPGA for dummies" ended up like this (jargon fest)?
Yes, and it's my fault. I wanted to make a point about emulation and thought quickly looking up some 'stuff' would help me make my point. I was wrong :(
-
I bet you made the original poster cry. :)
-
FPGAs implement the connectivity and logic gate setup that the HDL-code (VHDL/Verilog) specify. It will be slightly slower than a plain ASIC because the extra circuitry to make it possible to change function on the fly.
Thus the HDL-code specify connections and gate setup. The only exception are special builtin blocks that deals with phase locking, I/O modes etc.
It won't emulate, simulate, run any code or anything else. All that is plain misunderstanding.
There are analog FPGAs but they are limited. Other than that, other circuitry is just a mix of these technologies.
-
It won't emulate, simulate, run any code or anything else. All that is plain misunderstanding.
Except for emulation. It actually applies to all programmable chips, and it basically comes down to how far the concept of emulation reaches, and this is debatable. Of course, this really does belong in another thread.
-
I follow EE Journal (http://www.eejournal.com/) they often discuss newest development in ASIC, FPGA and embedded. They have also an article on XMOS from a year or two ago here (http://www.eejournal.com/archives/articles/20090728_xmos/).
greets,
Staf.
Thanks Fats,
I am a little surprised that more people have not researched XCore and the XMOS chips in detail, since they are included in the newest flagship of the AmigaOne line.
I know not everyone can afford one, but I thought maybe some of the X1000 beta testers could comment on what the XMOS chips is and what it can and cannot do, without infringing on their NDA's with A-Eon.
Just a general statement or two about how they differ from FPGA's, since both appear to be programmable chips. One using VHDL, or Verilog and the other using the "C" language with X extensions to program them.
I guess the people that know are too busy to be reading this thread. I will have to do more research on my own, but was hoping one of the experts would chime in.
Where are you Steve Solie? You might not be an expert on XMOS, but I'll bet you can shed some light on my questions.
-
Thanks Fats,
I am a little surprised that more people have not researched XCore and the XMOS chips in detail, since they are included in the newest flagship of the AmigaOne line.
I know not everyone can afford one, but I thought maybe some of the X1000 beta testers could comment on what the XMOS chips is and what it can and cannot do, without infringing on their NDA's with A-Eon.
Just a general statement or two about how they differ from FPGA's, since both appear to be programmable chips. One using VHDL, or Verilog and the other using the "C" language with X extensions to program them.
I guess the people that know are too busy to be reading this thread. I will have to do more research on my own, but was hoping one of the experts would chime in.
Where are you Steve Solie? You might not be an expert on XMOS, but I'll bet you can shed some light on my questions.
The XMOS chip is a CPU. It contains no programmable logic and is nothing at all like a FPGA.
-
The XMOS chip is a CPU. It contains no programmable logic and is nothing at all like a FPGA.
Indeed, even though it says this on their site:
XMOS embedded processors bring together the capabilities of processors, DSPs, ASICs and FPGAs in one, two and four core devices. Find the right chip for your designs.
Very misleading after you read about what those chips really are, on the same site :hammer:
-
Thanks Fats,
I am a little surprised that more people have not researched XCore and the XMOS chips in detail, since they are included in the newest flagship of the AmigaOne line.
I know not everyone can afford one, but I thought maybe some of the X1000 beta testers could comment on what the XMOS chips is and what it can and cannot do, without infringing on their NDA's with A-Eon.
Just a general statement or two about how they differ from FPGA's, since both appear to be programmable chips. One using VHDL, or Verilog and the other using the "C" language with X extensions to program them.
I guess the people that know are too busy to be reading this thread. I will have to do more research on my own, but was hoping one of the experts would chime in.
Where are you Steve Solie? You might not be an expert on XMOS, but I'll bet you can shed some light on my questions.
speaks lengths about how much it is worth, anticipated and generally demanded, especially on amiga related hardware, doesnt it? i would steer clear as far as possible. there is troubles enough without it.
-
The XMOS chip is a CPU. It contains no programmable logic and is nothing at all like a FPGA.
Please elaborate!
That is not what I came to understand from my short read of their site, but then I am here asking for clarification, because I am not sure exactly what they are.
Are you saying that they are nothing more than a specialized CPU that runs modified "C" code?
At Wawrzon, I disagree. Just because no one in the Amiga community has looked at these chips long enough to come up with a useful purpose yet, it does not mean that it won't happen.
The company would not still be in business if they were not producing something useful. It is hard enough to stay in business when you make something that is useful and there are many examples on their site showing what the chip is capable of. One item in particular that interested me (as an iPhone owner), is the iPhone dock that uses the exact same XMOS chip that is on the X1000 motherboard.
-
Can't we all just get along? :D
1400!
-
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.
-
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.
You're not saying it right: An FPGA provides the user with an environment which enables the user to implement electronic circuit designs without having to build a physical implementation for each design. That's why it's an emulation.
Sorry, couldn't help my self :)
-
Please elaborate!
That is not what I came to understand from my short read of their site, but then I am here asking for clarification, because I am not sure exactly what they are.
Are you saying that they are nothing more than a specialized CPU that runs modified "C" code?
It's a CPU that supports 8 threads per core. It doesn't run C code, at least not directly. You have to compile your programs with their version of GCC. XC is a version of GCC that has extensions to support multi-threading and possibly some of the other hardware on the chip.
-
@wawrzon
For bout 100 bucks you can find out what an XMOS does. It's basically a small computer you can program and place in remote situations. If you have a robot for example, you program the XMOS chip to run your robot and plug it into the robot. It's cheap and efficient.
-
Thanks Fats,
I am a little surprised that more people have not researched XCore and the XMOS chips in detail, since they are included in the newest flagship of the AmigaOne line.
I know not everyone can afford one, but I thought maybe some of the X1000 beta testers could comment on what the XMOS chips is and what it can and cannot do, without infringing on their NDA's with A-Eon.
Just a general statement or two about how they differ from FPGA's, since both appear to be programmable chips. One using VHDL, or Verilog and the other using the "C" language with X extensions to program them.
I guess the people that know are too busy to be reading this thread. I will have to do more research on my own, but was hoping one of the experts would chime in.
Where are you Steve Solie? You might not be an expert on XMOS, but I'll bet you can shed some light on my questions.
I thought we already kind of covered the possibilities in a thread about a year ago and it seemed people that might have some inkling chimed in at the time, and nobody could really come up with any sensible use for it. Sorry to sound negative, but I think that's why you aren't hearing any real use for it being proposed.
I'm just a software guy and I haven't looked at the XMOS in gory detail, but to me this just looks like a CPU that is good for wiring to other hardware and is particularly good at responding to multiple events with low latency, better than a general purpose CPU for that. But it's also nowhere as fast as a general purpose CPU.
If it served as the main CPU for some bit of electronic hardware it can probably do the intended job for a decent price. But sticking it inside a computer where there's already a powerful CPU and IO slots? Doesn't make much sense to me at all. Sure, you could make it do something and make it interface to some hardware in the Xorro slot or whatever, but is this something that will work out better than what can be done with IO boards on a PC? I don't really know as I'm not a hardware guy, but it seems to me if XMOS was a great idea you could just plug a card into your PC or have one come on it's motherboard. Maybe you can, but I don't hear much about that there either as solving many of the world's problems.
-
If I've read the xmos specs right, it should be pretty good at allowing you to implement at run time, all manner of I/O... I'm not sure what use that really has for the desktop hobbyist, but I can see how it would be very useful for hardware dev and small industrial production runs.
-
I find this philosophical argument about Emulation vs Real hardware equity funny.
Either via a software emulator or an FPGA, there is a recreation of the original functionality of the old chips. Neither is more "real" than the other and both "emulate" (meaning: appear to be like the original hardware from a user and software perspective) the Amiga.
I've been having a laugh while reading this thread too. :D
Yes, either software emulation or FPGA recreates the original functionality. However, only the FPGA recreates the original CIRCUITRY (and is actually more precise therefore). We're only talking the internal makeup of the computer that makes it what it is and how it works here. The DNA of the Amiga... as long as this is replicated how can this be called mere "emulation"? This is definitely more "real" than just software emulation on an alien platform. It's not emulation, it's cloning, if of an ephemeral nature due to the hardware being used.
And it's just semantics that some are using "emulation" in a broader sense, to include anything and everything that is not the original Amiga hardware. If it has any difference in the technology of the hardware, if it doesn't have anything stamped on the chips that you can visually read it's a 68000/3.1 ROM/Denise/Agnus/etc., or that it doesn't have the original external case and look of the Amiga, then some insist it's not really an Amiga, just an "emulated" one. And ignoring the fact that electronically it is identical! Not original Amiga, but not emulated, that is actually a clone. To use the word "emulate" for anything not original, is too confusing, inaccurate, and broad of a definition.
The comparison between RAM and ROM to FPGA and hard-wired chips is very accurate. But consider another analogy: authentic English speaking or translated English. One is the real deal, the other is not. Translated can't have quite the precise same meaning as the original, much like emulation isn't precisely the same. Someone Japanese speaks in their native tongue and a translator converts it to English. This is like emulation. Someone British speaks English, of the ethnicity of original English speakers. This is the "real" thing. Someone Japanese speaks English, born in the UK and has no Japanese accent. Is this translated English (emulation), just because they're not of the original English speaking ethnicity, or is it "real" English? It's the same thing as arguing the Japanese native-English speaker is translated English to argue the FPGA Amiga is emulating a real Amiga. They're both doing the same exact thing, but they just LOOK different. It's what's going on under the hood that matters most.
-
You're not saying it right: An FPGA provides the user with an environment which enables the user to implement electronic circuit designs without having to build a physical implementation for each design. That's why it's an emulation.
Sorry, couldn't help my self :)
Au Contraire, An FPGA gives the user an environment were the user *can* build a physical implementation of his design without all that tedious mucking about with a wire-wrap gun and a pile of chips. That's why it's not emulation.
Sorry, coundn't resist either. ;-)
-
And it's not really recreating the circuitry of the original chips, that's unknown, what it's actually doing is creating a "soft" circuitry that reproduces the results of most, if not all of the original "hard" circuitry results.
Yes, compared to modern hardware the Amiga custom chips are extremely simple, but still what you have is a simulation of what the Amiga was.
But why is this important?
-
Gosh, there's no soft circuitry or simulation.
Either you have circuit that match the electrical and most importantly the timing specification. If that is fulfilled, it's the real deal.
-
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.
-
Problem here is about belief vs. technical facts
Thumbs up.
-
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.
-
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.
-
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.
-
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.
-
I did not mean that reconfiguration capability implies slowness. But it's a common result with current SRAM reconfigurable gates.
-
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.
-
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.
-
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.
-
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).
-
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.
-
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.
-
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).
-
Yeah the Amiga chipset emulates Amiga.
-
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.
-
But AGA, like ECS Natami and Minimig, come from something other than the original chipset blueprints.
That simply means AGA is a new version of the Amiga chipset.
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.
Wait a minute, are the Amiga custom chips done in ASICs? Aren't ASICs chips that can be programmed once?
But we may never come to agreement on that philosophy.
Indeed. As long as it's clear that it's a philosophy and not necessarily set in stone.
-
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.:(
-
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
-
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).
-
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.
-
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.
-
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?
Not when implemented using an ASIC (billt just explained ASICs quite clearly). In this case you simply get a hardwired copy. If you made a hardwired implementation of just the behavior of a chip, you'd get a replica, not an emulation.
The reason why I keep hammering on the FPGA=emulation thing, is because of the soft side of FPGAs. All sorts of overhead electronics are needed to actually connect the wires together, and these extra components aren't needed to do a hardwired implementation. It seems to be a simple case of interpretation.
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.
Right, good to have that cleared up, means ASICs can stay out of the whole emulation thing.
-
We are now scanning dies of some 1980 ASICs. From this, we can do polygon extraction - then transistor extraction and then reduce to gates.
Amiga ASICs ?
Scanning electron microscope or high-resolution camera?
-
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.
-
The reason why I keep hammering on the FPGA=emulation thing, is because of the soft side of FPGAs. All sorts of overhead electronics are needed to actually connect the wires together, and these extra components aren't needed to do a hardwired implementation. It seems to be a simple case of interpretation.
Of course you're right, it is a matter of interpretation, however getting hung up on the need for the wires to be fixed in a non-emulated implementation seems like an odd requirement, IMO.
Let's use a hypothetical situation to explore this. Let's say you wanted to recreate a Z80 CPU using logic gate ICs (7400 series or similar). Let's say two devices were built, one on breadboard, the other on veroboard. Which is the true recreation? Are they both Z80 recreations? Is the veroboard model the only valid one, as you can more easily alter the wiring in the breadboard model?
My interpretation of emulation is making software designed for one computer system run on an incompatible computer system, meaning there needs to be a host layer and an emulation layer. IMO this doesn't apply to FPGA implementations, as they're not fixed function devices so there's no translating going on between architectures. It's a matter of opinion, but that's how I see it.
-
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.
You can work on the circuit timings too, which ensures you can get complete accuracy. Besides, circuits don't need to be identical to be compatible with each other, e.g. a 68020 and a 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.
-
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.
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?
-
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.
-
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.
-
This is funny. No, make that amusing.
Jay Miner and crew did old-fashioned logic design, possibly with pencil and paper, at best with some pretty rudimentary electronic tools. Remember how they went out to buy workstations the moment C= bought them up? Digital design required some top notch equipment (like Apollo workstations).
So, Meet Joe Pillow: A heap of chips, wires, and boards.
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.
-
Papper is just emulation of real writing.. ;)
I thought the Amiga team used SAGE computers (https://en.wikipedia.org/wiki/SAGE_Computer_Technology) (aka "Agony") ..?
-
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
-
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.
-
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.
I'm talking about translating between hardware environments by means of cycling through translation stages. Which in most cases is implemented by means of software.
MPGA - Meta Programmable Gate Array, version 0 (http://web.archive.org/web/20050309010953/http://ce.et.tudelft.nl/~reinoud/mpga/README.html) brought back ;)
-
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.
-
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
-
If it looks like a duck, walks like a duck and quacks like a duck then it is a duck.
Or in this case, an Amiga.
Next you'll be arguing about whether computers can ever be classed as intelligent.
-
My toaster is conspiring against me! ;)
-
If it looks like a duck, walks like a duck and quacks like a duck then it is a duck.
What if it's a robotic duck?
Next you'll be arguing about whether computers can ever be classed as intelligent.
Ha ha, I'll bite.
No, they can't. Same goes for the brain, because it's the neural connections that make a brain able to do anything in the first place. No neural connections=no functionality=no intelligence. Applies to computers as well: No software=no functionality.
The question therefore becomes: Can humans write intelligent software?
-
Perhaps it is this:
(http://farm3.static.flickr.com/2537/4096996466_a6961a8a8a.jpg)
-
"Proper Amiga", "Real Amiga", "True Amiga", "The Real Thing". Oh wait, that last one is from a Coca Cola commercial.:roflmao:
These arguments from the "Faithful" about what is "Real" and what is a form of emulation are so ridiculous and narrow minded (and tiring). If you want to follow their dogma to the letter then maybe everything that came after the A1000 should be considered emulation? Or should we go back further and consider everything that came after the original prototype breadboards with the mass of wires that were used as a proof of concept before the custom chips were first fabricated, to be emulation as well.
Why can't the fanatics that try to turn this into a holy religion realize that there is no ONE definition of what a "Real" Amiga is anymore. Not even between the most hard core fanatics can they agree what is accepted as a "Real Amiga" and what is labeled as "Clone", "Emulation", "Copy", "The Evil Destroyer of Amiga", etc.
Stop wasting so much time and energy arguing what is what and enjoy which ever versions and flavors of the Amiga experience that you see value in. I have been using the term Amiga inspired a lot lately, because I think that it fits my interests of all things that have their roots in the original Amiga.
Celebrate how much the Amiga has inspired so many different people in so many different ways and the profound effect it has had on all of us. Celebrate how we are tied together, instead of focusing on how we are different and fighting with each other because we enjoy this inspiration differently. We are all part of the greater Amiga community and should be proud that Jay's "Little Computer" continues to inspire so many people long after it has fallen out of production and lost all company support.
-
@amigadave
ditto.
-
What if it's a robotic duck?
Which side of the uncanny valley is it on?
-
No, they can't. Same goes for the brain, because it's the neural connections that make a brain able to do anything in the first place. No neural connections=no functionality=no intelligence.
Step 1: Synapse.
http://www.gizmag.com/researchers-create-artificial-synapse/18482/
http://www.mit.edu/newsoffice/2011/brain-chip-1115.html
Step 2: Neuron....
-
"Proper Amiga", "Real Amiga", "True Amiga", "The Real Thing". Oh wait, that last one is from a Coca Cola commercial.:roflmao:
Why can't the fanatics that try to turn this into a holy religion realize that there is no ONE definition of what a "Real" Amiga is anymore. Not even between the most hard core fanatics can they agree what is accepted as a "Real Amiga" and what is labeled as "Clone", "Emulation", "Copy", "The Evil Destroyer of Amiga", etc.
The problem is that those fanatics have brought this "what is a real Amiga" notion into an argument where it doesn't belong. The original question was whether or not an FPGA implementation was "emulation". I maintain that something like UAE where one computer executes a software program to pretend to be another is "emulation". Replay and Minimig are hardware implementations, same as if you wired one by hand like the Lorraine prototype.
It's got nothing to do with the "realness", "accuracy" "quality" or "amiganess" of the project, simply the underlying technology used to do it.
Sheesh ;)
-
Papper is just emulation of real writing.. ;)
I thought the Amiga team used SAGE computers (https://en.wikipedia.org/wiki/SAGE_Computer_Technology) (aka "Agony") ..?
I think you needed a SAGE to bootstrap the dev box?
-
How commodore made AGA is irrelevant, it's how you make something that behaves like AGA that is important.
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)?
-
These arguments from the "Faithful" about what is "Real" and what is a form of emulation are so ridiculous and narrow minded (and tiring).
Wrong, it's about the principle of what is an emulation and what isn't.
If you want to follow their dogma to the letter then maybe everything that came after the A1000 should be considered emulation?
Of course not, because emulations and partial replicas are two different things.
Why can't the fanatics that try to turn this into a holy religion realize that there is no ONE definition of what a "Real" Amiga is anymore.
The machines you could buy back in the day are the only Amiga computers. What's so fanatical about that?
I have been using the term Amiga inspired a lot lately, because I think that it fits my interests of all things that have their roots in the original Amiga.
That's the whole point behind the real Amiga debate. Some people want Amiga and some people want Amiga inspired.
Step 1: Synapse.
http://www.gizmag.com/researchers-create-artificial-synapse/18482/
http://www.mit.edu/newsoffice/2011/brain-chip-1115.html
Step 2: Neuron....
And without step 3 it will all do nothing.
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)?
Perhaps it's a partial replica? Doesn't matter, because it was designed and made by the makers of Amiga.
-
And without step 3 it will all do nothing.
Step 3 is profit.
-
realize that there is no ONE definition of what a "Real" Amiga is anymore.
Just a note, I haven't been trying to argue about what is real or fake Amiga. My part in the debate is about what is a real or imaginary circuit implementation. OK, I guess I have asked questions about what or who makes something real instead of a simulation or emulation in a custom chip, and what or who makes the same thing not a simualtion/emulation, but that all links back to trying to understand why one custom chip is a real circuit and another custom chip is a figment of everyone's imagination, which is how some people here feel about it.
-
Perhaps it's a partial replica? Doesn't matter, because it was designed and made by the makers of Amiga.
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?
-
Either the logic circuit meets the timing specification or it doesn't ..!
How you accomplish that is irrelevant.
-
I am terribly amused by all the logical.. uh.. agility demonstrated in this thread by some people, trying to sidestep all cold hard technical facts to justify some kind of personal religious belief.
Stay vigilant. The vile beast of Emulatioladilodillee-ation might lurk around the corner, corrupting your life into something of the unpure!
-
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.
-
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
-
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.
-
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.
-
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.
What are you smoking? Did I say anything about liking one over the other? Sounds more like you have the prejudice.
-
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
-
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.
My only concern is to recognize the different technology in the two approaches. Software emulation is different from FPGA implementation. Has nothing to do with anything other than that. They are both ways to do an Amiga, or other things.
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.
-
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".
-
One of the methods can adhere to the timing specification of the original design.
-
One of the methods can adhere to the timing specification of the original design.
Not true, I could program a microcontroller to respond to signals correctly to replicate the functionality of an ASIC (in fact I have used an ATMega328 in place of some old custom chip before). As long as it meets the timing as documented it will work.
-
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.
-
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.
-
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.
-
Depends on the circuit & the processor. There are circuits that are too fast to put into an fpga.
Name one?
-
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.
You make my point for me. ;-)
-
if it wasn't made 20+ years ago, it's not a "real" classic Amiga. real, for many classic Amiga enthusiasts, is defined by more than logic gate responses on a microchip. it also involves knowing that the system you are using was physically present with you in the past. it's tangible nostalgia, something fpgas recreate very poorly. in that respect alone, fpgas certainly are a poor simulation/substitute for a real amiga.
-
If you performed a test, with FPGA and real hardware hidden behind a wall or something, and people could not tell the difference the two, then that's good enough for me.
-
for a lot of people, they WOULD be able to tell the difference.
it's interesting to note: on the Amiga and c64 demoscene, i can cite a few examples of new demos (created after fpga blueprints for these systems) which push REAL hardware to the limit yet run fine on real machines. yet, because they do not play nicely with documented hardware timings and such - the code breaks fpga "hardware" and software emulatrs.
it may not be strictly "correct" terminology to call recreations of chips on fpgas an emulation, but that is their effective result.
i could program a fairly decent rule based inference system to replace the knowledge response of my local GP. but i wouldn't like to bank on it to diagnose anything out-of-the-ordinary and uncommon. not before reflashing/programming it with updated knowledge from a REAL doctor.
superficial familiar response != real
-
@xyzzy
And the same could be said for UAE.
-
"Is AGA a "proper Amiga" chipset?"
Perhaps it's a partial replica? Doesn't matter, because it was designed and made by the makers of Amiga.
Was it? How many of the original Los Gatos crew were left at C= to do AGA?
And yes, it matters. Either AGA is a proper Amiga chipset or it isn't. Make up your mind.
Why does it matter? Because the VHDL/Verilog design can probably be scrunched from someones security backup (if exonerated). That gives you the _original_ AGA design. In pure electronic form. Ready to be pushed into silicon again in 2011 (make that 2012).
But I guess according to some funny "rules" it wont fly unless it is done in the same fab process as the original was? And certainly not implemented with an FPGA or two.
(I guess Jens Schoenfeld is a heretic who will be first up against the wall for having pulled chips one by one out of an A1000 and replaced them with an FPGA.)
-
The AGA chips that commodore designed and had manufactured are "proper". Anything you design and manufacture are not the same.
I'll join you in playing your game of semantics:
If C= was still alive today (and filthy rich) and pulled out their original VHDL/Verilog for AGA to make a "20-years celebratory model" 4000 and had new chips manufactured by one of today's chip foundries in a current fab, would that be a proper Amiga?
If they made an internal test first to check their tools and used FPGAs to implement it, would that be a proper Amiga?
If I had a backup tape passed over from a friend of a friend with the original design and had it implemented in the same fab as used in 1990(91?) would that be a proper Amiga?
If yes, would it be if implemented in a current fab?
If yes, what about if I used FPGAs for it?
If you attend a faire with Jens Schoenfeld showing two A1000s and he tells you "one of these have had the custom chipset removed and replaced with FPGAs" and you can't tell the difference (assuming you have all the sw in the world to bring along to test), which one is a real Amiga?
-
Machines that adhere to the same electrical specification as the "original" is real.
The missing masks, and original code just shows how bad proprietary designs are for long term usage. But that's the way it is, like it or not. Someone could scan the orignal chips (don't throw them!). But such process is still hard. So the method that remains is reverse engineering.
Does anyone know how the orignal designs were managed?, I know 6502 was done with manual methods like pen and papper, OCS used logic chips and wire-wrap. But somewhere after that they ought to migrated into some electronic design system.
-
I'm remembering in an interview that the AGA design had a few bugs in it that needed reworking on the motherboard (sorry can't remember te exact source right now)... But suffice to say, you wouldn't want the original logic network of the AGA... It would be better to use a new circuit built to the correct specification :)
-
it's interesting to note: on the Amiga and c64 demoscene, i can cite a few examples of new demos (created after fpga blueprints for these systems) which push REAL hardware to the limit yet run fine on real machines. yet, because they do not play nicely with documented hardware timings and such - the code breaks fpga "hardware" and software emulatrs.
Please do name a few of these (new) demos.
-
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).
-
Saying that you won't get this particular problem proves my point that what you doing with an FPGA is emulation.
Are you claiming using an FPGA is always emulation ?
Is an FPGA based Cisco router emulation then ? What are they emulating, are you also in the league that says this is emulating a fictional hardware implementation that never will be manufactured ?
greets,
Staf.
-
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
-
Is an FPGA based Cisco router emulation then ? What are they emulating, are you also in the league that says this is emulating a fictional hardware implementation that never will be manufactured ?
You have to look at what the FPGA does here (I didn't :(). Is it something that can be ASICed, or is the functionality of the FPGA used in a different way?
-
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.
/MikeJ
It might be even simpler, unless aiming for "virtual analog" DRAM modeling :)
By chance (a bug), I've observed the failed refresh behaviour of a fast page SIMM, and it's amazing how much stuff is still intact after A FULL MINUTE.
So while a small bunch of cells might (or not) fail shortly after the time listed in the datasheet, the number grows much slower than I imagined, no avalanche effect!
All seems to indicate that decay of cells happen with an exponential rate (linked to capacitor discharge curve vs internal noise, I guess).
So probably a couple of LFSRs, a few counters, and some other glue might be sufficient, expecially if the CPU probing for failed refresh is a relatively slow 8-bitter.
-
You have to look at what the FPGA does here (I didn't :(). Is it something that can be ASICed, or is the functionality of the FPGA used in a different way?
Is mostly done in FPGAs because you can update both the CPU firmware and the HW accel functions. Still economically viable considering the cost of midrange and high end routers.
IIRC high end switchrouters (6500 and 12000) also use ASICs.
The functions offloaded to hardware is progressively increasing with the class of the router.
In some midrange models (3600) you can see the effect of FPGA vs CPU processing by using standard vs extended access lists (in reasonably massive amount :D).
(recalled from faded memories, please feel free to correct me)
-
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.
-
All seems to indicate that decay of cells happen with an exponential rate (linked to capacitor discharge curve vs internal noise, I guess).
Likely related to the threeshold of the internal sense amplifiers. Ie before it reaches the thermal noise floor.
-
Even an FPGA & ASIC running from the same VHDL don't necessarily behave the same way due to clock skew.
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
-
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.
-
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.
-
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.
A baked ASIC STILL doesn't run VHDL, again would suggest you do a bit more research.
-
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.
-
You take the VHDL & it gets turned into an ASIC. I know how that works.
Okay, explain it then. What is involved in that translation between VHDL and an ASIC? If you know how it works, then it won't be a problem explaining it. I await your reply.
-
Okay, explain it then. What is involved in that translation between VHDL and an ASIC? If you know how it works, then it won't be a problem explaining it. I await your reply.
logic synthesis -> placement tool -> routing tool -> profit
-
logic synthesis -> placement tool -> routing tool -> profit
Good. So do you know how much work is required for those steps? The simplification you're implying is that tools do most of the work, whereas the reality is moving from FPGA to ASIC is a labour intensive process that makes use of tools to simplify where possible. There are reasons why ASICs take months to design, even with a working FPGA version in place.
In this process, VHDL is not much more than a design spec, you can use it to kick off the logic synthesis process, but beyond that it's not going to be an active factor. This is why saying an ASIC 'running' VHDL is a mistake, unless you're making some gross oversimplification that any description of an integrated circuit is a 'VHDL'.
-
This is why saying an ASIC 'running' VHDL is a mistake, unless you're making some gross oversimplification that any description of an integrated circuit is a 'VHDL'.
You're suprised at gross oversimplification on an internet message board? While trivial in comparison I also don't mention creating a bitstream from VHDL and loading that into an FPGA.
The discussion was about whether using VHDL that described the behaviour of an Amiga to build an FPGA or an ASIC was simulation/emulation, the procedures you go through to do that are irrelevant to that discussion.
In the same way as how you simulate the amiga chipset is irrelevant, whether you're using software, hardware or pen & paper (this last one is labour intensive, slow & suffers from random innaccuracies and boredom).
-
Good. So do you know how much work is required for those steps? The simplification you're implying is that tools do most of the work, whereas the reality is moving from FPGA to ASIC is a labour intensive process that makes use of tools to simplify where possible. There are reasons why ASICs take months to design, even with a working FPGA version in place.
Are you saying you can't implement an FPGA circuit design directly using an ASIC?
-
The discussion was about whether using VHDL that described the behaviour of an Amiga to build an FPGA or an ASIC was simulation/emulation, the procedures you go through to do that are irrelevant to that discussion.
Let's just put it like this, I'm surprised that you brought up VHDL in the same sentence as ASIC, as they are not related.
Are you saying you can't implement an FPGA circuit design directly using an ASIC?
It's not impossible, the issue is that you wouldn't want to. To understand why, need to know about logic elements/logic cells (often shortened to 'LE'). See here:
http://en.wikipedia.org/wiki/Field-programmable_gate_array#Architecture
FPGAs make certain compromises in order to be reprogrammable. Designing a function in an FPGA relies on use of these generic building blocks, whereas with ASICs you have the freedom to make a design more efficient by simplifying/optimising the circuitry used. So whilst you could build an ASIC that mirrored the design of an FPGA, you'd be losing out if you did.
Before you start on the 'so FPGAs are only emulations' schtick, the important point to note is that even though the designs are different, they can be functionally identical. Think about it like this, Sony brings out a TV using an FPGA to drive the circuitry. They then bring out a new model, which is the same as the old one in every way, except the FPGA is replaced with an ASIC. Is the later model an emulation of the first? No.
-
One could exploit FPGA "floor planning" to accomplish some performance gains. On ASIC I guess it's all about floor planning.. ;)
-
Before you start on the 'so FPGAs are only emulations' schtick, the important point to note is that even though the designs are different, they can be functionally identical. Think about it like this, Sony brings out a TV using an FPGA to drive the circuitry. They then bring out a new model, which is the same as the old one in every way, except the FPGA is replaced with an ASIC. Is the later model an emulation of the first? No.
If you design one circuit to work the same as another one then it is a simulation. When the company that made the original uses the same design but slightly modifies it (i.e. switches from an FPGA to an ASIC) then it's not.
The same way that IBM made IBM PC's and other companies produced IBM PC clones. The term clone doesn't refer to the circuit being a direct copy, only that the same software can run. In todays language it would be an emulation.
The expansion model no 1 is also simulation/emulation.
http://www.colecovision.dk/atari.htm
-
Holy crap, all my AMD are emulating Intel ;)
-
Holy crap, all my AMD are emulating Intel ;)
He (psxphill) just doesn't get it. He's starting to sound like a broken record or a sick parrot on a pirate's shoulder sqwauking, "Braaak, FPGAs are simulations, FPGAs are simulations."
Just because my next door neighbor has the same floor plan as my home, doesn't make MY home a simulation in ANY respect.....same can be said for FPGAs or CPUs, etc......What the heck would it be simulating? Simulating implies that something about it wouldn't be real and I can assure you that my house is just as real as my neighbor's house. Both homes were built using the same plans and for the same purpose but by different contractors. Same can be said for FPGA based solutions. It isn't simulating anything. It's preforming the same purpose and function as the original. It's just being designed and built by someone other than the original designer. No more, no less. It doesn't matter if those plans were reverse engineered or if the architect had access to the original architects specifications. Both homes (and computers) are real and not simulating ANYTHING. An FPGA-based Amiga is just as real as an original classic Amiga.
-
Simulating implies that something about it wouldn't be real
Emulation/simulation doesn't imply that it isn't real, after all, everything that exists is real.
An FPGA-based Amiga is just as real as an original classic Amiga.
Of course, but it's not an Amiga, it's an Amiga replica. Two different things (look at the classic sports car world, the same happens there).
-
Emulation/simulation doesn't imply that it isn't real, after all, everything that exists is real.
Uhh, that was my point. No need to restate the obvious. So if it's real, it is not a simulation.
Of course, but it's not an Amiga, it's an Amiga replica. Two different things (look at the classic sports car world, the same happens there).
No kidding Sherlock. So what are you trying to say? That we should resurrect Commodore Inc. along with it's dead executives before we can have classic re-makes? That's absurd. The only thing that is going to satisfy you and psxphill would be to find a long-lost hidden cache of classic Amigas (or Amiga components) in some forgotten bomb shelter. News flash, Commodore isn't coming back, nor is the Amiga. Replicas are as good as it will ever get, so get over it.
More than one FPGA expert in this forum has set you and psxphill straight, but you two insist on spreading dis-information and continue to argue. Just let it go.....please!
-
Both UAE and FPGA are real Amigas. Now we can all be one happy family.
-
So if it's real, it is not a simulation.
What I mean is that a simulation is something that's real simply because it exists.
No kidding Sherlock. So what are you trying to say? That we should resurrect Commodore Inc. along with it's dead executives before we can have classic re-makes? That's absurd.
No, I'm not saying that at all, and yes, that would be absurd.
The only thing that is going to satisfy you and psxphill would be to find a long-lost hidden cache of classic Amigas (or Amiga components) in some forgotten bomb shelter. News flash, Commodore isn't coming back, nor is the Amiga.
That would be most satisfactory to me, yes. The chance that a large cache of NOS Amigas will be found is of course quites slim, so I'm not counting on it.
Replicas are as good as it will ever get, so get over it.
And that's not good enough for me, only a true hardwired copy would be good enough. I simply see FPGA computers for what they are, FPGA computers, that in and of themselves provide us with a new and interesting alternative computer platform.
More than one FPGA expert in this forum has set you and psxphill straight, but you two insist on spreading dis-information and continue to argue.
I think I have accepted corrections about the technical details, and I have already explained it. The problem was that I was trying to argue a point using technical details thinking it would help. Of course it didn't, and I have already admitted this. How many times must I say that I got that wrong?
My point is about emulation in and of itself and what it can be applied to. For example, can it be applied to software in general? Same question can be asked about FPGAs (and as billt, one of the experts, has said, it's a gray area, and I like to add to that that this makes the question hard to answer).
As for an FPGA computer being an Amiga, it's not, it's an FPGA computer. How difficult is that to see? Then again, people call macs with MorphOS Amigas, hell, people will call peecees with Amiga stickers on them Amigas, while obviously they're not. Why insist on calling something an Amiga while it's not?
-
If you design one circuit to work the same as another one then it is a simulation.
So, in your opinion, in the Sony TV example I gave, the ASIC is a simulation of an FPGA? If so, then I put it to you that nearly every ASIC that has ever existed is a simulation. Heck, Amigas are just simulations of Lorraine. Who knew we were all using simulations after all!
When the company that made the original uses the same design but slightly modifies it (i.e. switches from an FPGA to an ASIC) then it's not.
Ah, I see, you realised you'd gone too far, so stuck in this caveat about it needing to be made by the original company. You're clutching at straws, seriously. Let's put it like this. Imagine Commodore went bankrupt after the A3000, and was bought by Atari. Atari then bring out a new Amiga model, the A1200. Does that now make the A1200 a simulation, whereas it wouldn't be if Commodore released it? I should point out that in this hypothetical situation, the Atari A1200 is absolutely identical to the Commodore A1200 we know today, apart from the company that made it.
The same way that IBM made IBM PC's and other companies produced IBM PC clones. The term clone doesn't refer to the circuit being a direct copy, only that the same software can run. In todays language it would be an emulation.
Your use of the term 'emulation' is very wooly. The only major difference between an IBM clone and an IBM PC is the company that assembles it. IBM don't make PCs any more, but if they did, think about this... IBM brings out a new desktop PC. I then build a PC for myself that uses the EXACT SAME PARTS as the IBM one. Is my computer emulating/simulating the IBM one?
I think where you're going wrong is that you're trying to stretch the term 'emulation' to encompass the term 'copy'. When it comes to computers, copying something is not the same as emulating something. Emulation has a specific meaning when it comes to computers, it means making one computer run programs from an incompatible one. Copying, on the other hand, is prevalent throughout computing. For example, if I copy a file (i.e. clone it), am I emulating the file? I'm sorry, but your definitions are not standing up to scrutiny.
-
Emulation has a specific meaning when it comes to computers, it means making one computer run programs from an incompatible one. Copying, on the other hand, is prevalent throughout computing. For example, if I copy a file (i.e. clone it), am I emulating the file? I'm sorry, but your definitions are not standing up to scrutiny.
It's behaviour you emulate. So daemon tools is a dvd drive emulator.
Or you can have an ISA card: http://www.flickr.com/photos/defor/sets/72157623805154726/
Emulation doesn't just refer to software that makes a computer behave like another. However much you wish it did.
The term emulation started out purely as using hardware, using software was considered simulation (probably because you couldn't achieve real time results with software).
IBM PC's and clones share some chips, but the circuit board is different. It was only really the processors that were shared, the rest that makes it a clone was the same memory map etc. Before nvidia/ati/s3 etc you had custom graphics cards that emulated only certain functionality of IBM's original chips. Most graphics chips these days only emulate enough of VGA for the BIOS and windows boot screen & the days are numbered for that. Windows 7 uses a VESA mode (1024x768 IIRC) on bootup instead of Mode-X.
The term clone is similar to emulation in that IBM never made any clones, even though they made loads of different PC's. The clones were just as different to each other as they were to IBM's designs.
-
The term emulation started out purely as using hardware, using software was considered simulation (probably because you couldn't achieve real time results with software).
In fact, the words 'to emulate' and 'emulation' have been in use since the 1500s! See these definitions from Merriam-Webster:
Emulate: http://www.merriam-webster.com/dictionary/emulate
Emulation: http://www.merriam-webster.com/dictionary/emulation
It's precisely this that makes it hard to tell what is and is not an emulation.
-
Emulation doesn't just refer to software that makes a computer behave like another. However much you wish it did.
That's where you're wrong. As language evolves, words pick up new meanings for specific contexts. For example, with computing, you have a bunch of words that existed before modern computing, but that have specific meanings when applied to computers: kernel, shell, mouse, pipe, etc...
Furthermore, as usage of the word changes, so too does our definition for it. For example, call someone a 'cynic' today and you have a certain image of a bitter, morose person, whereas the original meaning is almost spiritual in origin (See for yourself: http://en.wikipedia.org/wiki/Cynicism ). However, if you called someone a cynic today, you are unlikely to be referring to their wish to "live in agreement with Nature.".
The same is true of the term 'emulation'. It now has a specific meaning when it comes to computing. See for yourself:
http://dictionary.reference.com/browse/emulate
IBM PC's and clones share some chips, but the circuit board is different. It was only really the processors that were shared, the rest that makes it a clone was the same memory map etc. Before nvidia/ati/s3 etc you had custom graphics cards that emulated only certain functionality of IBM's original chips. Most graphics chips these days only emulate enough of VGA for the BIOS and windows boot screen & the days are numbered for that. Windows 7 uses a VESA mode (1024x768 IIRC) on bootup instead of Mode-X.
The term clone is similar to emulation in that IBM never made any clones, even though they made loads of different PC's. The clones were just as different to each other as they were to IBM's designs.
You missed my point. I was talking about a hypothetical situation where all the components were identical, and it was only the company assembling the devices that changed. It's perfectly possible to build a PC that matches an IBM design exactly, my question was, is it a clone purely because of the company that put it together? To my mind, it's the device itself which is of interest, the company that makes it is not of any great importance.
-
Be careful not to become to exacting in your definition of what is real, since many companies will use chips from different sources from one month to the next.
So two computers made by the same manufacturer, a few months apart, in the same factory may not be identical, but does that mean that one is emulating the other?
-
Be careful not to become to exacting in your definition of what is real, since many companies will use chips from different sources from one month to the next.
So two computers made by the same manufacturer, a few months apart, in the same factory may not be identical, but does that mean that one is emulating the other?
A6000, psxphill is arguing that it doesn't matter that the designs are different, as long as they come from the same company. IMO bringing the role of companies into this is a red herring, as we're talking about how technology is identified, not the manufacturers of that technology, but that's what is being proposed.
-
The same is true of the term 'emulation'. It now has a specific meaning when it comes to computing. See for yourself:
http://dictionary.reference.com/browse/emulate
You better explain that to everyone else that disagrees with you.
from http://en.wiktionary.org/wiki/emulate
(computing) of a program or device to imitate another program or device
http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=4556828
http://www.syntiac.com/fpga64.html
http://dl.acm.org/citation.cfm?id=1999455
http://www.linkedin.com/in/mattdipaolo
http://arstechnica.com/civis/viewtopic.php?f=2&t=1152634&start=40
http://www.patentgenius.com/patent/6965972.html
http://www.scene.org/showforum.php?forum=11&topic=173109
The "emulator in an fpga is not emulation" stance seems limited to a few commercial "emulator in an fpga" projects.
-
Be careful not to become to exacting in your definition of what is real, since many companies will use chips from different sources from one month to the next.
So two computers made by the same manufacturer, a few months apart, in the same factory may not be identical, but does that mean that one is emulating the other?
Generally chips from different sources are made from the same mask and are just second source suppliers. AMD was a second source of Intel parts before it decided to make it's own. Therefore any variance in the components should be similar to the variance in the parts from the original supplier. It's impossible to make something identical, which is how you can get different speed rated processors out of the same batch.
This is different to starting over and designing your own motherboard.
I agree that it seems vague because of the same company clause, but you can't emulate yourself & it would muddy the use of the term if you could. It is better than the "emulator in an fpga is not emulation" argument that causes more confusion (although that confusion will produce higher profits, so it's easy to see why it's done).
-
Generally chips from different sources are made from the same mask and are just second source suppliers.
I don't know if that's true at all, but I do know that it's not generally true.
Some companies get bit by part changes. Supposedly identical parts from different suppliers can have enough difference to cause a product defect (probably a new timing or crosstalk issue due to faster/stronger outputs). Sometimes a single supplier changes their chip and this can cause a defect, without any notice or updates to documentation. One can be left scratching his head for quite a while until a chip change becomes known.
Also understand that even the same mask set in a different factory can give a different result and break timing or crosstalk.
-
That's where you're wrong. As language evolves, words pick up new meanings for specific contexts. For example, with computing, you have a bunch of words that existed before modern computing, but that have specific meanings when applied to computers: kernel, shell, mouse, pipe, etc...
Not only that, but the word "computer" had a meaning before the electronic device was invented. It originally referred to a person who had the fun task of calculating by hand huge and tedious tables of math functions. (Sin Cos and such)
-
Generally chips from different sources are made from the same mask and are just second source suppliers.
I don't know if that's true at all, but I do know that it's not generally true.
Well that was true for processors by Intel & Motorola.
For other chips there are standards that are specific enough that you shouldn't have problems, but yes problems do occur.
But then emulation is never exact either.
-
Sorry, I seem to be behind in reading this informative, fascinating, foolish, and ludicrous, massive thread. The above adjectives applying in a non mutually exclusive fashion, depending who is speaking.
If I made a parallel switch emulator, where you have two kinds of switches (normal and inverted), that behave like relays and have four pins, then how difficult would it be to translate such virtual circuitry to FPGA circuitry?
The emulation doesn't emulate electricity and simply uses 0 and 1 as signals, and signals are never amplified in any way.
The only emulation being attempted here is to speak techno babble, while lacking any fundamental understanding of the principles or technology being spoken of.
My roof lamp emulates light..
:roflmao: No kidding, that's how much sense he/she was making!
Very informative thread once a guy sorts out the arguing and dick waving, hehe.
Didn't know a heck of a lot about FPGA implementations before this read.
Yes, I quite agree, after sorting out the fools who like to show off, those speaking about what they know were most enlightening. I didn't even know there was such a technology as FPGA before this thread. Fascinating, a volatile circuit configuration chip! What RAM is to data, FPGAs are to circuitry (or what CD-Rs are to data, in some cases). And it makes sense, having played around with manually configurable Radio Shack circuit kits when was a lad, and knowing the fundamental function of electronic components (particularly transistors), that this could be done.
-
Yes, I quite agree, after sorting out the fools who like to show off, those speaking about what they know were most enlightening. I didn't even know there was such a technology as FPGA before this thread. Fascinating, a volatile circuit configuration chip! What RAM is to data, FPGAs are to circuitry (or what CD-Rs are to data, in some cases).
The fools who like to show off by making stupid straw man statements in a vain attempt to defend the "emulator in an fpga is not an emulator" stance have managed to make you think that an fpga works differently to how it does.
An fpga is made up of programmable cells, similar in concept to an ALU. http://en.wikipedia.org/wiki/Arithmetic_logic_unit
The routing between the cells is configurable by turning pre-existing routes on and off. The circuit never gets changes, gates only get turned on and off that change the routing and the operation of the cell.
An FPGA is an evolution of the PLA. http://en.wikipedia.org/wiki/Programmable_Array_Logic
-
You better explain that to everyone else that disagrees with you.
from http://en.wiktionary.org/wiki/emulate
(computing) of a program or device to imitate another program or device
http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=4556828
http://www.syntiac.com/fpga64.html
http://dl.acm.org/citation.cfm?id=1999455
http://www.linkedin.com/in/mattdipaolo
http://arstechnica.com/civis/viewtopic.php?f=2&t=1152634&start=40
http://www.patentgenius.com/patent/6965972.html
http://www.scene.org/showforum.php?forum=11&topic=173109
The "emulator in an fpga is not emulation" stance seems limited to a few commercial "emulator in an fpga" projects.
First of all, some of those examples weren't related to computing, as I said before the term emulation has specific meaning in computing, this does not need to extend to the whole electronics industry.
Secondly, FPGA re-implementations of entire computing platforms is a relatively new phenomenon, so it's not surprising that people would use the closest word they could think of to describe them.
Thirdly, some of the content you linked to uses other, more descriptive, terms to describe what's occurring, e.g. "FPGA-64 is a re-implementation of the Commodore-64 computer using reconfigurable logic chips." Re-implementation is a clearer way of describing the process being followed.
Well that was true for processors by Intel & Motorola.
Do you work in the industry? Curious to know how you know this.
The fools who like to show off
So someone who disagrees with you is a fool who likes to show off. Hmm... I didn't call you a fool, I would expect the same in return.
-
Not only that, but the word "computer" had a meaning before the electronic device was invented. It originally referred to a person who had the fun task of calculating by hand huge and tedious tables of math functions. (Sin Cos and such)
Quite right. This is the description of computer that existed at the time of Turing, in his work (and the work of other computing pioneers) he used this earlier definition to convey what was being proposed.
-
The only emulation being attempted here is to speak techno babble, while lacking any fundamental understanding of the principles or technology being spoken of.
That QUESTION isn't such an attempt, it's a QUESTION. I've actually written that in this thread already. Yes, this thread has caused me to get interested in this kind of thing, and I was wondering how hard/easy switch based logic is to convert to some FPGA format.
:roflmao: No kidding, that's how much sense he/she was making!
Dude, you're laughing at a BS reply to my question :)
Yes, I quite agree, after sorting out the fools who like to show off
I guess I do have to say I was wrong again :( It's NOT about showing off. I was trying to argue a serious point here, which is something that way too many people didn't understand (which is understandable). My mistake was trying to use technical terms to help make my point, and obviously that didn't work.
What I want to know is how many times I still have to say I was wrong?
-
The fools who like to show off by making stupid straw man statements in a vain attempt to defend the "emulator in an fpga is not an emulator" stance have managed to make you think that an fpga works differently to how it does.
I sure hope you're not talking about billt, because he's been nothing but patient in explaining the workings of FPGAs.
-
What I want to know is how many times I still have to say I was wrong?
Thomham, don't worry about this anymore, it's better to be inquisitive, you don't need to apologise for showing an interest in a new topic.
-
Do you work in the industry? Curious to know how you know this.
It's very well known.
http://en.wikipedia.org/wiki/Am286
Intel sued AMD for their 386.
http://en.wikipedia.org/wiki/Second_source (http://en.wikipedia.org/wiki/Second_source)
The 68000 was second sourced by alot of companies, Mostek, Rockwell, Signetics, Thomson & Toshiba.
http://en.wikipedia.org/wiki/Motorola_68000#Second-sourcing
The fools thing was aimed at the "my room lamp emulates light". It's even a rubbish analogy, because the lamp emits light. You could suggest that a lamp simulates the sun, however it would be a very innaccurate simulation as a lamp and the sun don't share many simularities & the lamp wasn't based on properties of the sun. An electronic lamp was built to replace gas lamps, but even then the light given out is completely different. But I'm sure it sounded funny when it was posted, even though it's just a stupid straw man argument.
The term "Emulator" has been used to refer to hardware simulated by FPGA/earlier similar technologies for two decades, it's not a relatively new technology.
You could say that a software emulator recreates a computer system, so because the FPGA 64 says that it's an emulator in an fpga and it recreates the c64 doesn't change anything.
-
psxphill, I've just finished looking through this entire thread, and noticed you said before you'd worked on software-based emulation (guessing for the PSX, judging by your name). As this means you should be familiar with programming, I'll try and explain my point using a programming analogy.
In object-oriented programming you have, amongst other ideas, the concepts of classes and objects. Classes describe the features of an object (variables used, methods allowed, whether the class is a member of a larger class, etc...), whereas objects are instances of a class, they are the items built by following the specifications in a class.
To me, Amigas are a class of computers, and the objects we use follow the specifications laid out in this class, to varying degrees. The A500 is an object that follows this spec, the Minimig is also an object that follows this spec. They are both implementations of the design ideas of the Amiga.
In my opinion, which is shared by many, emulation requires translation. Not translation from a design spec (class) to a computer (object), but translation from one object to another, fitting the code designed for one computer into the constraints of another.
Re-using the word 'emulation' when describing these devices does not capture this difference, which is why 'implementation' is preferrable.
-
Quite right. This is the description of computer that existed at the time of Turing, in his work (and the work of other computing pioneers) he used this earlier definition to convey what was being proposed.
So when it comes down to it, if you believe some folks, every computer from ENIAC to WATSON are mere emulators of some Victorian guy hunched over a stack of foolscap with a quill pen. :-) <-----------
In view of the Season, a Bob Cratchit clone.
The First Amiga
(http://img593.imageshack.us/img593/3745/bobcratchit1.jpg)
A more recent emulation
(http://img703.imageshack.us/img703/2581/bobcratchit2.jpg)
-
This thread has outlived it's usefulness......
(http://cdn.head-fi.org/3/3d/1000x500px-LL-3d00713e_pope-with-headphones-on-pic-reuters-getty-31071489.jpg)
-
It's very well known.
http://en.wikipedia.org/wiki/Am286
If AMD's had a higher possible clock speed, then I really don't believe it was the same masks as suggested elsewhere. Being pin-compatible and based on Intel's microcode does not a mask duplicate. Though it does seem your wikipedia article does suggest the 386 situation was a result of Intel not sharing masks, it still seems that AMD did some changes to the 286 design to get higher frequencies. And the wikipedia article says that it's common for those agreements to allow tthe first-source company to make designs from the second-sourcers. So there must be some design going on to have that in there.
The 68000 was second sourced by alot of companies, Mostek, Rockwell, Signetics, Thomson & Toshiba.
I remember something about some of them having quirks in compatibility, I think Signetics in particular. Can't be same masks.
The fools thing was aimed at the "my room lamp emulates light". It's even a rubbish analogy, because the lamp emits light.
If it was not made by Edison himself, then some in this thread seem to believe it should not really be a light bulb... And CFL and LED replacements are not light bulbs, so they must only be simulators...
-
All the Cardinals in the house say, hooooooe!
-
Perhaps it's time to restore this thread to it's original purpose.
I'll repeat the question that some people thought was an argument (understandable, seeing how it was worded), and this is about emulation on a normal computer. Whether an FPGA emulates or not isn't relevant here, and I'm not going to argue about that anymore in this thread.
Here goes:
Seeing how I've become interested in FPGA computing, I would like to play with this, and seeing how a switch (emulated relay using bits as signals) emulator on a computer shouldn't be too hard to write, I would like to know how easy or difficult such virtual circuitry would be to translate to actual circuitry that can be implemented using an FPGA (or with wires and transistors, or an ASIC, or...)?
Any pointers are appreciated :)
-
Seeing how I've become interested in FPGA computing, I would like to play with this, and seeing how a switch (emulated relay using bits as signals) emulator on a computer shouldn't be too hard to write, I would like to know how easy or difficult such virtual circuitry would be to translate to actual circuitry that can be implemented using an FPGA (or with wires and transistors, or an ASIC, or...)?
Once you have a logic description of your circuit, e.g. your switch emulator, there are automated tools that will convert it to something you can give to your FPGA or put it in ASIC. These tools or often free for some FPGAs and will cost up to a few $1k for making ASICs on advanced technology nodes. Look on web for 'boolean logic', 'logic synthesis' and EDA.
BTW, a transistor is actually a switch and in CMOS technology you basically have two types: a nMOS one that is open when input is high and a pMOS one that is closed when input is high. It depends on convention if high is representing a 1 or a 0.
These transistors (e.g switches) can also be used in regimes where it is not fully on or off and this is often called analog behavior (amplifiers, current mirrors, ...).
Look on the web for transistor.
greets,
Staf.
-
Is there any preference for nMOS or pMOS in regards to stability and noise immunity, or even propagation delay?
-
Seeing how I've become interested in FPGA computing, I would like to play with this, and seeing how a switch (emulated relay using bits as signals) emulator on a computer shouldn't be too hard to write, I would like to know how easy or difficult such virtual circuitry would be to translate to actual circuitry that can be implemented using an FPGA (or with wires and transistors, or an ASIC, or...)?
Any pointers are appreciated :)
Your relay sounds like a passgate. (also called a transmission gate in some circles) In an ASIC you might just put a passgate there, but this implies tristate wires which are frowned upon in modern design practices in terms of design using gates (logic gates I mean, not transistor gates). (be that verilog, vhdl, schematics, whatever, it's all a poor habit to be in unless there is particularly good reason for them) It's frowned upon as it implies the possibility of a floating input somewhere when all drivers on the net are "off"/disconnected. Floating inputs are bad, in that they can do weird things, which can be bad. So tristate busses, like you do see on PCB boards (PCI, Zorro, ISA, etc) are frowned upon inside a chip. Using a passgate can be troublesome in timing analysis. In my FPGA silicon days, we could not plan for timing because of inability to time through passgates. So we just built them, and thigns went as fast as things turned out to work right. It's also difficult to design an FPGA with timing/speed in mind, as what exactly needs to go how fast? You don't know what it will be doing in a customer design, so how do you optimize for that or have a particular goal?
In an FPGA, to do a passgate, you probably controlling a mux to pass the input value out or not. But in not passing the input value out, in an FPGA you probably need to pick an "off value", in that you can't pass a Z (complete disconnect), you have to pass (select) either a 1 or 0 (still connected to something). Proper design methods/habits/whatever need to be used, so rather than design using "relays" as you call them, you need to design using more appropriate elements. And that applies to all digital things inside the chip. (Analog chip design is a whole other world with whole other rules. I've only scratched the surface there as a layout guy, and know nothing of circuit design that we layout guys are given to implement)
-
BTW, a transistor is actually a switch and in CMOS technology you basically have two types: a nMOS one that is open when input is high and a pMOS one that is closed when input is high.
In CMOS, the N and P are used together. pmos are used on the high voltage side, and nmos on the ground side. nmos give a weak high voltage connection, and pmos give a weak ground connection, which is why we don't use one alone anymore. using pmos on high side gives a good high connection, and nmos gives a good ground connection, and together you have good connections to both voltages.
-
Good answers, guys, great :)
BTW, a transistor is actually a switch and in CMOS technology you basically have two types: a nMOS one that is open when input is high and a pMOS one that is closed when input is high. It depends on convention if high is representing a 1 or a 0.
Right, I just had a problem with transistors only having three pins, so relays seemed easier to emulate somehow.
Your relay sounds like a passgate.
I just meant normal relays, because they seem easier to use than transistors to me (and it's only about the basic idea of what a normal relay does, the emulator doesn't emulate any electrical charges, too complicated :)). Also, in my emulator there are only two states: 0 and 1, so that when you add two such signals together directly you basically get the effect of an OR (1+1=1 and not 1+1=2). Would that be a problem to translate?
Also, is there anything wrong with the basic idea of such an emulator?
-
To revive a year old thread, there is now an online simple class about FPGA chips that seems relevant to this. It does compare and contrast software running on a processor and hardware configuration of an FPGA, and talks some about how things work inside. I've finished 2 of 5 sessions now, and am enjoying it. (On another note, I've just finished a university course in Computer Architecture, also very enlightening and interesting stuff about the control logic of a processor)
http://university.eetimes.com/lecture-calendar.asp?cid=901#lecture_track_cgid_3
-
So after reading the entire thread (Why I did that I don't know) I came to the below conclusion:
FPGA = Emulation/simulation
UAE = Emulation/simulation
So I'll stick with my classic hardware :-)
-
Hey, I just got an email from Xilinx yesterday announcing that their new Vivado web pack edition was available for download...
Lurch: If you'd read the thread accurately, you'd have learned that:
FPGA = Reimplimentation
UAE = Emulation. ;-)
-
Yeah, logic is logic. As long as it isn't one computer simulating another, it isn't emulation.
-
FPGA is not emulation. It's the recreation of the physical chips under a reconfigurable chip.
Not really. If the setups were exact clones of the chip they intended to emulate, I might agree. As of now, for example an FPGA Amiga emulator are entirely different hardware setups that do (almost) the same thing as the original hardware, trying to emulate it as closely as possible.
I don't get why people somehow seem to think that FPGA/emulation are mutually exclusive.
-
Thirdly, some of the content you linked to uses other, more descriptive, terms to describe what's occurring, e.g. "FPGA-64 is a re-implementation of the Commodore-64 computer using reconfigurable logic chips." Re-implementation is a clearer way of describing the process being followed.
Unless you end up with the exact same configuration of gates, it's not a "re-implementation" in any sense that makes it distinguishable from "emulation". And really, a re-implementation of what? The hardware? Nope. FPGA-64 makes a particularly interesting example because its SID emulation is not anywhere close to how the real SIDs function. Hardware end-functionality? Nope, even if it's close or maybe even "getting there". End-user experience? Fuzzy, but have a look at the FPGA-64 changelog to get an idea of what bugs they've had to tackle to this day and ask yourself if it makes sense that they are somehow all magically weeded out by now.
The only ways to have these FPGA systems come close to the functionality of the systems they intend to emulate is either to try to get them into reproducible states in synch with the original systems and analyze the differences, or take a microscope to the chip surface.
One will make you insane, the other will not :)
-
Yeah, logic is logic. As long as it isn't one computer simulating another, it isn't emulation.
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.
-
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
-
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.
Yes, the logic isn't the same. It is emulation.
Even though the FPGA's have extra functionality, they can still emulate the old functionality enough to run the old software.
Like it or not, it's emulation. Nothing about the word emulate implies using a computer. It means one thing trying to behave like another thing.
-
So does that mean AGA chipset emulates ECS and ECS emulates OCS ?
-
Yes, the logic isn't the same. It is emulation.
Even though the FPGA's have extra functionality, they can still emulate the old functionality enough to run the old software.
Like it or not, it's emulation. Nothing about the word emulate implies using a computer. It means one thing trying to behave like another thing.
No, it isn't emulation.
-
No, it isn't emulation.
What do you think emulation is?
-
So does that mean AGA chipset emulates ECS and ECS emulates OCS ?
Sure, why not!? Merry Christmas...
Bit fed up with the religious wars... If it's not the original implementation, it's emulating the functionality of the original.
Why is emulation a "dirty word"? It's not, it's the future... Now lets get down to the important job of improving the quality of these FPGAs Amiga chipset emulation ;)
-
It was a rhetorical question but I agree, bring on the FPGAs!
-
No, it isn't emulation.
Care to explain your reasoning? This isn't a very constructive way to join a discussion.
-
So does that mean AGA chipset emulates ECS and ECS emulates OCS ?
Well, AGA certainly isn't OCS or ECS. It's compatible to some extent, but hey, whaddayaknow, some careless OCS/ECS programs won't work correctly with AGA unless you patch them because of low level incompatibilities. Whatever you call it, AGA itself is an extension of these designs.
-
So does that mean AGA chipset emulates ECS and ECS emulates OCS ?
Definitely for AGA vs ECS, apart from the blitter it was basically a new implementation.
AGA & AAA don't emulate ECS all that well either. The weird super hires mode palette is different in ECS to all the other implementations, which is why when ECS came out Commodore were telling people to use the OS or else. They only claimed compatibility for hardware hitting programmes that used OCS features. Commodore went so far as to not even release documentation on AGA registers, as AAA didn't emulate those either.
It was a rhetorical question
It's not a good example of a rhetorical question, it came over as a strawman. However I don't think you expected anyone to disagree with you.
-
em·u·late
3. Computer Science To imitate the function of (another system), as by modifications to hardware or software that allow the imitating system to accept the same data, execute the same programs, and achieve the same results as the imitated system.
All right... So, only the very first Amiga prototype which successfully ran some software is the original. All other Amigas 1000, 500, 2000, 600, 1200.. etc ever produced are emulators. So everything is an emulator, and we can stop this stupid discussion about emulation that pops up every now and then. Hopefully it will let people enjoy new FPGA hardware without obnoxious comments.
-
All right... So, only the very first Amiga prototype which successfully ran some software is the original. All other Amigas 1000, 500, 2000, 600, 1200.. etc ever produced are emulators.
They aren't emulators, they are computers that have have components that emulate others. Some old sound cards had soundblaster emulation, that doesn't mean that the computer you put it inside was just an emulator.
and we can stop this stupid discussion about emulation that pops up every now and then. Hopefully it will let people enjoy new FPGA hardware without obnoxious comments.
Discussing whether it's an emulator or not is not obnoxious. Even the "I don't like emulation but I like fpga's, therefore an fpga can't be emulation" standpoint isn't obnoxious.
A 68060 and PPC in an FPGA for the A1200 would be awesome.
-
Regardless of what you want to call the likes of the Replay (emulation, re-implementation, lamp post...) I'd be surprised if anyone would disagree that it will be hell of a lot closer to the original hardware that we love than WinUAE, and that is pretty impressive as it is. Even if you consider emulation a dirty word, this will not be like any emulation you have experienced before. There won't be any controller lag or host OS getting in the way.
Yes, you may have the occasional game or demo that doesn't work exactly as it did on your aWhatever, but I expect this to be rare once it matures, possibly even less than we get with OCS, ECS, AGA if we build enough configs for the different custom chips. For some apps you'll never get 100% compatible on anything but the exact original hardware it was written for (without patching), but we'll just have to suck it up or fix it. We already have to do this with our original hardware variants so I don't see the big deal.
-
They aren't emulators, they are computers that have have components that emulate others. Some old sound cards had soundblaster emulation, that doesn't mean that the computer you put it inside was just an emulator.
Yes they are emulators. See the definition. They had some modifications in respect to the prototype and they can accept the same data and execute the same programs. They are all emulators. You, me, and everyone else (except for DH and Amiga/Commodore engineers) have had nothing but emulators our entire lives.
Discussing whether it's an emulator or not is not obnoxious.
Yes it is. Regardless of whether you are right or not, and whatever the definition of an emulator might be, whenever someone feels excited about new FPGA stuff here comes one of the "captain technicalities" and drags on about it not being a real hardware implementation but only an emulation. It is damn right annoying and obnoxious.
If someone had a hand drawing of a computer and called it his Amiga I would support him, and not lecture him about that not being a real computer.
Be positive and supportive.
-
em·u·late
3. Computer Science To imitate the function of (another system), as by modifications to hardware or software that allow the imitating system to accept the same data, execute the same programs, and achieve the same results as the imitated system.
All right... So, only the very first Amiga prototype which successfully ran some software is the original. All other Amigas 1000, 500, 2000, 600, 1200.. etc ever produced are emulators. So everything is an emulator, and we can stop this stupid discussion about emulation that pops up every now and then. Hopefully it will let people enjoy new FPGA hardware without obnoxious comments.
Obnoxious comments? Do you feel like these facts (that are totally irrelevant from anything other than a technical perspective) impose on the experience of using these FPGA systems?
Oh, and no, I don't think your argument holds any water. In what way does it make sense to you?
-
Regardless of whether you are right or not, and whatever the definition of an emulator might be, whenever someone feels excited about new FPGA stuff here comes one of the "captain technicalities" and drags on about it not being a real hardware implementation but only an emulation. It is damn right annoying and obnoxious.
If someone had a hand drawing of a computer and called it his Amiga I would support him, and not lecture him about that not being a real computer.
Be positive and supportive.
I'm not sure where to go with that, I don't think I'd be excited if I ordered an FPGA arcade and a hand drawn picture turned up. Patronising people doesn't help them.
The FPGA arcade isn't an Amiga, it can emulate lots of different computers/consoles.
You only consider it dragging it down because you are being unsupportive and negative about emulators.
And yes, people emulate others.
em·u·late
/ˈemyəˌlāt/
Verb
- Match or surpass (a person or achievement), typically by imitation.
- Imitate.
-
Hi all, i didn't intend to rekindle an argument about what is or is not emulation. the links i posted go to a technical education series of webinars introducing fpga technology to newbies. I thought the op of this thread and some others would be interested in learning.
People designing with fpgas design circuits that are placed into the chip by configuration.
Whether or not you feel the result is emulation or not i don't feel like participating in again, though i do have my choice on that debate.
-
Obnoxious comments? Do you feel like these facts (that are totally irrelevant from anything other than a technical perspective) impose on the experience of using these FPGA systems?
Well, when someone says:
"Yaaay a cool piece of hardware, this is gonna be my new Amiga"
Do you feel that comments like:
"No no no, this is not a hardware Amiga this is an emulator BLAH BLAH BLAH sheets of text how this is an emulator and not the real stuff."
Actually help, or do something good ?
As I already said, regardless of whether you are right or not. Is it more important to be right at all costs, or to enjoy the good stuff with fellow Amigans ?
I like FPGA Arcade, I like NatAmi and hope it will pull through, and I will like and support whatever FPGA project comes next. Will buy some of them for sure. Probably all of them. But I, most certainly, would not like to listen to someone saying day after day after day how it's not this and not that.
Oh, and no, I don't think your argument holds any water. In what way does it make sense to you?
Check the dictionary definition I posted. I can stubbornly defend my point till the end of time (since there is no 21st apocalypse apparently) and pollute the thread to the point of unreadability. Would anyone want that ? Would it actually matter whether I can prove it or not ? Why aren't FPGA threads about support and contribution instead of proving that FPGA is emulation and not real hardware ?
@psxphill
I'm not sure where to go with that, I don't think I'd be excited if I ordered an FPGA arcade and a hand drawn picture turned up. Patronising people doesn't help them.
This is just it. Can't you take anything with a little humor and spirit ? Why does it have to be either 0 or 1 ?
The FPGA arcade isn't an Amiga, it can emulate lots of different computers/consoles.
You only consider it dragging it down because you are being unsupportive and negative about emulators.
And yes, people emulate others.
Yes, FPGA Arcade is not an Amiga, yes it can be lots of things.
No I have nothing against emulators, I use a couple of them actually (software ones).
Yes people emulate others as well.
And it is not a matter of you or me being right or wrong, or if we agree or not. It's about supporting projects for what they CAN do, not dragging endless discussions about what they are not. Are we on the same page here ?
-
I can stubbornly defend my point till the end of time (since there is no 21st apocalypse apparently) and pollute the thread to the point of unreadability. Would anyone want that ?
You appear to want that, I'm so sick of hearing that emulators are bad and fpga's isn't emulation that I can be just as stubborn as you.
Well, when someone says:
"Yaaay a cool piece of hardware, this is gonna be my new Amiga"
Do you feel that comments like:
"No no no, this is not a hardware Amiga this is an emulator BLAH BLAH BLAH sheets of text how this is an emulator and not the real stuff."
Actually help, or do something good ?
I only get involved when people are slagging off emulators and saying that using an fpga isn't emulation. My "contribution" to the debate is just as valid as theirs.
-
You appear to want that, I'm so sick of hearing that emulators are bad and fpga's isn't emulation that I can be just as stubborn as you.
Of course I don't want that. It's just an example how a pointless discussion can be dragged indefinite. This (and all other FPGA threads) are polluted enough as it is.
I don't think anyone ever said WinUAE is bad. Toni is doing such a great job that he has the respect of all Amigans in the world. Without WinUAE I wouldn't be able to prep a CF drive for my A600. Hats off to the man !
But many people seem to like FPGA projects more because they are tangible. Gives them something "real" to tinker with.
If someone gets a "better personal feeling", with FPGA, AROS x86, Mac MOS, or something else, how could you, and why would you want to prove otherwise ? Live and let live.
I only get involved when people are slagging off emulators and saying that using an fpga isn't emulation. My "contribution" to the debate is just as valid as theirs.
So in other words, you are behaving like a ten year old ?
-
So in other words, you are behaving like a ten year old ?
Sometimes you have to sink to other peoples levels when they throw a tantrum that you suggested that an fgpa is emulation. It's all they understand. If you could figure out a better way to shut them up then I'm all ears.
-
Just don't do it.
FPGA threads are FPGA threads. Of course they will attract some people who think FPGA projects are the best thing since sliced bread. Some will think it's better than sex, better than bacon. Some will think it's better than all classic Amigas just because it's brand new.
And who's to say they are wrong ? It's personal perception really. It's not emulation, it's not earthly at all, it's divine. Let them enjoy.
It's not like anyone said: "Hey you can submerge your Amiga in the bathtub while you're taking a bath".
Now that's a post for intervention :)
Instead of waging pointless wars, start a WinUAE (or some other emulator) thread and explain how they are useful, and why do you like them. When someone comes dissing emulators I will come and defend your point. Not because I like emulators better than FPGA or the other way round, but because I like everything for what it CAN do.
-
Just don't do it.
FPGA threads are FPGA threads. Of course they will attract some people who think FPGA projects are the best thing since sliced bread. Some will think it's better than sex, better than bacon. Some will think it's better than all classic Amigas just because it's brand new.
And who's to say they are wrong ?
You're getting confused between me saying that the fpga is emulation and whether I like fpga's.
I already have a 1541ultimate2, which is a 1541 emulation in an fpga. I would probably buy a fpga arcade when it becomes available.
-
No, I understand you perfectly.
But some may like FPGAs more than you and I. Or have their own definition of emulators.
Why carry on the discussions whether FPGAs are better than something or not, or are they emulation or not ? To some, if they are not ASICs then they are emulators. To others, if they can knock on it and they make a sound then they are "real" and not emulators. To some, they will be emulators no matter what, since they are not Moto's CPUs. So what ? Bring them on and let us see what they can do. Why argue semantics ?
-
What I and others have disagreed with is the purity control folks who think that this is somehow more pure than UAE. You may like the hardware emulation of FPGA more than the software emulation of UAE, but they are both valid ways to get a Classic Amiga like experience on modern equipment. One's not superior to the other, they are just different approaches. The last thing we need to to divide ourselves into more camps.
-
Yes, the logic isn't the same. It is emulation.
Even though the FPGA's have extra functionality, they can still emulate the old functionality enough to run the old software.
Like it or not, it's emulation. Nothing about the word emulate implies using a computer. It means one thing trying to behave like another thing.
Oh I see. So if you run an ECS game on an A1200, I guess that's emulation?
-
As many have said, it is not emulation. It is re-creation. Like all re-creations how accurate it is depends in the information you have on the original.
AGA was also a re-created Amiga chipset but the engineers had the original design chip schematics, something the developers today do not have.
I'd be surprised if anyone would disagree that it will be hell of a lot closer to the original hardware that we love than WinUAE
I disagree. :-P
Why doesn't WinUAE 'feel' like your original Amiga? I ran WinUAE on my Iiama Vision Master 450 Pro at 50Hz with VSYNC for many years and it felt very close. Could it be your setup? I used a monitor capable of an exact multiple of the Amiga framerate (50Hz, 60Hz, 100Hz) forced this using powerstrip and enabled VSYNC. This makes all the difference to me.
-
Whether or not you feel the result is emulation or not i don't feel like participating in again, though i do have my choice on that debate.
Nice thing about language is that it is not an exact science; even dictionaries are just a snap shot of the what a word means at a certain point in time. So you can claim all people in this thread are right, as well as they are all wrong :). I just love reading these threads and they can go on forever...
All the best!
-
Oh I see. So if you run an ECS game on an A1200, I guess that's emulation?
You're being too vague. What do you guess is emulation?
Going into the early boot menu and disabling the caches on your 68020 so it emulates the behaviour of a 68000, or setting the chipset to OCS so that it disables 32 bit fetches so that it emulates the OCS chipset more closely.
There is some emulation going on there, it's probably not what you think of as emulation.
Whether you use an a500, WinUAE or FPGA arcade. It's not going to look the same on a modern LCD as a 1084. I still use old commodore/philips monitors for this reason.
-
As many have said, it is not emulation. It is re-creation. Like all re-creations how accurate it is depends in the information you have on the original.
AGA was also a re-created Amiga chipset but the engineers had the original design chip schematics, something the developers today do not have.
I disagree. :-P
Why doesn't WinUAE 'feel' like your original Amiga? I ran WinUAE on my Iiama Vision Master 450 Pro at 50Hz with VSYNC for many years and it felt very close. Could it be your setup? I used a monitor capable of an exact multiple of the Amiga framerate (50Hz, 60Hz, 100Hz) forced this using powerstrip and enabled VSYNC. This makes all the difference to me.
WinUAE runs under a deffective OS: it's software broken by definition.
-Running on a propietary closed-source OS means you depend on Micro**** to have a compatible OS.
-And more importantly: Windows is a broken OS, bloated an slow, wich you can't optimize much. There's no real way to ensure the defective OS won't take CPU from WinUAE to run any ****ty app in the background and cause desyncs, stalls or slowdowns. A real OS where you can configure and even modify scheduler is needed to avoid this broken emulation.
-Windows adds a lot of output delay.
It doesn't mind if you run on a 50Hz display. I did that on the past and you get smooth scroll etc, but it's a broken and immoral OS you're running under the hood anyway. It's NOT how an Amiga looks and feels.
Now an FPGA implementation IS an Amiga. It looks and feels exactly the same. Response is the same. It isn't a total and absurd waste of resources like WinUAE solution is.
WinUAE can be a tool for poor Windows slaves to work with HDF files and all that, but that souldn't be considered an Amiga Computer replacement. No way.
-
I disagree. :-P
Why doesn't WinUAE 'feel' like your original Amiga?
Consider me surprised :)
I'm not suggesting a dislike for WinUAE, but for me, it can be less immersive having windows getting in the way. A good Win7 setup helps a lot, but your millage may vary. I'd rather remove the OS from the equation and have a dedicated machine (but not in an AROS x86 way). It's like a temperamental 500W sledgehammer to crack a lemming shaped nut.
Back in the day I only had a 14" TV so it's more about the gameplay experience than the exact visuals.
The FPGA system also has other benefits: the wife doesn't like the amigas in the living room, because of all the space and cables. With this I can stick it to the back of the telly and just plug in joysticks as required.
-
WinUAE runs under a deffective OS: it's software broken by definition.
-Running on a propietary closed-source OS means you depend on Micro**** to have a compatible OS.
-And more importantly: Windows is a broken OS, bloated an slow, wich you can't optimize much. There's no real way to ensure the defective OS won't take CPU from WinUAE to run any ****ty app in the background and cause desyncs, stalls or slowdowns. A real OS where you can configure and even modify scheduler is needed to avoid this broken emulation.
-Windows adds a lot of output delay.
Your argument became absurd when you changed Microsoft to put a swear word in.
Are you saying that UAE on Linux or MacOS is ok? In which case just don't run Windows.
-
At least I know FreeBSD or Linux works better. But any multitasking especially non-realtime OS is going to produce a less responsive experience.
However an FPGA can produce accurate timing to most system components.
-
UAE originated on Linux, it was ported to MS Windows. Having an underlying OS doesn't really matter since you are emulating a system that doesn't have much CPU power. I will give you that FPGA is a more efficient emulation, allowing for emulation on a much less powerful host, but is it going to be cheaper?
(http://1.bp.blogspot.com/-_m5KMltPGrE/UM85lpOX8TI/AAAAAAAACKw/tJuoD14k6OA/s1600/animated-dancing-santa-clause.gif)
-
The question is to ask:
Will it be more accurate?
What is the most sucessful way to do MFM decoding or that matter GCR from disc?
* Write it in BASIC using INB .. on a single user system?
* Write it in C using inb() on a multiuser system?
* Write it in assemble using inb xx on a bare bones system?
* Code it as an hardware description (HDL) equalient ?
* Wirewrap it with 7400 circuits?
* Etch an ASIC at horrendous cost?
Recall that these signals come at a synchronous specific time and doesn't wait for anything. And you need to listen to them with precision and act on them on time, all the time. There's also DRAM signals, bus responses, video generation, communication etc that all need the right response on time.
Add the complexity of several way more complicated circuits that all act in parallel with defined realtime responses. If you try to implement this on a single CPU system you will need to find out which signals that need hard realtime response and do a check-and respond to all those signals without ever delaying outside time boundaries. This means system response will be dependent on the total service loop execution time. A huge liability. The other liability is that this signal servicing will not be in lock step with the system as a whole and thus introduce time jitter..
(a multi-CPU system makes this easier, but it still suffer from the same fundamental flaw)
When the possibility exist to model a signal system which is what the electrical circuitry really implement. The design thought process can focus on the modeling instead of explicit response times and time critical signal hooks. And when the model is correct it will "just work(tm)". Instead of having to figure out how to implement this as sequential code. So it is in the essence signal path description vs sequential code equalient.
As bonus that comes from being unimpeded by central clock phase, cache, logic bare bone etc one can interact with real hardware interfaces. A PC with a 2 GHz CPU should be able to respond to an I/O within 3 instructions so in the ballpark of 1.5 ns. But real life test rarely finds the parallel port respond faster than 1000 ns.
I hope this gives some understanding on the issues that FPGA/CPLD/7400 etc makes it possible to deal with efficiently.
-
@freqmax
I get your point, but I would have used something other than a legacy port that doesn't exist on most modern computers to make it. Your should be able to get better emulation faster and simpler through an FPGA system. But in reality it's not going to make a difference to the vast majority of folks who just want to play old familiar games.
-
I guess some games/demos just won't be themself in an environment that lack signal precision.
-
I can see the idea of pulling the old dead motherboard out of an Amiga and sticking one of these in though. These electronics are getting really really really past their use by date and some day they just aren't going to turn on again, better to have something that at least pretends to be an Amiga to stick into it.
-
WinUAE runs under a defective OS. Windows is a broken OS. it's a broken and immoral OS you're running under the hood anyway. It's NOT how an Amiga looks and feels.
I'm getting the feeling you don't like Windows?
Replace WinUAE with FS-UAE and re-read :)
It looks and feels exactly the same. Response is the same. It isn't a total and absurd waste of resources like WinUAE solution is.
Maybe a waste of resources but it is a hell of a lot cheaper! (P.S. They don't feel the same...)
-
When the possibility exist to model a signal system which is what the electrical circuitry really implement. The design thought process can focus on the modeling instead of explicit response times and time critical signal hooks. And when the model is correct it will "just work(tm)". Instead of having to figure out how to implement this as sequential code. So it is in the essence signal path description vs sequential code equalient.
Actually it's software emulation where you can focus on modelling the original hardware, writing code for an fpga is much harder. Ram access for instance is free with software emulation, but on an fpga you're not only emulating ram but you're having to talk to modern ram as well. 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.
Most software emulation inaccuracies come down to lack of understanding about how the original hardware works. That understanding doesn't magically appear because you're writing code for an fpga.
Sometimes it can be due to conscious decisions to keep make it run fast enough, like if you're running an old emulator that was designed for a previous cpu generation. I don't know if that's the case with WinUAE as I haven't looked at the code, but it's been around a long time.
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.
You could for instance write a software emulator that locks all it's memory so it can't be paged out and run it at a high priority.
-
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
-
In theory perhaps, although usually you are not in control of the entire software stack.
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.
how does it actually get audio or vidio data out to an external device in real time?
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.
If you're worried about it then I'd recommend using a 1084.
tricky as hardware is inherently parallel and I assume you are running a single CPU to do your emulation
Today you'd use a single CPU core, but that isn't a big deal. While hardware is parallel, everything gets triggered off clock edges which effectively makes it sequential. Each clock tick might require 100 actual instructions, but think of those as propagation delays. It all works out in the end and nobody notices.
-
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
-
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.
Some graphics cards can be configured to produce the correct frame rate when running fullscreen. Otherwise you'd need to transcode it. There is an msx emulator that does 50hz to 60hz transcoding that is supposed to be very good.
-
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
-
but it will always be more laggy as you need to hold this to the next vsync.
Yeah, you'll get a frame of latency, but on modern displays one frame is the least of your problems.
Unless the video clock is locked (it won't be) then you will always get tearing
Tearing only comes from frame rate differences, pixel clock is irrelevant. You may be able to get the exact frame rate, depending on the graphics card. But if you can't then you don't have to have tearing, you can use various techniques for generating the number of frames the graphics card wants from the source video. There are people claiming good results for 50fps -> 60fps transcoding, so you can run PAL games on a TV/monitor that only supports 60fps. I don't know how well it looks for
something like 59.9hz -> 60hz (I don't know whether the Amiga outputs NTSC as 59.9fps or 60fps and whether PC monitors that say 60fps actually support 59.9fps).
If you need to then Powerstrip can be used to generate custom modes on the fly & it works on most graphics cards
Speeding up/slowing down the frame rate is simpler, but then you have to time stretch and then pitch correct the sound. You'll notice with an A/B test as the frame rate will drift eventually, you'd get accuracy issues with things like serial port output or CIA TOD clock.
-
One technique could be to let the software emulator draw a complete screen. Once completed it's sent off to a FIFO that will display them. However any difference in frame rate will cause you to have tofew or to many. So you will have to interpolate or morph frames, that will require at minimum 2 frames and the latencies incurred. Not to mention the blurring.
Math is a bitch ;)
So I agree with all of MikeJ:s statements.
-
So I agree with all of MikeJ:s statements.
I understand his points, but on most computers you can set the refresh rate so it matches the Amiga's output anyway. For those cases when you can't then there are various techniques that have their own pros and cons.
Post processing and latency is something that you have to put up with modern TV's. So unless you're going to use a 1084 then any argument you're going to use against software emulation is going to be equally valid for an Amiga.
That isn't something that is generally considered part of the accuracy of the emulation, it's considered part of the human experience.
Feel free to say that real hardware or an FPGA based Amiga can offer a better human experience.
-
Yeah, everything will have latency on LCD monitors, but the less the better.
I really couldn't care less if the refresh rate matches the real hardware exactly, as long as it syncs up properly. A speed difference of less than a percent isn't going to be noticeable.
-
I don't know if it's the sound, graphics or input that is delayed (well, the sound definitely is on my systems) in WinUAE (most likely all three) but I definitely lost an important sense of immediacy when using it instead of a real computer. Of course it has the benefits of scaling in raw processing power with your processor, and the amount of peripherals you can simply emulate, but other than that I can't see any reason to use a software emulator over a hardware one.
Apparently the input delay issue have improved with the last few releases, but I'll happily wait for the Replay board before I use anything other than my A1200 for Amiga stuff again.