| ??? 12/13/07 05:07 Read: times |
#148125 - It doesn't look too difficult yet ... Responding to: ???'s previous message |
Richard said:
A lot depends on what your goals are.
If you want a faithful recreation of the Intel debacle, with all its failures, including that apparently unreliable postive-going reset, then you'd probably take one approach. If, on the other hand, you want an efficient, high-performance core that consumes a minimal amount of the resources in your programmable logic, you might consider something different. Well, as with my Morse code decoder, the primary goal is to become proficient as an FPGA user. This project is just a means to that end. Having said that, I think it would be silly to simply duplicate what Intel did. For one thing I'm not sure it's possible to discover exactly what they did. Then of course the game is completely different now, given the wealth of resources that's available on the FPGA. So what I'm after is something that strikes a happy balance between simple and fast. I don't care so much about conserving the FPGA resources. For my purposes, they're there to be squandered. If you design an ALU that does everything that's needed, including operations on the DPTR, SP, PC, etc, then the multiplier and divider are the only real challenges. I don't agree with this approach. It seems to me that the Harvard architecture simply screams for concurrent operation of the code fetching mechanism and the other side that manipulates the data. I haven't thought about it very much, but it seems like trying to run everything through the same ALU would make an instruction like LCALL and long, drawn-out ordeal. Is it really that expensive to dedicate an adder or two for things like incrementing the program counter and calculating relative jump addresses? I guess I'll find out! After all, improving performance above what you can buy is just about the only justification for building an MCU in FPGA. Wrong in my case. See above. If you treat SFR's, Internal data memory, external data memory, and code memory as distinctly mapped memory regions, with registers as a special case, things easily fall into place. Think about it! I have thought about this. I agree that the SFRs, registers and internal data memory should all be thought of as the same. However, I think the code memory obviously falls on the "other side" of the Harvard architecture, and that the 16-bitness and limited instructions for accessing XDATA makes it different enough from the internal memory that it should be separate. You'll see these opinions reflected in my block diagrams. -- Russ |
