OPENCORES.ORG

Hello:

I don't know what is the answer to you specific question, but I can tell you
that for ASIC RAMs they don't have reset and there are two ways:
1) a state machine that clears register file at every reset
2) a short code at the begging of reset vector that will initalize register
file to 0. To reduce gate count and increase speed (simpler pipeline etc)
this one is implemented in OR1200 when not using generic RAM (ie flops).

In silicon implementations that I know (Flextronics Semiconductor, Dongbu
Anam) register file was implemented with generic memories (flops). So in
these cases boot code doesn't have to initialize register file to zero,
however in most boot code I've seen in order to assure compatibility between
FPGA implementations (typically FPGA implementation is a prototype of
silicon implementation and in many cases register file in FPGA due to lack
of resources is implemented with block RAMs and they need to be initialized)
and those ASIC implementation that use hard macro RAMs the following reset
vector in boot code has to be used.

Copied from linux
http://www.opencores.org/cvsweb.shtml/or1k/linux/linux-2.4/arch/or32/kernel/head.S:

    .global _start
_start:
	/*
	 * ensure a deterministic start
	 */

	l.ori	r3,r0,0x1
	l.mtspr	r0,r3,SPR_SR

	CLEAR_GPR(r1)
	CLEAR_GPR(r2)
	CLEAR_GPR(r3)
	CLEAR_GPR(r4)
	CLEAR_GPR(r5)
	CLEAR_GPR(r6)
	CLEAR_GPR(r7)
	CLEAR_GPR(r8)
	CLEAR_GPR(r9)
	CLEAR_GPR(r10)
	CLEAR_GPR(r11)
	CLEAR_GPR(r12)
	CLEAR_GPR(r13)
	CLEAR_GPR(r14)
	CLEAR_GPR(r15)
	CLEAR_GPR(r16)
	CLEAR_GPR(r17)
	CLEAR_GPR(r18)
	CLEAR_GPR(r19)
	CLEAR_GPR(r20)
	CLEAR_GPR(r21)
	CLEAR_GPR(r22)
	CLEAR_GPR(r23)
	CLEAR_GPR(r24)
	CLEAR_GPR(r25)
	CLEAR_GPR(r26)
	CLEAR_GPR(r27)
	CLEAR_GPR(r28)
	CLEAR_GPR(r29)
	CLEAR_GPR(r30)
	CLEAR_GPR(r31)

And copied from
http://www.opencores.org/cvsweb.shtml/or1k/orp/orp_soc/sw/support/reset.S

        .org    0x100
_reset_vector:
        l.nop
        l.nop
        l.addi  r2,r0,0x0
        l.addi  r3,r0,0x0
        l.addi  r4,r0,0x0
        l.addi  r5,r0,0x0
        l.addi  r6,r0,0x0
        l.addi  r7,r0,0x0
        l.addi  r8,r0,0x0
        l.addi  r9,r0,0x0
        l.addi  r10,r0,0x0
        l.addi  r11,r0,0x0
        l.addi  r12,r0,0x0
        l.addi  r13,r0,0x0
        l.addi  r14,r0,0x0
        l.addi  r15,r0,0x0
        l.addi  r16,r0,0x0
        l.addi  r17,r0,0x0
        l.addi  r18,r0,0x0
        l.addi  r19,r0,0x0
        l.addi  r20,r0,0x0
        l.addi  r21,r0,0x0
        l.addi  r22,r0,0x0
        l.addi  r23,r0,0x0
        l.addi  r24,r0,0x0
        l.addi  r25,r0,0x0
        l.addi  r26,r0,0x0
        l.addi  r27,r0,0x0
        l.addi  r28,r0,0x0
        l.addi  r29,r0,0x0
        l.addi  r30,r0,0x0
        l.addi  r31,r0,0x0

        l.movhi r3,hi(MC_BASE_ADDR)
        l.ori   r3,r3,MC_BA_MASK
        l.addi  r5,r0,0x00
        l.sw    0(r3),r5
        l.movhi r3,hi(_start)
        l.ori   r3,r3,lo(_start)
        l.jr    r3
        l.nop

Maybe I'll add a state machine that will delay fetch of first insn by 32
clock cycles and go through register file RAM and clear every register and
only then make first insn fetch.

regards,
Damjan

----- Original Message ----- 
From: <meleth_esp@y...>
To: <openrisc@o...>
Sent: Friday, May 21, 2004 7:18 PM
Subject: [openrisc] Problem with Register File modelsim simulation

> Hello:
>
>   In a previous post I comment that I develop a simple testbench that
> executes a load instruction, but when the data bus is going to assert
> strobe lines all the signal from the bus going to X.
>
> I found the reason. The simulation only works with the register file
> with the OR1200_RFRAM_GENERIC selected. With OR1200_RFRAM_DUALPORT or
> OR1200_RFRAM_TWOPORT selected and the FPGA target memories in generic
> mode the simulation makes the previous commented.
>
> I dont know if it is the desirable behaviour, Is it?
>
> Regards
> _______________________________________________
> http://www.opencores.org/mailman/listinfo/openrisc
>