[J-core] Memory_fpga

[Gutierrez, Santiago]

Hi Geoff,

I have included the log files that I believe are most relevant. The first file, the one titled synth_log, is the synthesis of j2 with the cpu_core.vhd file as the top level module. I was planning on using that module in a design of a new top level soc.vhd that I will be using for the kintex 7. I am using vivado's built in Memory Interface Generator to make a DDR3 SDRAM controller. How exactly does the J2 handle memory writes/reads? I'd love to know the step by step process so that I can connect the generated memory controller and the top level cpu_core. Looking at the code, cpu_core just seems to be a wrapper around cpu with added modules, such as an interrupt controller. Is this correct?

The second file, j2_cpu_synth_attempt, is the log file of my first attempt at synthesizing just the J2 processor, with the top level being the cpu.vhd file. As you can see it complains about not being able to find the architecture cpu_decode_reverse. One of my colleagues here took a look at the code and made a bit of a work around, she hard coded the desired architecture into the files and after that the synthesis completed successfully. If you guys would like, I could see if it's possible for me to send over the modified files. After I got the synthesis to work, I tried the creating the implementation and that worked fine, but as you can see in the final log file included, the bitstream was unable to be generated. The last two errors, the ones that aren’t LUTLP-1 are just due to unassigned pin assignment so can be ignored. However the LUTLP-1 error is the major error stopping the bitstream. A workaround, as it says in the error is to set a SEVERITY warning, which is what I did, as I don’t wish to break any functionality that could be there. Interestingly enough however, when synthesized with the top level soc.vhd from the mimas_v2 project this error was not there and it only gave the unassigned pin errors.

I hope this helps somewhat for the future. I'm looking to forward to hearing about the memory read/write procedures for the J2 processor. Also, when would the superH-4 patents be expiring? And when would you guys be releasing the J4?

Thank you,

Santiago Gutierrez 

-----Original Message-----
From: Geoff Salmon [mailto:gsalmon at se-instruments.com] 
Sent: Thursday, June 16, 2016 1:31 PM
To: Gutierrez, Santiago <Santiago.Gutierrez at viasat.com>; j-core at lists.j-core.org
Subject: Re: [J-core] Memory_fpga

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
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: synth_log.txt
URL: <http://lists.j-core.org/pipermail/j-core/attachments/20160617/b7d87f3b/attachment-0003.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: j2_cpu_synth_attempt.txt
URL: <http://lists.j-core.org/pipermail/j-core/attachments/20160617/b7d87f3b/attachment-0004.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: j2_cpu_bitstream_attempt.txt
URL: <http://lists.j-core.org/pipermail/j-core/attachments/20160617/b7d87f3b/attachment-0005.txt>