Networking, address spaces and systems

TCP/IP version 4 specifies a network addressing scheme which uses a four-octet address for each node on the network, and in Controlix each control presents to the system a network physical-port analogy which provides the control with an IPv4 address that it can use to interact with the rest of the system. When an IP address is used in Controlix by a control, it can therefore categorize that control in one of four ways:

• Class A address space: Synchronous controls. These controls roughly correspond to a traditional device driver, and represent a specific motif which should encapsulate and provide access to as well as be driven by the functionality of an underlying basis. For a typical, fixed-function ASIC, this basis will usually be a standard bus protocol seen on external pins, such as a memory or I/O bus, or pins which have been strapped high or have a fixed function such as clock or flow control lines. For an FPGA, this will turn into a set of ports representing simple interfaces such as memory or external synchronous busses/bridges. For CPU-based systems, the basic system control set becomes more complex as asynchronous busses with interrupts and the devices which use them come into play and must be synchronously polled. Finally there is the user-layer where the system controls can often represent abstract interfaces such as POSIX file I/O or TCP/IP sockets, which must be asynchronously buffered with FIFOs.

• Class B address space: Asynchronous controls. These controls encapsulate functionality in a higher-level space then the basic system control set, and in this environment buffering, protocol routing and interface translation are commonly seen as underlying motifs. On ASICS, these functions are often absent, or implemented internally as a design convenience only. On FPGAs, external physical interfaces such as serial or ethernet ports are commonly managed at this level. CPU-based systems usually manage more complex, DMA-using devices such as graphics/sound/video, disk interfaces such as IDE or SCSI, or more advanced, I/O-buffered network cards. At the user layer, we see more complex system interfaces like generic message passing encapsulated.

• Class C address space: Demultiplexing controls. Demultiplexing usually refers to a process by which multiple types of data which have been serialized into a FIFO are deserialized based on a protocol. In the systems context in which Controlix is set, this usually means that a protocol server application is running, accepting input messages requesting services and sending return messages providing the requested service results. ASICS only provide one specific service to a specific and hardwired set of other single-service ASICS, and as such are usually not represented by as class C address in Controlix. FPGAs are also not often seen encapsulated at class C, due to the fact that they are not dynamically reprogrammable. CPUs are, and that is why "computer program space" usually starts at this level. The user layer usually consists of more application-specific code, such as math libraries, application-specific network protocol handlers like web or shell servers, or resource virtualization management such as virtual private network management or a graphical user interface with multiple z-order windowing.

• Class D address space: Multiplexing controls. This is "application space", and is usually composed of programs which make use of services at class C in a hierarchical fashion but do not typically provide any such hierarchical services themselves, restricting general messaging to external peer-to-peer networking or internal thread-to-thread style interprocess communication. This being the application level, ASICs, FPGAs and even CPUs are not seen much in abstraction at class D, and this often means that controls are represented in a generic fashion and can take a variety of forms - binary executables, scripts, plug-ins or even abstract interface patterns such as XML-based "presentation apps".