On 06/16/2018 11:47 AM, Giovanni Mascellani wrote:
Hi, Il 16/06/2018 12:02, Manuel A. Fernandez Montecelo ha scritto:As a rough estimate, qemu is about 20x times slower than modern hardware. E.g. if the build takes 5 min in arm64, it takes 1h on one of our buildds; if it takes 2h in arm64 that's two days in riscv64.
Merely an interested follower here but from my experience working with
SoC type projects limited to JTAG debugging I feel that this Freedom
E210-G000 chip may just be the first of a series of non-production scale
*prototype* class implementations. Given the interest in RISC-V we can
surely hope to see more to follow that are 64-bit wide and clock rates
up significantly. However this first piece of hardware uses a PLL that
operates in the range 6 to 48MHz and generates a clock to the SoC from
48 to 384MHz.[1]
From the E310-G000 ref manual we see :
The instruction memory system consists of a dedicated 16 KiB 2-way
set-associative instruction cache. The access latency of all blocks
in the instruction memory system is one clock cycle.
The instruction cache is not kept coherent with the rest of the
platform memory system. Writes to instruction memory must be
synchronized with the instruction fetch stream by executing a
FENCE.I instruction.
The entire implementation is 32-bit at this time and performance is the
*last* concern on the table I should think. A compliance level to the
specifications should be the first. If a Linux kernel can be ported to
this hardware at all there should be joy all around. So the HiFive1
test board looks to be the place where one should compare compliance
between a software implementation ( qemu? ) to the hardware and more
joy if that seems to mesh. I would forget performance entirely and be
happy that anything can be done in 48 hours.
Dennis
[1] The PLL output frequency is set using a combination of three R/W
fields: pllr[2:0] pllf[2:0] and pllq[1:0] wherein we can accept the
PLL ref clock input from 6 to 48MHz and then scale up to the output
clock range.