(Refactor) Abstract Base Class for Modules

[AlexMontgomerie]

This refactor will define a new standardised interface for modules. The goal if for the module classes to be lightweight, and correspond closely with the hardware parameters. This refactor introduces a Port object, which describes the interfaces into and out of modules, and is standard across all modules. This means that there is a unified description from single port modules like Accum to multiport like VectorDot and Concat.

Registry is used in this refactor as well, as a way of building modules based on architecture parameters. For example, the following code builds an Accum module for the chisel backend, without having to explicitly declare the AccumChisel module.

from fpgaconvnet.models.modules import ModuleBase
from fpgaconvnet.architecture import BACKEND, DIMENSIONALITY

# open configuration
with open(config_path, "r") as f:
    config = json.load(f)

# initialise module
module = ModuleBase.build("accum", config,
        backend=BACKEND.CHISEL, dimensionality=DIMENSIONALITY.TWO)

[AlexMontgomerie]

For the resource modelling side of things, I'm a bit stuck with where to go next. So far, I've tried to abstract out module, resource and solver specific parts of resource modelling, so that it is more extensible. The script below describes what I've got so far.

from fpgaconvnet.models.modules.database import load_resource_dataset
from fpgaconvnet.models.modules.resources import NNLSHeuristicResourceFitter, SVRResourceFitter

from fpgaconvnet.models.modules import AccumChisel

# get the dataset
train, test = load_resource_dataset("test", AccumChisel)
print(len(train.docs), len(test.docs))

# fit to the training data
fitter = NNLSHeuristicResourceFitter()
fitter.fit(train, "ff")
print(fitter.get_accuracy(train, test, "ff"))

[AlexMontgomerie]

It is an very important step that helps sort out the relationship between the model and the backend. Thanks Alex! If I am not mistaken, so everything currently under the module directory will be dispatched to their own folder, just like the accum one?

Yeah exactly, and we can have different classes for each backend or variation, and so on within the sub-directory. We'll just need to specify the name, backend and dimensionality for each of the modules first

[ptoupas]

I think the idea and how you proceed with the code refactoring regarding the Modules is really good and relatively easy to follow. Its a very good thing to have this (perfectly) aligned with the backend since it will make things easier when it comes to understanding the existing modules and their modeling with respect to the hardware and to create new ones.

One (minor) comment that I have got (apart from the two comments/questions above) is regarding the type hints that we are using in the code. Even though we are (trying) to use type hinting from typing library there are many occasions where we use the native python objects and structures like list, or dict instead of the typing.List or typing.Dict. My suggestion is that we should try to be consistent and only use one or the other. We shouldn't mix them up.