From b16a1f4c4fcbc6bc90bbe25fb0534a02f0923226 Mon Sep 17 00:00:00 2001 From: Mike Frysinger Date: Thu, 24 Mar 2011 03:18:17 +0000 Subject: sim: bfin: document SIC limitation Signed-off-by: Mike Frysinger --- sim/bfin/TODO | 24 +++++++++++++++++++++++- 1 file changed, 23 insertions(+), 1 deletion(-) (limited to 'sim/bfin/TODO') diff --git a/sim/bfin/TODO b/sim/bfin/TODO index d180ab2..b81d770 100644 --- a/sim/bfin/TODO +++ b/sim/bfin/TODO @@ -19,7 +19,29 @@ fix single stepping over debug assert instructions in hardware exception in IVG5 causes double fault ? -add a "file" option to the async banks to back it +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 -- cgit v1.1