[Simh] Emulating multiprocessors

Bill Beech (NJ7P) nj7p at nj7p.org
Tue Apr 5 16:39:19 EDT 2011


Bob,

I would love to see the code.  I have begun to look into running the 
processors in just the fashion you outline.  Polling on a 4 GHz machine 
is still much faster than any of these old 8 and 10 MHz processors.  
Realistically, I need to delay running each instruction to make the 
system operate as it originally did.

I really enjoy working on these old machines and SIMH is a fine tool for 
doing it.  Thanks again!

Bill

On 04/05/2011 12:37 PM, Bob Supnik wrote:
> I solved this problem when I used SIMH as the foundation for a 
> simulator of the SiCortex 6-core system on a chip.  I never published 
> that work while the company was in business, and now that it has 
> folded, I didn't think it was interesting anymore.
>
> I have permission from the inheritors of the IP to publish the 
> simulator, unsupported, if people want to look at the techniques it 
> used.  It was compiled against SIMH 3.8-0 and added many 
> system-specific features, so I don't think it will work against the 
> current distribution; it may not work on any environment except 64b 
> Linux, in fact.  It does have quite a reasonable MIPS64 emulator, 
> complete with floating point, which people might like.
>
> The SMP model is an extension of the multi-controller techniques used 
> in the PDP11 RQ simulator.  There is a global shared memory and IO 
> subsystem, and then all processor state is encapsulated in a large 
> structure, the context.  The CPU is no longer in charge; instead, it 
> provides a routine, cpu_one_inst, that is called multiple times from 
> the master controller (placed in the MEMory controller, for convenience):
>
>     while (reason == 0) {                               /* loop until 
> halted */
>
>         if (sim_interval <= 0) {                        /* check clock 
> queue */
>             if ((reason = sim_process_event ())) break;
>             eval_intr_all ();
>             }
>         sim_interval = sim_interval - 1;
>
>         reason = cpu_one_inst (cpu_ctx[0]);
>         for (i = 1/*not0*/; i < NUM_CORES; i++) {
>             if (cpu_enb[i] && (r1 = cpu_one_inst (cpu_ctx[i])))
>                 reason = cpu_report_err (reason, r1, dev_list[i], 
> cpu_ctx[i]);
>             }
>         }                                               /* end while */
>
> So all the cores execute in lockstep on a round robin basis; one 
> simulator cycle includes executing one instruction for all enabled 
> cores.  The simulator also included mechanisms for detecting when the 
> cores were idle and skipping them.
>
> Heterogeneous multiprocessing can be implemented the same way, except 
> that memory is local to each CPU, not global; and IO is not shared but 
> distributed among the CPUs.
>
> When we were implementing HP Access 2000 (linked processors), I looked 
> at rewriting the HP CPU and IO system to this model but concluded it 
> was too much trouble.  So Access runs separate simulator images that 
> communicate over sockets - inefficient but workable.
>
> /Bob Supnik
>
> _______________________________________________
> Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
>



More information about the Simh mailing list