[J-core] Memory_fpga

[Geoff Salmon]

Hi Santiago

On 06/16/2016 11:47 AM, Gutierrez, Santiago wrote:
> I was wondering if someone could tell me the function of the
> memory_fpga.vhd module.

It is the memory mapped into the CPU's address space at 
0x00000000-0x00003FFF (I think it's mirrored repeatedly above that too). 
It's connected to both the CPU's data and instruction buses.

We place the compiled bootloader program into the INIT_NN generics so 
that when the FPGA comes out of configuration, it will have the 
bootloader in it. The first thing the CPU does is read it's initial PC 
register value from a fixed address at the start of the memory and then 
begin executing instructions from there.

There are targets in soc_top/tools/soc.mk that read in 
soc_top/tools/memory_fpga.vhd.in and the compiled bootloader and outputs 
the memory_fpga.vhd that will be passed to the xilinx tools. Here's the 
relevant bit below.

################################################################################
# Pack boot code into memory_fpga.vhd that is SRAM
################################################################################

# force main.srec because ROM_BIN may have changes so timestamp is not
# a reliable indicator of change.
ROM_BIN ?= boot.elf
main.srec: $(ROM_BIN) force
	sh2-elf-objcopy -v -O srec --srec-forceS3 $< $@

boot.bin: $(ROM_BIN) force
	sh2-elf-objcopy -v -O binary $< $@

ram.dat: main.srec
	$(TOOLS_DIR)/genram/genram-32k $<

memory_fpga.vhd: memory_fpga.vhd.in ram.dat
	perl $(TOOLS_DIR)/patchcode.pl ram.dat > memory_fpga.vhd.temp
# only replace the file if the new one is different to prevent
# unneeded rebuilding
	cmp -s memory_fpga.vhd.temp memory_fpga.vhd || mv memory_fpga.vhd.temp 
memory_fpga.vhd
	rm -f memory_fpga.vhd.temp


(As an aside, I believe there's a command line way with Xilinx ISE to 
change the initial contents of BRAMs in an existing bitstream. That 
could be a nicer way of doing this same task. I'd bet Vivado can do it too.)

> I have almost been able to fully synthesize the
> entire SOC using Vivado, and the only thing that it’s telling me right
> now is that I’m missing that file. However, I had diffed the two
> memory_fpga files produced from the make process of both the mimas_v2
> and the microboard, though both files were extremely long there were
> only 4 lines different from the two. So I just wanted to know if there
> was a significant difference between the two, and is the memory_fpga
> file board specific at all.

Each board can include a bootloader with different features. For 
example, on a board without a LCD, the bootloader should not try to 
display the vmlinux load progress on the LCD. To accomplish this, each 
board's Makefile (the makefiles in soc_top/targets/boards/*) has a 
target to build boot.elf from the soc_top/boot directory and can pass 
options to the soc_top/boot/Makefile. Different options to the 
bootloader Makefile lead to different boot.elf contents which leads to a 
different memory_fpga.vhd.

Even if the boot build options are identical, the resulting 
memory_fpga.vhd can be different because there is a string in the 
bootloader that includes the build time. See this part of 
soc_top/boot/Makefile

VERSION_STRING:=revision: $(REVISION)\\\\n
ifeq ($(CONFIG_VERSION_DATE),1)
VERSION_STRING:=$(VERSION_STRING)build: $(shell date)\\\\n
endif

You can pass CONFIG_VERSION_DATE=0 to the boot Makefile to stop 
including the date in that version string and then the memory_fpga.vhd 
should be identical given the same options built with the same toolchain.

> If it is then I will have to make one for
> the Kintex 7 KC705, if it’s not then I will just use one of the two files.

I think you would build the bootloader with the same options that 
mimas_v2 does.

> Also, porting the core into Vivado gave an error of DRC 23-20 LUTLP-1,
> which is a combinatorial loop in some logic, there were 3 modules in
> particular, 2 in the decode_core and one in the datapath I believe.

Can you send us the build logs or relevant sections of them? Might be 
handy to see what Vivado complains about. Even the warnings could be useful.

> I was also wondering if the J2 was compatible with superH-2A architecture?

It's not. SH-2A is much newer than SH-2 and the relevant patents have 
not expired yet.

- Geoff