6502.org

Did a doctor tell you this? Or/And is this a self-diagnoses?
Sorry to the OP. I couldn't resist.

Only the cumulative time of the critical path does. Even if that's the new kid on the block, and it would bring down the maximum clock frequency, avoiding entire cycles will more than offset that. Or maybe you should try to, before rabidly trying to dismiss it.

Just because you're not able to figure it out, and move goalposts whenever you've had something that you missed explained to you (sometimes multiple times), hardly suggests that it won't work.

My pleasure. I figured as much.

Perhaps you should take it into account when you enter discussions.

It would be nice if we could all be calm and considerate.

John, if you coded up a contribution would you open-source it? As you may know, several of favour LGPL.

Cheers
Ed

I will try to remember. Better yet, I will make a note in my book not to ever mess with windfall again

I would like to add patient. And thinking. In this case, certainly.

I'd have to know that I'm not doing it for nothing, though. Some core author has to grasp (and believe in) the concept, and would have to be willing to make the required changes to their core. All the way, or not at all.

Good luck

I do envy your arrogance! Seriously, I do.

I wouldn't take this too personal dude. All this is sort of entertaining though.

I haven't laughed like this in about 6 months!

> In this case, certainly
That's good to hear, thanks.

I don't know that this thread has made you seem easy to work with, Windfall, but that's for individual collaborators to determine. I've seen no-one do better than Jeff in re-explaining and de-escalating such that everyone comes out with the same understanding.

More technically: I think the on-chip block RAM of affordable FPGAs falls a bit short of many expectations - the Atom being an exception - so the idea of having off-chip RAM (as wide as 32bits or wider) and using the block RAM as buffer or cache seems good to me. We should note that on-chip there's no special need for the core to access memory using a single memory path. But the cores we have today do look like that, so there's work in making them otherwise. (We've mentioned particular cases of putting zero page and/or stack page on chip. That might be technically easier than a general cache, or more effective, or neither!)

Cheers
Ed

Thanks for putting us back on track Ed!
..In the Do It Yourself arena, we need someone who can tackle a 1mm BGA package and successfully mount it. Enso seemed to be headed in this direction. I would very much like to see us headed in this direction for a real build. In the end, one needs a real system and a 32-bit core will most likely need alot of I/O pins, more than I'm wrestling with in the 144-pin QFP Spartan 6.

In the current design, the address (PC) is presented to the memory in cycle #0, the memory fetches the opcode, and the opcode is ready for decoding in cycle #1. The opcode isn't stored in flip-flops in the core, instead, the decoding logic looks straight at the data bus.

With your proposal, the address is presented to the memory in cycle #0, the memory fetches a 32 bit word, which will be ready in cycle #1. The difference is that we can't feed the data straight into the decoder, because we first need to select the correct byte out of 8 possibilities.

That's not very big of you, Ed.

Okay, I see. You've shifted the paths a little by preprocessing the opcode while it's not even registered yet. No, 5. And we can make it 4, because we can arrange the opcode to always come out of PW. There is just one corner case to fix. If IR consumes the last byte of PW exactly (in the code example I posted earlier this happens when the fourth instruction is constructed), we replace PW and PWA anyway, even though the word read has not contributed.

See what happened here ? The critical path may have become shorter here, since this replaces the memory access path with a combinatorial path involving only PW and the two least significant bits of the PC.

In my core, the opcode is never registered. None of the incoming data bus is registered before processing. It only becomes shorter if PW/PWA are registers. But then you'll have to add the cycles to load those registers. In addition, you'll need muxes to grab the operand values. And what are you going to do when you load data ? If you use the same method, every LDA will require an extra cycle.

And did you consider STA ?