[J-core] correction (Linux is now working) (Re: Achievable clock speed, bottlenecks?)

[BGB]

On 10/1/2016 3:33 AM, BGB wrote:
> 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.
>

still not sure of this, ex, whether an FPGA behaves more like real 
electronics or more like RLL:
     https://en.wikipedia.org/wiki/Ladder_logic

not entirely sure how they work though, ex, if they are something like 
FGMOS being used to wire up logic gates (ex: essentially like a 
Flash-ROM chip but controlling wires and logic gates rather than 
memory), or if they are more something like a crazy-fast many-core 
version of a PLC (generally the PLC's aren't all that fast and will bog 
down some if the ladder-program is complicated enough).


>
> 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).
>

correction, output was:
<--
Aboriginal Linux 1.4.2
ifconfig: ioctl 8916: No such device
route: ioctl 0x890b failed: Network is unreachable
Type exit when done.
(:1) / $
-->
(screwed up because I retyped it from memory, but couldn't remember what 
it looked like exactly...).

turns out the missing detail was trying to hit a key, where the rest of 
the text doesn't appear until after a key is hit... I was left thinking 
it had simply died after printing "ifco" the whole time (and hadn't been 
trying hitting keyboard keys, guess I had hit a key that one time).

though, in my bug hunt, did uncover/fix a few bugs:
     for example noting that the SMC detection could miss writes into 
the instruction in the delay-slot;
     it could also miss cases where a misaligned write crossed a page 
boundary (4kB)
         with an instruction trace beginning at the start of the next page.
     ...


garbage appears to be ANSI codes.
     as soon as I hit enter though, nothing happens
     OK: this is specific to the Windows console.
         there is no logic currently to interpret ANSI codes, and I am 
not sure what Linux expects from enter.
             sending CR, LF, or CR+LF doesn't work.

testing from a WS4L shell, it appears I can type commands and they work.
but, for whatever reason, I have to hit keys before the rest of the 
output appears, which is weird...

there appears there is some difference between what I am getting from 
the Windows command-prompt vs WS4L console which effects what happens in 
the emulated Linux.

have noted, if I type a bad command, then the emulated Linux becomes 
unresponsive.
noted: no evidence thus far of network devices or drivers (beyond loopback).

also don't see any devices for the SD card, so not sure how it would be 
mounted (well, assuming my implementation of the SPI/MMC interface is 
correct enough for Linux to use it...).


I guess this counts as working (may put the updated emulator source 
online later).