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

[D. Jeff Dionne]

There is one more problem... The boot code is not 'rom', and would have to have .bss zeroed and .data reinitalized.  This needs to be fixed, with a new linker script and crt0

Cheers,
J.

> On Jul 18, 2016, at 09:43, Geoff Salmon <gsalmon at se-instruments.com> wrote:
> 
>> 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
> 
> _______________________________________________
> J-core mailing list
> J-core at lists.j-core.org
> http://lists.j-core.org/mailman/listinfo/j-core