# # 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.