Live data from Hacker News

FPGA x86 Processor

code.google.com

21–30 of 39 posts

Re: FPGA x86 Processor

#21
post #20

This is awesome. One of the running bets I've had is how many chapters of Hennesy [1] you can implement in an FPGA. Early on it was hard to do more than basic RISC architectures, the 6502 Etc. Then you could do the Z80 which was a good cisc variant that had some excellent code tests. The 8086 and 68000 make for good follow on targets. At some point we should be able to do a VAX, its sort of a local maximum of CISCyne…

> At some point we should be able to do a VAX You mean a processor where all of the complex opcodes are implemented in loadable microcode?

That's the one! I happen to have what is a fairly complete collection of all of the 'chip' VAX cpus (for Qbus) starting with the KA610 (MicroVAX I), through the KA692 (VAX 4000/700a), and its fascinating to watch the architecture go from a nearly pure microcode implementation to a nearly pure 'gate' implementation. From the perspective of looking at the tradeoffs of microcode vs gates it is really an excellent tutorial on computer architecture.

Re: FPGA x86 Processor

#22

Good luck, this is very, very hard Why? Having tested an x86 processor from a 3rd party manufacturer (not the big ones, and not even the 2nd league) - Bios. Including ACPI stuff. So Windows XP would boot, with linux some would boot, some would work but with instabilities, some would not boot - Minor incompatibilities and every nook and cranny of the x86 spec. - Drivers for everything your board does different - The x…

AFAIK a lot of the IBM PC legacy are already required for the legacy PC BIOS.

Re: FPGA x86 Processor

#24
Hmm, besides being from 2009, this looks very very incomplete, there's almost no real functional code, just a multiplier, divider, and a simple ram module (and not sure if any of those work properly...). So all in all, not too exciting, unfortunately.

Re: FPGA x86 Processor

#25
post #20

Earlier quoted context omitted.

> At some point we should be able to do a VAX You mean a processor where all of the complex opcodes are implemented in loadable microcode?

That's the one! I happen to have what is a fairly complete collection of all of the 'chip' VAX cpus (for Qbus) starting with the KA610 (MicroVAX I), through the KA692 (VAX 4000/700a), and its fascinating to watch the architecture go from a nearly pure microcode implementation to a nearly pure 'gate' implementation. From the perspective of looking at the tradeoffs of microcode vs gates it is really an excellent tutori…

If we want a microcoded architecture, I'd prefer the PDP-10, but that's me.

How much more complex is a mostly-microcode VAX implementation compared to a MIPS? The point about being able to move stepwise up the hardware complexity ladder by progressively replacing microcode with gates is a really good one, though.

Re: FPGA x86 Processor

#28
post #20

This is awesome. One of the running bets I've had is how many chapters of Hennesy [1] you can implement in an FPGA. Early on it was hard to do more than basic RISC architectures, the 6502 Etc. Then you could do the Z80 which was a good cisc variant that had some excellent code tests. The 8086 and 68000 make for good follow on targets. At some point we should be able to do a VAX, its sort of a local maximum of CISCyne…

> At some point we should be able to do a VAX You mean a processor where all of the complex opcodes are implemented in loadable microcode?

You're thinking of the Perq (http://www.chiark.greenend.org.uk/~pmaydell/PERQ/). The VAX was probably implemented with microcode, but it wasn't that modifiable.

Re: FPGA x86 Processor

#29
post #5

My god, the ability to use this for tracing code makes me more excited than anything I've seen in a while. The debugging facilities on x86 are, well, limited to the point of being damn near useless. I may spend some time hacking solid trace functionality into this, if it ends up being an open core.

For such purposes, binary instrumentation is probably a more proper tool. Various options out there, I personally prefer Pin [1] because it's extremely robust and gives you good control of the overheads from instrumenting.

edit: grammar

[1] http://software.intel.com/en-us/articles/pin-a-dynamic-binar...

Re: FPGA x86 Processor

#30
Most of the implementation is based on Zet http://zet.aluzina.org/index.php/Zet_processor and cpu86 http://www.ht-lab.com/freecores/cpu8086/cpu86.html as mentioned in the project description. The Zet implementation can already run several DOS games on a pretty low-end FPGA board like the DE1, but only does the older 16-bit instructions.

Not sure what he tries to accomplish, but it seems like a small system based on a CPU, memory, VGA controller(? not seen) and a 16550 UART and a lot of tests to proof correct implementation?

Post reply on HN