Re: [ECOS] generating interrupts in ARM-PID (SID simulator)

["Frank Ch. Eigler" <fche at redhat dot com>]

Hi -


On Tue, Jul 01, 2003 at 01:50:14PM -0700, Partha Palit wrote:
> [...]
> As recommened by Robert, I tried using the interrupt
> 11.It seemed to work, but it showed up as spurious
> interrupt which is not handled by the ARM Hal. I guess
> this is becuase ARM recognizes level triggered
> interrupts as pointed out by Robert.

I would be surprised if that were the case.  At the time
that the interrupt is first asserted, the OS has no way
of knowing whether it was an edge or level type interrupt.
If it never even dispatches to your handler, on account of
spuriousity, then there is a software problem.  I would
expect an edge- vs level-triggering problem would show
itself by having an interrupt refusing to be masked off.


> -->Q: Could anyone kindly tell how to generate pulses
> of definite time period using sid-sched? [...]

First thing, one must be aware of how sid models signals
like this.  The basic signalling primitive takes a 32-bit
value, and can be interpreted as a pulse, an edge, or an
abstract event - the interpretation depends on the sender
and receiver.  Modules that want to model level-sensitive
phenomena sometimes use a 1-valued signal for the leading edge
and a 0-valued one for the trailing edge of the entire pulse.

It turns out that the scheduler sends a 0-valued abstract
signal when an event fires.  This does not seem appropriate
after all for direct connection to the hw-interrupt-arm/ref
inputs, which appears to prefer 1-/0- type signal pairs to
delimit pulses.

I suspect a reasonable way to go is to extend the scheduler
to allow the driven event signal to have a configurable value.
Then, one can send a proper 1-valued leading edge of a pulse
from the scheduler.  (This would require some very minor
code extensions to sid/component/sched.)

The trailing edge is normally caused by target software action
(the interrupt handler acknowledging it), so this could be
modelled by use of the hw-glue-probe-bus component.  This
little widget can be memory-mapped anywhere, and transmits on
pins the parameters of an incoming memory access.  It could
map a "write 0x0 to 0xA8000040" to a single pin event of value
0x0, suitable to connect to the same interrupt controller input.
It needs a dummy downstream memory object too:

  new hw-glue-probe-bus uninterruptor
  new hw-memory-ram/rom-basic dummy
  connect-bus cpu-mapper unint:[0xA800040,0xA8000043] uninterruptor upstream
  connect-pin uninterruptor data-low -> intctrl interrupt-signal-11
  set dummy size 4
  connect-bus uninterruptor downstream dummy read-write-port
  connect-pin target-sched 888-event -> intctrl interrupt-signal-11
  set target-sched 888-value 1 # not yet implemented
  set target-sched 888-time 8888


> Also I had to manually generate the interrupt in the
> SID tksm GUI. Otherwise it was not working.  [...]

I'm glad you found your way around the GUI.


- FCHE

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss