OpenCores
Issue List
Fetching all zero instead of BNEZ (boot.asm) #11
Closed mi.petracca opened this issue over 14 years ago
mi.petracca commented over 14 years ago

compiling my C program and linking boot.asm, the head of the program looks like follows (from test.lst), which is exactly how I expect it to look like.

00000000 <.text>: 0: 3c1c0001 lui gp,0x1 4: 279c8670 addiu gp,gp,-31120 8: 3c050000 lui a1,0x0 c: 24a50680 addiu a1,a1,1664 10: 3c040000 lui a0,0x0 14: 248408a4 addiu a0,a0,2212 18: 3c1d0000 lui sp,0x0 1c: 27bd0878 addiu sp,sp,2168 20: aca00000 sw zero,0(a1) 24: 00a4182a slt v1,a1,a0 28: 1460fffd bnez v1,0x20 2c: 24a50004 addiu a1,a1,4 30: 0c00012e jal 0x4b8 34: 00000000 nop 38: 0800000e j 0x38 3c: 23bdff98 addi sp,sp,-104 40: afa10010 sw at,16(sp)

However, both in Quartus II simulation and on Altera FPGA, and both with 2 or 3 pipeline stages, the instruction BNEZ at address 0x28 is fetched as all 0. During execution, while fetching such instruction the address 0x28 is held for two clock cycles, because the SW store two instruction before is executed. The following ADDIU instruction at address 0x2C is fetched and executed correctly, and the program ends up in an endless loop on J, at address 0x38.

Now, I do not expect this to be a bug, because the BNEZ instruction turns out to be the instruction that calls the main program, so if there was a bug there someone would have definitely realized it before me... but what am I missing? I checked that the memory content is properly set, but I do not understand what is going on. It is not even an issue with jump hazard, because the OPCODE_NEXT signal into the MEM_CTRL block evolves correctly but I just see 0x00000000 in a clock cycle where I expect to see 0x1460fffd.

NOTE: while PC_REG into the PC_NEXT block is set to 0x28 (for 2 clock cycles), MEM_SOURCE from the CONTROL block is set to 0x05 (again because of the execution of a store two instructions before) for 2 clock cycles as well.

Please, help. Thank you.

mi.petracca commented over 14 years ago

My bad. The problem was simply due to the fact that my RAM instances had REGISTERED outputs. I missed that configuration when updating the LPM_RAM_DQ instances to the new ALTSYNCRAM.

From Altera documentation website (http://quartushelp.altera.com/9.1/master.htm#mergedProjects/hdl/mega/mega_file_lpm_ram_dq.htm?GSA_pos=1&WT.oss_r=1&WT.oss=lpm_ram_dq): ... Parameterized RAM with separate input and output ports megafunction. Altera recommends using lpm_ram_dq to implement asynchronous memory or memory with synchronous inputs and/or outputs. This megafunction is provided only for backward compatibility; instead, Altera recommends using the altsyncram megafunction. ...

If I haven't missed anything else, the updated instance 0 would be

altsyncram_component0 : altsyncram
GENERIC MAP (
	address_aclr_a => "NONE",
	indata_aclr_a => "NONE",
	init_file => "code0.hex",
	intended_device_family => "UNUSED",
	lpm_hint => "ENABLE_RUNTIME_MOD=YES, INSTANCE_NAME=RAM0",
	lpm_type => "altsyncram",
	numwords_a => MEMORY_SIZE,
	operation_mode => "SINGLE_PORT",
	outdata_aclr_a => "NONE",
	outdata_reg_a => "UNREGISTERED",
	power_up_uninitialized => "FALSE",
	widthad_a => ADDRESS_WIDTH-2,
	width_a => 8,
	width_byteena_a => 1,
	wrcontrol_aclr_a => "NONE"
)
PORT MAP (
	wren_a => byte_we(3),
	clock0 => clk,
	address_a => address(ADDRESS_WIDTH-1 downto 2),
	data_a => data_write(31 downto 24),
	q_a => data_read(31 downto 24)
);

NOTE: the option

lpm_hint => "ENABLE_RUNTIME_MOD=YES, INSTANCE_NAME=RAM0"

enables full visibility on/access to the RAM content at run-time through In-System Memory Content Editor.

Regards.

rhoads was assigned almost 14 years ago
rhoads closed this almost 14 years ago

Assignee
rhoads
Labels
Request