[J-core] Achievable clock speed, bottlenecks?

[BGB]

On 10/1/2016 12:51 AM, Rich Felker 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.

I am wondering as well.
   ex: how fast can stuff on an FPGA actually run?...
   is it more analog timing (like with discrete components)
   or is it more like the FPGA runs on a fixed master tick.
     are there propagation delays and a "scan time" like in PLC's / 
Ladder Logic?
     if so, is there something in the VHDL to hint at relative 
scan-ordering?
     ...

though, I find VHDL at least a little easier to follow (and less 
pointlessly bulky) than RLL / ladder logic (which is sort of right up 
there with Redstone in Minecraft).

but, yeah, if it is a timing issue like this, maybe it could be possible 
to make things like accessing DRAM and MMIO take multiple cycles if 
needed, so that executing instructions and performing arithmetic can be 
done faster?

but, granted, I still don't have money for an FPGA, so can't really mess 
with this side of things yet.
what I can do is mostly limited to software.



not meaning to derail, but current status:

the current status of my emulator is that it seems to die shortly after 
starting execution of the "init" shell-scripts.
AFAICT, it gets to about here: "ifconfig eth0 10.0.2.15" and then dies.

on one run, I got output something like:
<--
ifconfig eth0:
Failed to configure eth0: Destination host unreachable.
...
Type exit when done.
#
-->

but, trying to type stuff gave garbage characters, and I have been 
unable to reproduce this result in subsequent runs (ex: actually getting 
to a prompt).


more commonly, I am getting the output:
<---
Aboriginal Linux 1.4.2
ifco
--->

at which point it appears to be dead.

with some other variants, it cuts off the banner line to "Abo", or 
follows it by printing 'hus' instead of 'ifco'.
I am not sure the meaning, but it seems like somewhere, it prints the 
first few characters of the name of the program where it died, with the 
path omitted (when it dies, it goes into a sleep loop in the kernel).


debugging is proving difficult, but I have noted that the handling of 
the trace-cache seems to influence the output at this point. after 
control reaches the init script, there is considerable amounts of SMC 
handling.

it appears that "sed" regularly writes to a region of memory, executes 
it, then zeroes it, then writes code back to it, then zeroes it again, 
... subsequent commands appear to zero multiple pages worth of code, 
then execute, then zero the memory.

where and how it dies, and how quickly it executes, are somewhat 
influenced by the cache-flushing logic. however, the effects of the 
cache flushing/... "should" be completely invisible (implying there may 
be a bug somewhere, assuming the behavior is not timing-related or 
related to some other internal state, such as using an uninitialized 
variable somewhere or similar).

but, yeah, "getting closer" at least...


the EMAC interface appears to be the Xilinx Emaclite / "LogiCORE IP XPS 
Ethernet Lite Media Access Controller", as I can infer from the various 
bits of code around (mostly from the 0PF stuff in the Linux kernel), 
though mostly indirectly by inferring from address ranges.

if so, I may implement this.

though, this is unlikely to effect booting Linux as AFAICT it is not 
actually accessing any of the EMAC-related memory ranges (and thus the 
"ifconfig eth0" line is a misnomer, as it isn't actually accessing the 
device). likewise, it doesn't appear this driver is configured in the 
kernel, and the drivers which are configured don't appear to match, so 
dunno...


or such...


> Rich
> _______________________________________________
> J-core mailing list
> J-core at lists.j-core.org
> http://lists.j-core.org/mailman/listinfo/j-core