Re: multiprocessor architecture...3

[Francesco Poletti]

Yes is properly that, the pool vay I think may be a first implementation
but after I need to improve my simulator like this I need to understand
better how the second two methods works...
Francesco
> 
> 
> Francesco Poletti wrote:
> > 
> > Sorry Joel, I was looking for some architecture suggestion: my
simulator
> > is under development and I don't know which is best way to implement
the
> > mechanism by which a processore may be able to interrupt another. I
> > don't know which are architectural possibility...If anyone may
suggest
> > me where I can find documentation.
> 
> Three possibilities I know of.. others probably exist:
> 
>  + poll
>  + board feature for in inter-board interrupt.  I know the Motorola
>    VME m68k boards tended to have this feature as did other vendors.
>  + CPU feature.  The hppa had an interprocessor bus for SMP boards.
>    Based upon the "node number" in the system (hardcoded), each 
>    CPU had some MP communications registers at a certain address.
>    These included this type of interrupt.  This is the only CPU RTEMS
>    has been ported to that I know has this type of feature.  
> 
> Your simulator has to simulate a CPU and its external peripherals to
> provide a complete -- if simple -- system.
> 
> Is that more what you were looking for?
> 
> > Francesco
> > >
> > >
> > > Francesco Poletti wrote:
> > > >
> > > > Hy, I'm developing a multi arm simulator which one day... will
be
> > boot
> > > > with rtems.
> > > > When I read the shared memory code I saw that may be important
for
> > the
> > > > comunication between processor which one node will able to
interrupt
> > > > another node. In my simulator this thing isn't implemented and
I'm
> > > > asking which way may be more coorect...I'm looking for
documentation
> > but
> > > > I don't find anything interesting.
> > >
> > > Not surprising as this is a shared memory driver specific
question.
> > > It supports using either interrupts between the boards or
installing a
> > > routine that is called on each clock tick to poll for new packets.
> > > This is configurable on a per BSP basis via the shmconfig support.
> > >
> > > [NOTE: The shared memory driver predates the Classic API timer
> > > manager.  It really should use the timer manager for its polling
> > > routine instead of the clock tick trick it is currently using.]
> > >
> > > > Thanks to anyone which can help me.
> > > > Francesco.
> > >
> > > --
> > > Joel Sherrill, Ph.D.             Director of Research &
Development
> > > joel at OARcorp.com                 On-Line Applications Research
> > > Ask me about RTEMS: a free RTOS  Huntsville AL 35805
> > > Support Available                (256) 722-9985
> > >
> 
> -- 
> Joel Sherrill, Ph.D.             Director of Research & Development
> joel at OARcorp.com                 On-Line Applications Research
> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
> Support Available                (256) 722-9985
>