legion/docs/readmes/README.service_processor

#
# Copyright 2006 Sun Microsystems, Inc.  All rights reserved.
# Use is subject to license terms.
#
# ident "@(#)README.service_processor   1.1     06/09/24 SMI"
#
#
#       Using the service_processor directive
#

[-] Introduction

    If you are running legion in parallel with a Service Processor
    simulation (sp library, stub, co-simulation, etc), you may want
    legion to wait for some event from the Service Processor before
    starting to execute instructions. In order to support this, a
    service_processor directive has been added to legion's config file.
    Once this directive exists, legion will setup all it's internal
    state but wait for a global variable (options.sp.poweron) to be
    set to true before starting to execute any instructions.

[1] How to set this up
    Add the following to your legion config file:

        system "dumbblue" {
                service_processor "generic_sp" {}       //<<---Add this

                domain (
                        ...

[2] How the SP signals legion to start

    The assumption is that your Service Processor is now somehow
    connected to legion (shared mem, sockets, sram etc) and that
    there is some portion of this Service Processor code that runs
    within legion's address space. Once the poweron event or
    de-assertion of the reset pin occurs on the Service Processor,
    the sp code running within legion can set options.sp.poweron
    to true which will cause the simulation to start executing
    instructions.


[3] Starting Service processor application from within config file

    If there are applications that need to be started at the same
    time as legion in order to setup the co-simulation environment
    you can start these application from within the legion config
    file using the 'xterm' directive withing the service_processor
    directive as follows:

        system "dumbblue" {
                service_processor "generic_sp" {
                        xterm "./service_processor_stub &";
                        xterm "./communications_channel &";
                }

        domain {
                ...

    The arguments to xterm above are simply passed to a system(2)
    call within legion. No measures are taken to terminate these
    processes once legion terminates. That is up to the Service
    Processor code.