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