binutils-gdb/sim/bfin/TODO

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 ?