How about using $00A9 for LDA and $01A9 for LDB. That way you can use bit 8 as an override bit to switch from 'A' to 'B'. It's a small change, and it works seamlessly for any instruction currently using 'A', including LDA, STA, ASL A, PHA, TXA, or TAY. It is also easily extended to 'C' and 'D' accumulators by using an additional instruction bit.

I think I follow you. So it should look something like this?:

No, because now you have overlapping cases. For instance, the INX opcode now matches both SEL_X and SEL_A.

For SEL_X, SEL_Y, and SEL_S, bit 8 can be a don't care. So you could write something like this:

And similarly for SEL_Y and SEL_S. For SEL_A/SEL_B, something like this:


Basically, whenever something doesn't apply to the accumulator, just put an 'x' instead of a '0' in bit 8 position. When it does apply to the accumulator, add in an extra mux for bit 8 to choose between A and B. ETA: instead of using the "? :" operator, you can also add extra cases, but then you'd have to list all opcode patterns matching the accumulator(s), without overlapping any of the X/Y/S based patters.

Excellent! I believe it's working. I was able to see the B reg change value to the $00A5 I had in LDB #$xxA5. That's it. A very small Sim.

This is exciting to think of how many more opcodes just came to life! I have to wait until I get on a real computer to do some further testing because this laptop is agonizingly slow. Hopefully I can post an ISim tonight of a simple program:

This is awesome. It is working! I/we have a B Accumulator!
Will post a Sim soon after I get a better program than above to display proof of opcode recognition within the core. But the program above worked as expected on ISim... I would just like to include most if not all of the opcodes that use the Accumulator in a short cycle program.

Now, an observation about this line of code (which does work by the way):

After I got home from work tonight, I had to go read my 'Digital Design Using Digilent FPGA Boards (Verilog Edition)' by Haskell and Hanna and see how they implemented a 2 to 1 MUX, a very basic building block one must know the syntax of, obviously I do not. But I want to learn...
I saw the very same syntax as above, on pg.69. In their example, the expression was: which reads: 'if s is true (logical 1) then y=b, else y=a.

Now I will quote them regarding this syntax: "This shortcut method of writing an if statement was inherited from the programming language C but its use should be discouraged because it is more difficult to understand than writing out the if statement as in Listing 5.3"
Listing 5.3 goes something like this:

But, can we put an IF statement after a Default?
__________________________________________________________________________________________________________________________

The 2:1 MUX is good for IR[8] to choose SEL_A or SEL_B.

Now, going forward to the C and D Accumulators in addition to the A and B Accumulators, we will need a 4:1 MUX to put the DCBAXYS regsel data into the src_reg or dst_reg. I might be tempted to write something like this:

or this:

but it seems this is not the proper syntax...

I doubt it. IMO it's the difficulty of extending the relatively simple:



to more deeply nested cases that prompts so much advice to avoid it altogether. And it is hard to push it further and still be understandable (to humans, anyway).

Anyway, what you seem to be after is a four-way branch based on two conditions. I think it parses this way:



I don't know if that's the syntax your tool requires (or even allows), but it's pretty straightforward to decode if you look at it as simply using a nested ternary expression for both the 'true' and 'false' branch expressions of the nesting ternary expression.

You can go even further, in the sense that it won't confuse a competent parser to do this to any depth, but it's generally a lot easier for humans to write now and read later to set anything beyond the simplest case use out as multi-way IF/ELSE branches.

It's a matter of taste. For short expressions, I find the ?: operator easy enough to read, but as the expression gets more complicated, I usually switch to other methods. If you prefer the if/else, you could use that instead.

There are several approaches. You can continue using the ?: operator in the following way, which is still fairly readable.

You could also write a 2nd case statement inside the default:

And if you like to be a bit clever, you can also pick special bit patterns for the 'SEL_*' constants. Suppose SEL_A = 4'b1000, and SEL_B = 4'b1001, etc. Then you could write:

I'm learning alot, thanks for sharing that info about MUX's!
It's all about the syntax. I had tried to come up with a way to do a default: case, but my syntax was way off! I do prefer that method.

So today I finished off adding the 2 other accumulators. I did a Sim on the short listing below and it worked.

My last immediate goal as far as adding things, is to add a Z index. Before that I think I should see if the core can still run @100MHz. I'll do that when I get home, and get off this sloth machine!

The new core, with 4 Accumulators, did not pass a 10.0ns O2In constraint...
However, it did pass a 10.5ns constraint! for a max of 99.48MHz.

EDIT: 10.5ns not 9.5ns.

Did you convert all instructions to work with any of the 4 accumulators where it previously only had A ?

I think a useful next step would be to add accumulator-accumulator transfer instructions, such as TAC, and TDB. This requires adding some opcodes too.

Yes. All the states related to A were changed in the Microcode state machine. So all addressing modes, etc. should work with B, C, & D Accumulators.


I agree. I think I see how to do that.

An interesting option is to allocate 2 different bits in the opcode space, say, bits 11-10, for the src_reg indexing, and bits 9-8 for dst_reg.

That way, you can do all kinds of interesting stuff like ADC B, A, #10, where an ADC operation is performed on A, and the result is stored in B.

That is what I would like to do with a 16x16 multiply opcode.

I recently read on Xilinx forums someone posed a question about how to infer the DSP48A1 slices which hold these multipliers. There was a link there point to a bunch of multiplier examples. Still I need to finish the transfer opcodes and the Z register, then recheck top speed... Busy at work today, so unfortunately no progress on the core.

Interesting developments!

It might be worth casting an eye over John West's design of the opcode encodings for 65020 (which is purely a paper design.) The machine isn't what we have - different register sizes for a start - but the encodings are quite interesting and they fit into a 16-bit opcode space, as an extension to a 6502 base.

http://www.ucc.gu.uwa.edu.au/~john/65020.html
http://www.ucc.gu.uwa.edu.au/~john/6502 ... tions.html

By flipping a few of his definitions (make the P bit the opposite value for a start) you might get something you could implement piece by piece.

Cheers
Ed

Do you know how old this design is? There is no date on the page

André