[J-core] What is the correct way to reset the CPU?
gsalmon at se-instruments.com
Mon Jul 18 09:43:45 EDT 2016
On 16-07-18 05:43 AM, Robert Ou wrote:
> 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 core : decode_core
use entity work.decode_core(arch)
generic map (
decode_type => REVERSE,
reset_vector => DEC_CORE_RESET);
for table : decode_table
use entity work.decode_table(reverse_logic);
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.
More information about the J-core