Multiple Networks on Processor

[keegandent]

Problem(?)

The current fpga.Processor has incomplete compliance with the Framework API in that it only supports one network per processor.

Proposed Solution

It should not be too difficult to add support for multiple networks to the RTL design. The source packets will need a "network index" field, and the behavior of sink packets should be unaffected as the processor design is still synchronous.

Hurdles

• Considering the index associated with a given network has no bearing on the performance of that network, it may be better to associate EDA projects and hashes to network combinations and not permutations, with the software handling index mapping
• Under the assumed paradigm of a single packet structure corresponding to both networks, there is significant wasted communication bandwidth for networks with different input or output number of neurons. Heterogeneous packet structures would introduce complexity.
• Networks will need identical processor parameters unless we want to implement compatibility logic.

Expected API Impact

This will create a non-breaking API change in various fpga.Processor methods

[jimplank]

For those without history, the network_id parameter of all of the processor calls in the framework came from Parker when he was designing Caspian, and wanted the feature. He never implemented it in Caspian, and more telling, no one has implemented the feature in any of the simulators (including Caspian). Unless someone really wants it, I think this should be a "punt until later" issue. As you intimate, there are some widely different use cases:

• We want identical networks doing different things (e.g. dbscan)
• We want different networks working on identical things (e.g. EONS in the loop)
• We wand different networks working on different things (e.g. one dbscan and one classification).

I don't think we should sacrifice any current packet structure for a future where we don't really know what we'll be doing -- just my thoughts.

[keegandent]

I am good with putting a defer/delay label on this issue then.

It’s worth keeping in mind this will create a limitation of one network per interface, so if a target board has only a single UART to communicate with a workstation, that workstation can only use one FPGA-based network at a time.

For embedded clients, this isn’t an issue; we can wire multiple UART processors to the header pins, up to the number the client will support. For MPSoC boards it’s even better as the device tree could be expanded for an indefinite number of UART or, once Bryson’s work is integrated, DMA processors.

I will say, it may be possible to have the portion of the packet structure after the network ID be dynamic and allow variation in length, but I think that would involve splitting all the sources and sinks into two layers instead of one. But I’m all for punting that kind of complexity.