[J-core] qemu updates / roadmap

[Geoff Salmon]

On 16-05-17 06:52 PM, Rob Landley wrote:
> On 05/17/2016 05:36 PM, Geoff Salmon wrote:
>> On 16-05-17 06:15 PM, Rich Felker wrote:
>>> See Rob's previous post to this list:
>>>
>>> http://lists.j-core.org/pipermail/j-core/2016-April/000038.html
>>>
>>> I think the SRAM part is larger than he stated though; check the VHDL
>>> or just use the boot loader linker script as a guide for now.
>> It is 32KB. It's all writeable though. There is no ROM/SRAM partition in
>> the current FPGA designs.
>>
>> In an ASIC, there will be a separate ROM holding the bootloader and a
>> writeable RAM region which is uninitialized at power on. At some point
>> we'll need to implement this same separation between a one-port ROM and
>> a RAM in the FPGA to test the data and instructions buses work as
>> expected, but we haven't done that yet even though we'll often call it
>> the "bootrom".
>
> So the boot code is copied into sram before the processor starts executing?

I think the instructions would be executed directly from the ROM. 
Anything writeable with an initial value would have to be copied to 
SRAM. Later stages of the bootloader could be loaded into SRAM or DDR 
RAM and run from there.

It'll be slower. The ROM has a single port which needs to shared between 
the instruction and data buses, and it may take multiple cycles to read 
from the ROM.

>> If you're curious, the memory is instantiated in the file
>> soc_top/tools/memory_fpga.vhd.in. This file is modified by a perl
>> script, soc_top/tools/patchcode.pl, which inserts the INIT_NN generics
>> into the VHDL to put the bootloader image into the memory.
>
> How does this "put" work...?

The FPGA bitstream can contain the initial contents of block RAMs in the 
FPGA. While the FPGA is being configured, these values are written into 
the block RAMs, so they'll be there before the cpu starts running. The 
"SRAM" we're talking about is implemented by block RAMs.

> It sounds like it creates circuitry that writes a series of values into
> the memory before the processor starts, and this is easier for us to do
> in the FPGA than make an actual ROM because the FPGA already includes
> some sram in its libraries so it's cheap for us to use that, and making
> our own ROM with address and data busses that let it be randomly
> addressable and readable would eat way more cells than this sequential
> writer does?

I don't know the mechanics of it. I imagine that during FPGA 
configuration the same circuitry and memory write ports that our design 
will later use are purposed to write values into the block RAMs. We 
don't need to write any logic to manage this writing and I doubt there's 
any lasting cost to doing it after the FPGA is programmed with our soc.

If you want the gruesome details look at the "Configuration Memory 
Frames" section of 
http://www.xilinx.com/support/documentation/user_guides/ug380.pdf and at 
"Content Initialization - INIT_xx" in the "Block RAM Attributes" section 
of http://www.xilinx.com/support/documentation/user_guides/ug383.pdf

In preparation for the ASIC we would implement our "ROM" using a block 
RAM, connect the cpu data and instruction buses to a single port of the 
RAM, and ignore writes from the data bus. We might even add the extra 
read delay cycles if there are any with the real ROM. It shouldn't use 
that much more FPGA slices than the current design does.

- Geoff