sim: bfin: document SIC limitation

Signed-off-by: Mike Frysinger <vapier@gentoo.org>

2 files changed, 27 insertions, 1 deletions

diff --git a/sim/bfin/ChangeLog b/sim/bfin/ChangeLog
index 36c8665..c5ab9ae 100644
--- a/sim/bfin/ChangeLog
+++ b/sim/bfin/ChangeLog
@@ -1,5 +1,9 @@
 2011-03-23  Mike Frysinger  <vapier@gentoo.org>
 
+	* TODO: Document some known SIC issues.
+
+2011-03-23  Mike Frysinger  <vapier@gentoo.org>
+
 	* devices.h (dv_w1c): Fix typos in documentation of "bits" arg.
 	* dv-bfin_cec.c (bfin_cec_io_write_buffer): Pass 0xffee to dv_w1c_4.
 	* dv-bfin_emac.c (bfin_emac_io_write_buffer): Pass 0xe1 to dv_w1c_4
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