public inbox for sid@sourceware.org
 help / color / mirror / Atom feed
From: "Frank Ch. Eigler" <fche@redhat.com>
To: Partha Palit <chessrook2001@yahoo.com>
Cc: ECOS <ecos-discuss@sources.redhat.com>, SID <sid@sources.redhat.com>
Subject: Re: [ECOS] generating interrupts in ARM-PID (SID simulator)
Date: Tue, 01 Jul 2003 23:53:00 -0000	[thread overview]
Message-ID: <20030701235347.GC24380@redhat.com> (raw)
In-Reply-To: <20030701205014.61802.qmail@web12908.mail.yahoo.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

  reply	other threads:[~2003-07-01 23:53 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20030627094625.GN341@biferten.ma.tech.ascom.ch>
2003-06-27 13:40 ` Robert Cragie
2003-07-01 20:50   ` Partha Palit
2003-07-01 23:53     ` Frank Ch. Eigler [this message]
2003-07-02 10:10     ` Robert Cragie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030701235347.GC24380@redhat.com \
    --to=fche@redhat.com \
    --cc=chessrook2001@yahoo.com \
    --cc=ecos-discuss@sources.redhat.com \
    --cc=sid@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).