55 lines
2.1 KiB
Plaintext
55 lines
2.1 KiB
Plaintext
need to review ASTAT write behavior
|
|
|
|
how to model RETE and IVG0 bit in IPEND ...
|
|
|
|
model the loop buffer ? this means no ifetches because they're cached.
|
|
see page 4-26 in Blackfin PRM under hardware loops.
|
|
|
|
handle DSPID at 0xffe05000
|
|
|
|
CEC should handle multiple exceptions at same address. would need
|
|
exception processing to be delayed ? at least needs a stack for
|
|
the CEC to pop things off.
|
|
|
|
R0 = [SP++]; gets traced as R0 = [P6++];
|
|
|
|
merge dv-bfin_evt with dv-bfin_cec since the EVT regs are part of the CEC
|
|
|
|
fix single stepping over debug assert instructions in hardware
|
|
|
|
exception in IVG5 causes double fault ?
|
|
|
|
SIC int forwarding doesn't accurately reflect the hardware. what the sim
|
|
does is:
|
|
- device generates an interrupt
|
|
- int is sent to SIC
|
|
- SIC logs it into its ISR
|
|
- so long as SIC's IMASK allows it, bits set in ISR generate
|
|
an interrupt to the CEC
|
|
- no way to clear the SIC's ISR
|
|
the way the hardware works is that the device monitors the interrupt level and
|
|
the SIC's ISR bits are basically hardwired from each peripheral. so when the
|
|
device has its interrupt cleared, the bit in the SIC's ISR is automatically
|
|
cleared as well.
|
|
perhaps the only way to model this behavior in the sim is to have each device
|
|
set up an event callback that sends out a port event: a level of 0 means the
|
|
int has been ACKed and the SIC can clear its ISR while a level of 1 means the
|
|
int is being generated still. if the device is still generating an interrupt,
|
|
it can reschedule itself again.
|
|
|
|
insns that cause an interrupt don't seem to be processed at the right time.
|
|
for example, setup a glue device that generates an interrupt upon right.
|
|
when the store insn is executed, the interrupt is taken right away instead
|
|
of being scheduled *after* the insn has finished executing. difference is
|
|
that RETI needs to point to the *next* insn and not the store insn.
|
|
|
|
tests:
|
|
- check AN bits with Dreg subtraction
|
|
R0 = R1 - R2;
|
|
- check astat bits with vector add/sub +|+
|
|
- check acc with VIT_MAX and similiar insns
|
|
|
|
flush[0xffa00000] causes HWERR in sim but not on hardware ?
|
|
|
|
convert to using do_hw_attach_regs ?
|