Arlet's 6502 Core Timing

[Arlet]

cr1901 wrote:

I don't think your core provides enough control signals to the outside world for me to do that

What signals would you need ?

[cr1901]

I'd have to think whether I need more, but at the very least, I'd need a signal that denotes whether your core is "ready or not ready" to fetch the next address. Something akin to a pipeline stall signal.

But this is later. I can live with the halved performance on the Wishbone bus for now.

[Arlet]

By "next address", do you mean the previous + 1 ?

[Rob Finch]

In the FPGA, Block RAM's are incredibly fast. It's possible to use the synchronous RAM in an asynchronous fashion by clocking the RAM at a higher clock frequency than the processor core. For instance using a 3x core clock to clock the block RAM. This avoids the need to use a next-address output from the core and instead the normal address bus can be used.

[Arlet]

Rob Finch wrote:

For instance using a 3x core clock to clock the block RAM. This avoids the need to use a next-address output from the core and instead the normal address bus can be used.

My problem with that approach is that I wouldn't know where to begin with the proper timing specification for that. Do you have experience with this ?

[Rob Finch]

Quote:

My problem with that approach is that I wouldn't know where to begin with the proper timing specification for that. Do you have experience with this ?

Yes, specifying timing may be the problem.
I had the FISA64 cache setup this way for a while and it seemed to work, but I switched it to using the negative clock edge instead. It may have been giving me timing error messages which I ignored.
I didn't use an explicit timing spec in a constraints file as the clocks are all related to (synchronous to) a master clock. The tools check for proper timing automagically.

It's the same idea as using the negative edge of the clock to clock the BRAM. Using the negative edge of the clock is similar to using a 2x clock. It gives 1/2 the time to access the BRAM.

It does mean you have to generate another clock and pass the clock signal around, so it's not pretty in code.

The reason to use a 3x clock (or higher) is that the BRAM should be guaranteed to have a full access time even if the clock synchronization is off a bit.

[cr1901]

Arlet wrote:

By "next address", do you mean the previous + 1 ?

Yes. That said, I think I need to finish designing my current "toy" system and upload the code (I have your code linked as a git submodule).

[cr1901]

Decided to compromise... I created a bus that's compatible with Arlet's core and then created peripherals that respond to this bus. For the purposes of creating 6502 SoCs, all peripherals I create- except for those emulating 65xx chips- will use Arlet's core timing; the toolbox I use to write HDL doesn't really allow negedge clocks, save for faking it by inverting a posedge clock.

If I need Wishbone or ASIC 6502 timing, then I'll create bridges between each bus to convert bus timings from one format for another (6 different permutations :/).

Ah well, this works and it's a start (as of the first commit, this really only works for one dev board. I'll fix that in the upcoming days.

https://github.com/cr1901/n6502fpga