[J-core] Linux on J1?

[Geoff Salmon]

On 16-08-02 04:06 PM, Rich Felker wrote:
>> > I also forgot that CMPXCHG and our memory barrier stuff is currently
>> > implemented as cache tricks. Right now we CAN'T do SMP without the cache.
> I'm not sure where you got that. It works fine with dcache off, and
> IIRC it even works on sram too (though not on mmio registers, of
> course).

You're both sort of right. There's a VHDL entity called ddr_ram_mux that 
combines 5 separate buses into one stream of read and writes for the 
DRAM controller. There's only one implementation of ddr_ram_mux that 
supports SMP and it also contains the dcaches, so we don't have an SMP 
build without the dcache. As Rich said though, I don't think the cas.l 
instruction requires the dcache be there.

There is some bus arbitration logic that supports cas.l on the SRAM. 
That logic is relatively simple. I don't think it looks at the address 
so if both cpus are doing cas.l one will stall even if the addresses are 
different. If this false sharing is acceptable, access to DRAM could be 
controlled in the same way.

>>> > > It might be more
>>> > > practical to do a shared-dcache implementation for SMP, where both
>>> > > cores are accessing the same cache (even if subject to stalls when
>>> > > both access it at the same time) that would allow all the snooping
>>> > > logic (and half of the cache memory size) to be omitted.
>> >
>> > I'm not sure what actually saves resources in the FPGA, the SRAM banks
>> > are there either way. (Wiring them up takes the kind of cells we tend to
>> > run out of...)
> I would think an LX25 or LX45 has more sram space than an LX9 or
> ICE40, but that's just a guess; maybe they all have a plenty.

For block RAMs, a Spartan6 SMP design is currently using about 41 of the 
LX45's 116 block RAMs. LX9 has only 25 and LX25 has 52. Would have to 
drill down and determine what is actually using those block RAMs and 
whether it could be removed in a J1 SMP design to have a hope of fitting 
on a LX9.

Rob is right that actually using the block RAMs consumes slices to write 
signals to and from the block RAMs, so the block RAM count might not be 
the limiting resource. Even if we had enough block RAMs, reducing the 
number used by a particular logical memory, like the CPU SRAM, should 
free up some resources that were previously routing signals to and from 
the now unused block RAMs.

- Geoff