#10 Simulate Multiple Processors

open
nobody
None
5
2005-10-22
2005-10-22
Scott Dattalo
No

Provide a mechanism whereby multiple processors can be
simulated.

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.

Discussion

  • 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

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

     
  • 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):

    <uC#01:p16f628a>
    <uC#02:p16f627>
    <uC#03:p16f84>

    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
    or
    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'

     


Anonymous


Cancel   Add attachments