Here the I2C bit bangging is tied to the virtual clock (VCLK) but could easily be tided to a timer interrupt (or even polled if necessary).

VCLK driven bit bangging, reduces CPU overhead at the cost of extra I/O interconnections. It allows several CPUs of varying speeds to be connected to a common free running clock signal. This clock ensures that all CPUs are always no more than one clock cycle apart. The VCLK is driven by the state machine schedular. Consequently tying the I2C bit bangger to the VCLK causes comms to be driven as a background task. Tying the I2C bit bangger to a timer interrupt causes comms to be driven as a foreground time critical task. Driving the comms in the background allows the CPU to drive other critical I/O with greater ease and accuracy (e.g. driving stapper motors or timming external events).

Driving the I2C comms (bit banger) via the timer interrupt could cause problems in systems consisting of several CPUs with large speed differences since a data producer could swamp a data consumer. The VCLK reduces the buffering requirements of each CPU since received data can be consumed by the state machine as it arrives i.e. VCLK driven comms is synchronous with the state machine schedular.

I2C and VCLK are multi-drop buses. This meens that several CPUs can be connected in parallel to these buses, and provided they stick to the defined protocol they will not interfere with each other.

The VCLK component and I2C component generates machine code which is directly executable in the target system. No additional debug code is generated for the simulator. Signaling between different CPUs is performed by reading from and writing to real CPU I/O ports. The simulator uses I/O components mapped to the CPU's I/O ports to route the signals between simulated CPUs. (see I/O components above for further information).