FPGA x86 Processor
code.google.com
code.google.com
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 x86 (legacy) infrastructure. Not sure how much you need to boot and make Windows work for example. It may get nasty. A20? Chained interrupt handlers? DMA controllers?
If this is his final EE project as said on the page, in my opinion the main focus of the project is to have a working proof of concept of an implementation of a X86 processor on a FPGA.
He wouldn't have the time to build a fully ready to market X86 processor all by himself, I think.
Not saying that its simple to implement an 8086, but it should be significantly easier than implementing an 80386/80486 (which is what one would expect today as a minimum when referring to it as x86).
Maybe he can boot FreeDOS then (not sure if it uses i386 mode, probably not)
It would be nice to boot, to show something, maybe even play an old game
[1] http://www.amazon.com/Computer-Architecture-Quantitative-App...
You mean a processor where all of the complex opcodes are implemented in loadable microcode?
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.
yeah, or a Foonly...
If bochs doesn't do enough, it would probably be easier to hack it up to do what you need.
You might try instrumenting bochs, which might both run your code faster, require less hardware and give you more accurate results. In many ways, bochs is much better built for the type of thing you want.
edit: grammar
[1] http://software.intel.com/en-us/articles/pin-a-dynamic-binar...
I don't want to be working at that level every day but it sure was a fun project.
Oh, OS courses at the university... good old time. (Some participants complained that going from zero to bare-metal x86 was too difficult.)
Honestly, when I'm debugging hardware where I have the high level specifications, the microarchitecture spec and the system verilog files that implemented the design it's still kind of a pain to trace things.
The other downside of having all the signals is that little things can be unintentionally misleading. As an example I was working with coworker trying to trace a memory transaction through some complicated logic blocks and there was a point we originally missed where the bottom few bits of an address aren't necessary for the hardware. Later after this point the bottom bits were reused to communicate transaction properties along with the significant address bits. There was a bit of confusion about why we were reading a "bad address" before we realized what happened.
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?
That's only supposed to be 4000 words. A project like this could turn into a book.