Commit | Line | Data |
---|---|---|
ef016f83 MF |
1 | need to review ASTAT write behavior |
2 | ||
3 | how to model RETE and IVG0 bit in IPEND ... | |
4 | ||
5 | model the loop buffer ? this means no ifetches because they're cached. | |
6 | see page 4-26 in Blackfin PRM under hardware loops. | |
7 | ||
8 | handle DSPID at 0xffe05000 | |
9 | ||
10 | CEC should handle multiple exceptions at same address. would need | |
11 | exception processing to be delayed ? at least needs a stack for | |
12 | the CEC to pop things off. | |
13 | ||
14 | R0 = [SP++]; gets traced as R0 = [P6++]; | |
15 | ||
16 | merge dv-bfin_evt with dv-bfin_cec since the EVT regs are part of the CEC | |
17 | ||
18 | fix single stepping over debug assert instructions in hardware | |
19 | ||
20 | exception in IVG5 causes double fault ? | |
21 | ||
b16a1f4c MF |
22 | SIC int forwarding doesn't accurately reflect the hardware. what the sim |
23 | does is: | |
24 | - device generates an interrupt | |
25 | - int is sent to SIC | |
26 | - SIC logs it into its ISR | |
27 | - so long as SIC's IMASK allows it, bits set in ISR generate | |
28 | an interrupt to the CEC | |
29 | - no way to clear the SIC's ISR | |
30 | the way the hardware works is that the device monitors the interrupt level and | |
31 | the SIC's ISR bits are basically hardwired from each peripheral. so when the | |
32 | device has its interrupt cleared, the bit in the SIC's ISR is automatically | |
33 | cleared as well. | |
34 | perhaps the only way to model this behavior in the sim is to have each device | |
35 | set up an event callback that sends out a port event: a level of 0 means the | |
36 | int has been ACKed and the SIC can clear its ISR while a level of 1 means the | |
37 | int is being generated still. if the device is still generating an interrupt, | |
38 | it can reschedule itself again. | |
39 | ||
40 | insns that cause an interrupt don't seem to be processed at the right time. | |
41 | for example, setup a glue device that generates an interrupt upon right. | |
42 | when the store insn is executed, the interrupt is taken right away instead | |
43 | of being scheduled *after* the insn has finished executing. difference is | |
44 | that RETI needs to point to the *next* insn and not the store insn. | |
ef016f83 MF |
45 | |
46 | tests: | |
47 | - check AN bits with Dreg subtraction | |
48 | R0 = R1 - R2; | |
49 | - check astat bits with vector add/sub +|+ | |
50 | - check acc with VIT_MAX and similiar insns | |
7935c6b0 MF |
51 | |
52 | flush[0xffa00000] causes HWERR in sim but not on hardware ? | |
53 | ||
54 | convert to using do_hw_attach_regs ? |