lava.magma.core.model
lava.magma.core.model.interfaces
digraph inheritance34a85b7057 { bgcolor=transparent; rankdir=TB; size=""; "ABC" [fillcolor=white,fontname="Vera Sans, DejaVu Sans, Liberation Sans, Arial, Helvetica, sans",fontsize=10,height=0.25,shape=box,style="setlinewidth(0.5),filled",tooltip="Helper class that provides a standard way to create an ABC using"]; "AbstractPortImplementation" [URL="../lava/lava.magma.core.model.html#lava.magma.core.model.interfaces.AbstractPortImplementation",fillcolor=white,fontname="Vera Sans, DejaVu Sans, Liberation Sans, Arial, Helvetica, sans",fontsize=10,height=0.25,shape=box,style="setlinewidth(0.5),filled",target="_top"]; "ABC" -> "AbstractPortImplementation" [arrowsize=0.5,style="setlinewidth(0.5)"]; }- class lava.magma.core.model.interfaces.AbstractPortImplementation(process_model, shape=(), d_type=<class 'int'>)
Bases:
ABC- abstract property csp_ports: List[AbstractCspPort]
Returns all csp ports of the port.
- join()
Join all csp ports
- property shape: Tuple[int, ...]
Returns the shape of the port
- start()
Start all csp ports.
lava.magma.core.model.model
digraph inheritanced5de39f972 { bgcolor=transparent; rankdir=TB; size=""; "ABC" [fillcolor=white,fontname="Vera Sans, DejaVu Sans, Liberation Sans, Arial, Helvetica, sans",fontsize=10,height=0.25,shape=box,style="setlinewidth(0.5),filled",tooltip="Helper class that provides a standard way to create an ABC using"]; "AbstractProcessModel" [URL="../lava/lava.magma.core.model.html#lava.magma.core.model.model.AbstractProcessModel",fillcolor=white,fontname="Vera Sans, DejaVu Sans, Liberation Sans, Arial, Helvetica, sans",fontsize=10,height=0.25,shape=box,style="setlinewidth(0.5),filled",target="_top",tooltip="Represents a model that implements the behavior of a Process."]; "ABC" -> "AbstractProcessModel" [arrowsize=0.5,style="setlinewidth(0.5)"]; }- class lava.magma.core.model.model.AbstractProcessModel(proc_params, loglevel=30)
Bases:
ABCRepresents a model that implements the behavior of a Process.
ProcessModels enable seamless cross-platform execution of Processes. In particular, they enable building applications or algorithms using Processes agnostic of the ProcessModel chosen at compile time. There are two broad categories of ProcessModels: 1. LeafProcessModels allow to implement the behavior of a Process directly in different languages for a particular compute resource. ProcessModels specify what Process they implement and what SynchronizationProtocol they implement (if necessary for the operation of the Process). In addition, they specify which compute resource they require to function. All this information allows the compiler to map a Process and its ProcessModel to the appropriate hardware platform. 2. SubProcessModels allow to implement and compose the behavior of a Process in terms of other Processes. This enables the creation of hierarchical Processes and reuse of more primitive ProcessModels to realize more complex ProcessModels. SubProcessModels inherit all compute resource requirements from the Processes they instantiate. See documentation of AbstractProcessModel for more details.
ProcessModels are usually not instantiated by the user directly but by the compiler. ProcessModels are expected to have the same variables and ports as those defined in the Process but with an implementation specific to the ProcessModel. I.e. in a PyProcessModel, a Var will be implemented by a np.ndarray and a Port might be implemented with a PyInputPort. The compiler is supposed to instantiate these ProcModels and initialize those vars and ports given initial values from the Process and implementation details from the ProcModel. For transparency, class attributes and their types should be explicitly defined upfront by the developer of a ProcModel to avoid lint warnings due to unresolved variables or unknown or illegal types.
This is a proposal of a low-boilerplate code convention to achieve this:
The same Vars and Ports as defined in the Process must be defined as class variables in the ProcessModels.
These class variables should be initialized with LavaType objects. LavaTypes specify the future class-type of this Var or Port, the numeric d_type and precision and maybe dynamic range if different from what would be implied by d_type. The compiler will later read these LavaTypes defined at the class level to initialize concrete class objects from the initial values provided in the Process. During this process, the compiler will create object level attributes with the same name as the class level variables. This should not cause problems as class level and instance level attributes can co-exist. However, instance level attributes shadow class level attributes with the same name if they exist.
Direct type annotations should be used equal to the class type in the LavaType to suppress type warnings in the rest of the class code although this leads to a bit of verbosity in the end. We could leave out the class type in the LavaType and infer it from ProcModel.__annotations__ if the user has not forgotten to specify it.
Process can communicate arbitrary objects using it’s
proc_paramsmember. This should be used when such a need arises. A Process’sproc_prams(empty dictionary by default) should always be used to initialize it’s ProcessModel.
- implements_process: ty.Optional[ty.Type[AbstractProcess]] = None
- implements_protocol: ty.Optional[ty.Type[AbstractSyncProtocol]] = None
- required_resources: ty.List[ty.Type[AbstractResource]] = []
- tags: ty.List[str] = []