32 is the new 8-bit

[ElEctric_EyE]

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

[Windfall]

enso wrote:

Muxes are async, and simply deliver the correct signal to the output. That takes time, and the cumulative time of all sequential logic decides the maximum clock rate.

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.

enso wrote:

Seriously, try to make your circuit before rabidly defending it.

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.

[Windfall]

enso wrote:

Windfall wrote:

Do you have some sort of psychological problem that we should know of ?

I suffer from a rare condition that makes it difficult for my brain to form medium-long term memories, due to an accident some years back. I can work pretty well with short-term stuff, but I have to literally re-learn things all the time.

On the positive side, I am pretty good at becoming reasonably good at various things quickly. And because I don't always have memory to rely upon, it makes me more careful about verifying everything. As well as documenting my projects carefully.

Oh, and I also have borderline Aspergers, a touch of OCD, and have issues with hyperfocusing. The ADHD diagnosis has proven to be incorrect.

Thanks for asking.

My pleasure. I figured as much.

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

[BigEd]

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

[enso]

Windfall wrote:

enso wrote:

Windfall wrote:

Do you have some sort of psychological problem that we should know of ?

I suffer from a rare condition that makes it difficult for my brain to form medium-long term memories, due to an accident some years back. I can work pretty well with short-term stuff, but I have to literally re-learn things all the time.

On the positive side, I am pretty good at becoming reasonably good at various things quickly. And because I don't always have memory to rely upon, it makes me more careful about verifying everything. As well as documenting my projects carefully.

Oh, and I also have borderline Aspergers, a touch of OCD, and have issues with hyperfocusing. The ADHD diagnosis has proven to be incorrect.

Thanks for asking.

My pleasure. I figured as much.

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

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

[Windfall]

BigEd wrote:

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

I would like to add patient. And thinking.

BigEd wrote:

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

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.

[enso]

Good luck

I do envy your arrogance! Seriously, I do.

[ElEctric_EyE]

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

[enso]

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

[BigEd]

> 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

[ElEctric_EyE]

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.

[Arlet]

Windfall wrote:

Yes. But it replaces the cycle that would load only the opcode instead. So there is no extra cost. Just the gain of no longer needing to load any of the argument bytes in following cycles

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.

[Windfall]

BigEd wrote:

I don't know that this thread has made you seem easy to work with, Windfall, but that's for individual collaborators to determine.

That's not very big of you, Ed.

[Windfall]

Arlet wrote:

Windfall wrote:

Yes. But it replaces the cycle that would load only the opcode instead. So there is no extra cost. Just the gain of no longer needing to load any of the argument bytes in following cycles

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.

Okay, I see. You've shifted the paths a little by preprocessing the opcode while it's not even registered yet.

Arlet wrote:

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.

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.

[Arlet]

Windfall wrote:

Okay, I see. You've shifted the paths a little by preprocessing the opcode while it's not even registered yet.

In my core, the opcode is never registered. None of the incoming data bus is registered before processing.

Quote:

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.

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 ?