[J-core] Achievable clock speed, bottlenecks?

D. Jeff Dionne Jeff at SE-Instruments.com
Sat Oct 1 09:35:29 EDT 2016


We can easily hit about 100MHz in K7.  I've run it at 125MHz in K7 but it crashes early on, not surprising given it doesn't meet timing at that speed.  The critical paths shown for the CPU are generally from the instruction decoder, through the ALU and to the T bit (flags) or some such (caveat: it's been a while since I looked).  If we want the CPU to run much faster, we have to look at breaking what is done in the pipeline stage that has this critical path into 2 stages (that is, insert a pipeline register).  LEON SPARC 3 moved to a 7 stage pipeline from a 5 stage for this reason.

openrisc is, well, very RISC, and j-core pipeline is implementing something much, much more complex.  The instruction set design was driven by research into efficient code generation and execution, not implementation.  Compact instructions and (hopefully) less of them for a given algorithm are the trade off for clock speed.

That said, Rich is correct, the stuff around the cores matters a lot to what the tools can get the fpga fabric to give us.   You can play tricks with constraints to help it arrange things more logically on the die (floor planning), but it makes the whole synthesis process brittle.  You'll have to do the manual placement constraints again and again as the RTL changes.  If you have the Xilinx tools installed, do a synthesis and P&R, and run the floor planner to see what it looks like.   For instance, select the CPU... Gaaaaaah!

As for the fpga itself, all our commercial designs have many multiple clock domains... Some of the logic in all of those has 1/2 cycle paths at 250MHz (so 2ns) even in Spartan 6.

Cheers,
J.

> On Oct 1, 2016, at 01:51, Rich Felker <dalias at libc.org> wrote:
> 
> Reportedly the mor1k implementation of or1k is running at 150 MHz on
> Kintex 7s, dual-core even. Any ideas what might be preventing J2 from
> achieving comparable clock rate? Not being an expert on the hardware
> side of things, my naive guess would be that having all the
> peripherals on the main bus at cpu clock is a major obstacle to
> meeting timing constraints at higher clocks.
> 
> Rich
> _______________________________________________
> J-core mailing list
> J-core at lists.j-core.org
> http://lists.j-core.org/mailman/listinfo/j-core


More information about the J-core mailing list