| SID Simulator Component Developer's Guide | ||
|---|---|---|
| <<< Previous | Theory of Operations for bridge-tcl Component | Next >>> |
Once a Tcl program is loaded into the interpreter, it is able to make outgoing SID API calls, not merely respond to incoming ones. All SID API functions are exposed to Tcl as procedure hooks, in a very symmetric way to the incoming calls. Simply, each function in the incoming set has a shadow: sid::component::FUNCTION, sid::pin::FUNCTION or sid::bus::FUNCTION, as appropriate. Each outgoing procedure takes a receiver handle (the same opaque string passed in an incoming call) as its first argument.
There is no checking that would prevent an outgoing SID API call from becoming recursive and referring to the originating component, either directly or indirectly. As for all other components, infinite recursion prevention is the responsibility of the component author.
| Incoming | Outgoing |
|---|---|
| attribute_value $name | sid::component::attribute_value $component $name |
| driven_h4 $pin $value | sid::pin::driven_h4 $pin $value |
There are some special outgoing functions that function as constructors for local object handles.
Returns an opaque string handle to this component.
Returns an opaque string handle to a new private C++ pin, usable as a return value to find_pin.
Returns an opaque string handle to a new private C++ bus, usable as a return value to find_bus.
| <<< Previous | Home | Next >>> |
| Theory of Operations for bridge-tcl Component | Up | Sample Source Code |