[J-core] What is the correct way to reset the CPU?

[Geoff Salmon]

On 16-07-18 05:43 AM, Robert Ou wrote:
> Hi,
>
> What is the correct way to reset the CPU? In my simulation, if I
> assert the rst pin, the CPU then proceeds to fetch instructions
> starting from address 0. However, the boot.elf bootrom compiled for
> the Mimas definitely starts with the address of the start function at
> 0x0 followed by the initial stack at 0x4. I don't understand how the
> CPU can get in a state such that it can correctly run this. Could
> someone clarify? Do I need to externally feed in a RESET_CPU event?

Hmm. Asserting the rst port should be enough.

When you assert rst, you're seeing the cpu read address 0 on the 
instruction bus and not the data bus?

Oh, this may be due to not instantiating a cpu configuration, explained 
in my earlier email. The configuration for each type of instruction 
decode sets the reset vector in a generic. Here's one example

configuration cpu_decode_reverse of decode is
   for arch
     for core : decode_core
       use entity work.decode_core(arch)
         generic map (
           decode_type => REVERSE,
           reset_vector => DEC_CORE_RESET);
     end for;
     for table : decode_table
       use entity work.decode_table(reverse_logic);
     end for;
   end for;
end configuration;

If you don't instantiate a configuration like work.cpu_sim or 
work.cpu_fpga, then decode_core's reset_vector generic won't be set. I 
would have thought that would be an error ghdl would report, but maybe not.

> Also, if I look at the microcode spreadsheet, it seems to be saying
> that reset should involve loading *(0x0) to R15?! and *(0x4) to PC.
> This seems backwards unless I am reading the spreadsheet wrong
> (likely). Could someone explain why the spreadsheet has a store to R15
> before the store to PC (row 251 vs row 252 in the 20160418 code dump)?

The control signals for setting the PC and which stages they act in are 
a bit arcane. I'm not sure I can explain them well or even correctly.

Looking at the MA* signals in the right-most columns of the spreadsheet, 
the two memory loads are on lines 250 and 251.

Line 250 reads U*4 where U is an immediate from the instruction and is 0 
when the CPU is reset. If you look at the rest of this spreadsheet line, 
it seems to do nothing with WBUS, which is the result of the read.

Line 251 reads U*4+4 and writes the WBUS to R15. So this 2nd read loads 
the stack register.

The result of the first read started on line 250 is actually used in 
line 252 where "ZBUS SEL"=W. When this microcode line's EX stage is 
running, the WB stage of line 250 is running, so WBUS is the value read 
from address U*4.

The spreadsheet does a poor job expressing these dependencies between 
lines. There's some more arcane stuff in the next line too. Even though 
line 252 writes the value to PC, line 253 sets "IF ADDY"=ZBUS so that 
the new PC is used for the instruction fetch. Otherwise the next 
instruction fetch would still use the old PC value.

- Geoff