Open keegandent opened 1 month ago
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:
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.
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.
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
Expected API Impact
This will create a non-breaking API change in various
fpga.Processor
methods