#10 Simulate Multiple Processors


Provide a mechanism whereby multiple processors can be

Proposed implementation:

gpsim has most of the infrastructure in place to
simulate multiple processors at once. Unfortunately the
user interface is really only designed to support a
single processor. So it's proposed that multiple
processor simulation be supported with multiple gpsim
sessions each simulating a single processor. The
sessions can link to one another with module wrappers.
The wrappers allow the processors to interconnect and
allow their simulation times to be synchronized.


  • Nobody/Anonymous

    Logged In: NO

    theoretically, you could also employ the existing socket interface to facilitate working with multi-controller environments, where basically multiple sessions would be inter-linked via sockets to exchange configurable data via pre-defined mechanisms (i.e. a simple way to implement a connection between ports of multiple running controllers), that way you could even implement a full BUS

  • Nobody/Anonymous

    Logged In: NO

    the latter is actually an interesting idea, as it would basically mean to provide a well-defined socket interface to the controller's pins, which could eventually facilitate interfacing running gpsim instances with other electronics simulation software such as for example spice, so that actually running different simulators together would only boil down to providing the corresponding "glue" modules for each particular simulator.

  • Nobody/Anonymous

    Logged In: NO

    one could also consider extending the current UI to make usage with more than one processor more intuitive, i.e. for starters:

    - present the interactive CLI mode as a "shell" with context information, a shell that shows directly which processor context is currently set active (that is, the TARGET for any processor-specific commands):


    Then, one could provide additional commands to switch to different uCs using some sort of switch/set instruction that may be followed by either a unique ID/number or the PIC name.
    Having an instruction that will allow users to add/edit/remove controllers would then also be useful.

    For situations where it is not feasible to switch contexts, one could provide some sort of "immediate" mode where processor-specific instructions either need to be pre-pended a target ID, or appended, i.e:

    uc#01 du e
    du e uc#01

    alternatively one could use a more intuitive syntax such as:

    uc#01.du e ; // du is executed for uc#01 with argument 'e'

  • Martin Habets

    Martin Habets - 2014-12-08

    The UART method documented for ucsim should also work between ucsim and gpsim, or 2 instances of gpsim.

    We could also connect 2 instances of gpsim together using the analog FileRecorder and FileStimulus modules.

    Is anything else needed to complete this feature? Should we provide a howto document on this and/or a full example?



Cancel  Add attachments

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks