hoglet wrote:
No I haven't - it's not a tool I'm particularly familiar with.
My new verilog 65C02 core.
Re: My new verilog 65C02 core.
It's quite easy to use. Just go to Tools/Smartexplorer/Launch, set it for Timing Performance (probably default), and click OK. It will run a bunch of different strategies, and return a table with results. You can pick the fastest, and set it as default.
Re: My new verilog 65C02 core.
The timing results I reported earlier were all done on -3 speed grade on a SLX9, with single 2kB code/data RAM.
On my test board I have a SLX4 with speed grade -2, and I've only been running it at 50MHz.
On my test board I have a SLX4 with speed grade -2, and I've only been running it at 50MHz.
Re: My new verilog 65C02 core.
hoglet wrote:
Anyway, keep up the good work, it's been fun debugging these (minor) issues.
Re: My new verilog 65C02 core.
For the distributed version, I have decided to return to a similar kind of state machine I had in my first core. The idea is to only replace the CTL module with a different one, and keep the other modules as they are. That way, you can quickly swap out one design for the other, and see which one fits your project best.
I spend a lot of time going over different possibilities, but I can't think of anything better than what I had. I will save a few states, because there are fewer cycles per instruction, and several addressing modes are collapsed into one.
The nice part is that the data path is already done, and I already know what needs to happen in each instruction cycle.
I spend a lot of time going over different possibilities, but I can't think of anything better than what I had. I will save a few states, because there are fewer cycles per instruction, and several addressing modes are collapsed into one.
The nice part is that the data path is already done, and I already know what needs to happen in each instruction cycle.
Re: My new verilog 65C02 core.
I made a first draft version of the FSM (finite state machine) version of the control logic. You can see the Verilog source here.
It's only a start, but I thought I would put it on github, so you could follow along with the design, if you're interested.
The first 120 lines are just a trimmed down version of the old CTL module, with all references to the ROM removed. Below that is the new state machine code. For each of the control output signals (WE, do_op, alu_op, reg_op), there's a case statement that uses current 'state' to determine the operation select value, which are the same as for the microcode ROM.
There are a couple of loose flops (ind, jmp, rmw) that hold some additional state, in order to keep number of states a bit smaller.
At the bottom (line 314) is the state machine update logic. I have 14 instructions supported right now. These represent all the different types of addressing modes and special instructions (like JSR/RTS). Branches are still missing, but for every other class of instruction, there's a representative opcode present.
There are no flag updates, no ALU operations (except those needed to update stack pointer), no register updates. I first like to get the skeleton state machine running that can walk through the code without losing track of the instruction stream.
It's only a start, but I thought I would put it on github, so you could follow along with the design, if you're interested.
The first 120 lines are just a trimmed down version of the old CTL module, with all references to the ROM removed. Below that is the new state machine code. For each of the control output signals (WE, do_op, alu_op, reg_op), there's a case statement that uses current 'state' to determine the operation select value, which are the same as for the microcode ROM.
There are a couple of loose flops (ind, jmp, rmw) that hold some additional state, in order to keep number of states a bit smaller.
At the bottom (line 314) is the state machine update logic. I have 14 instructions supported right now. These represent all the different types of addressing modes and special instructions (like JSR/RTS). Branches are still missing, but for every other class of instruction, there's a representative opcode present.
There are no flag updates, no ALU operations (except those needed to update stack pointer), no register updates. I first like to get the skeleton state machine running that can walk through the code without losing track of the instruction stream.
Re: My new verilog 65C02 core.
I've added support for branches. Note that if you click on the link above, it takes you to the most recent version of the code.If you want to see the history, go here
Re: My new verilog 65C02 core.
I just had an idea to make the control logic more readable. Instead of having half dozen case statements, and figuring out all the don't cares, I made a big case statement. For each opcode, there's a vector with a bunch of bits that are loaded into flops during decode cycle, and then used in various places, controlled by state machine. It's a similar concept as the microcode table, but much more compressed, because it only specifies a single ALU operation per instruction, rather than an ALU operation for each cycle. The idea is that the tools will do a good enough job of generating small logic for each bit, helped by using as many don't cares as possible.
Code: Select all
always @(posedge clk)
if( sync )
case( DB )
// SH ADD CI W DR SRCR
8'h00: control <= 20'bxx_xxx_xx_0_xx_xxxx; // BRK
8'h01: control <= 20'b00_000_00_1_10_0010; // ORA (ZP,X)
8'h04: control <= 20'b00_000_00_0_xx_0010; // TSB ZP
8'h05: control <= 20'b00_000_00_1_10_0010; // ORA ZP
8'h06: control <= 20'b10_000_00_0_xx_0111; // ASL ZP
8'h08: control <= 20'bxx_xxx_xx_0_xx_xxxx; // PHP
8'h09: control <= 20'b00_000_00_1_10_0010; // ORA #IMM
8'h0A: control <= 20'b10_000_00_1_10_0010; // ASL A
8'h0C: control <= 20'b00_000_00_0_xx_0010; // TSB ABS
8'h0D: control <= 20'b00_000_00_1_10_0010; // ORA ABS
8'h0E: control <= 20'b10_000_00_0_xx_0111; // ASL ABS
8'h10: control <= 20'bxx_xxx_xx_0_xx_xxxx; // BPL
8'h11: control <= 20'b00_000_00_1_10_0010; // ORA (ZP),Y
...
Re: My new verilog 65C02 core.
Just to let you know, I am folllowing along, and watching the commits as they fly past!
I like where you are heading...
I like where you are heading...
Re: My new verilog 65C02 core.
I was thinking that all those x's in the table could be dangerous, if they always get simulated as zeroes, but optimized to random values in synthesis.
Luckily, Verilator has some command line options to set x=1, or to a random value. I can run the test suite a couple of times with different values for x, and make sure it passes all the times.
Luckily, Verilator has some command line options to set x=1, or to a random value. I can run the test suite a couple of times with different values for x, and make sure it passes all the times.
Re: My new verilog 65C02 core.
hoglet wrote:
I like where you are heading...
I thought it was a nice touch.Re: My new verilog 65C02 core.
Instruction handling is (hopefully) complete now. Still to do: make dinner, flag updates, reset and interrupt handling. Probably still some mistakes in the table, but I can't run the test suite without flags (fails after 25 cycles)
Re: My new verilog 65C02 core.
As soon as you have a version that passes the Dormann 6502 tests, I'll give it a try in the Beeb.
Re: My new verilog 65C02 core.
Ok, probably not today. I've added the flag support, but I realized that the TSB/TRB instructions won't set their flags correctly. Also, decimal mode isn't done yet.
I should be able to run Dormann's tests now, with BCD disabled. Made it 337 cycles ! More than 50000 cycles now.
I should be able to run Dormann's tests now, with BCD disabled. Made it 337 cycles ! More than 50000 cycles now.
Re: My new verilog 65C02 core.
Passes Klaus Dormann's test suite now (only tested NMOS), with BCD disabled. Still no interrupts, reset, or TSB/TRB.
I'm done for today. I'll finish it tomorrow.
I'm done for today. I'll finish it tomorrow.
Re: My new verilog 65C02 core.
Arlet wrote:
Passes Klaus Dormann's test suite now (only tested NMOS), with BCD disabled. Still no interrupts, reset, or TSB/TRB.
Can you also add RDY to the TODO list?
Arlet wrote:
I'm done for today. I'll finish it tomorrow.
Dave