org:
How you approach your project depends very much on your personal objectives for the project. You've spent a considerable amount of time studying the circuitry of the original 6502. In my opinion, it uses a non-overlapping two phase clock in order to use the latches in its design. I personally appreciate very much the solution that the design team applied. Using their latch based design approach, they were able to achieve an all around efficient implementation and deliver high performance with low clock rates; their design should be required for study by all chip designers.
Myself and others (Arlet Ottens, Rob Finch, BigEd/ElEctricEyE, Jens Gutschmidt, etc.) have all implemented various flavors of a 6502 FPGA core. Each solution is different. I like mine, but I also have great appreciation for those of the others I've mentioned. Most of us implemented our cores for the purpose of learning the processor, learning the HDL used to implement it, etc.
In providing my comments to you, I don't want to discourage you from taking whatever approach you want to take. I think there are many ways to implement a processor such as the 6502, and whatever approach you use will be best for you.
After all that, if you want to make use of the inherent concepts of the 6502 in your implementation, then I would recommend that you use the basic cycle divisions in the 6502. That is, the address is generally calculated during the Phi1 high phase, and the memory is read/written during the Phi2 high phase. Generating non-overlapping clocks like Phi1 and Phi2 can be done using a 2x clock. If strict adherence to non-overlapping clock is relaxed somewhat, then it is possible to use a single phase clock and use the first half to correspond to Phi1, and the second half to correspond to Phi2.
Under these conditions, I would use the falling edge of the clock to register the output of the address generator and the rising edge of the clock to register the data read from memory. To create a RnW signal valid during Phi2 high, I would use a DDR output register. This view of the clocking corresponds roughly to using the falling edge of both Phi1 (end of the address computation phase) and Phi2 (end of the memory access phase). (Note: I provided one of these as an example for enso about a year ago for his CHOCHI project. When you're ready to tackle the I/O off your FPGA, let me know if you'd like a copy.)
As to the ALU model that you provided, I will comment on one thing. The real 6502 uses a number of techniques based on the technology of the time. One of these is the pre-charging of buses and the transference of signals from its storage latches onto the bus using pass gates. This feature of the 6502 cannot be implemented in any way on a modern FPGA. Except at the boundaries of the FPGA, i.e. the output drivers, Xilinx (and I suspect most other FPGA vendors) have long since eliminated any tri-state drivers in the FPGA fabric. Although you use a tri-state bus driver in your model to model the 6502 buses, this construct is only available in a simulator. The circuits in an FPGA itself cannot implement such a function. The synthesizers recognize the construct and implement the bus as a wired-OR (default to logic 0) or a wired-AND (default to logic 1) bus using standard totem-pole logic. Thus, when you get to synthesis, you may get an error message such as "multiple drivers found on xxx".
As I said above, I don't want to discourage your efforts, but I also want you to be aware of what I think may be some misconceptions regarding FPGAs. Unlike a chip implemented using a silicon compiler, like those used to create FPGAs, a synthesizer targeting an FPGA must use only the circuits already implemented in the silicon of the FPGA. Thus, any designs targeting an FPGA must be acutely aware of the capabilities built into the silicon of the device. Verilog and VHDL are hardware description languages, and as such the primary focus for these languages has been hardware modeling not hardware design. They support a broad range of hardware modeling activities, and not all simulation models can be targeted to an existing device like an FPGA. Therefore, I suggest getting out the data sheet and user guides of the Spartan 3 and Spartan 6 FPGAs (or the Altera Cyclone FPGAs) to get a clearer understanding of the capabilities of the silicon itself.
_________________ Michael A.
|