12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455 |
- 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 ?
|