Current implementation of AGWB has problems with FPGAs hosting e.g. multiple PCIe devices (an example may be huge Xilinx FPGA with two SLRs).
In that case we may have two independent and slightly different WB-based devices, which must be implemented in the same device. The simplest solution would be to prepare two separate top blocks with two different sets of parameters, but that may result in generation of entities with the same names and e.g. different types of ports.
This could be solved, by allowing the user to specify the name of the library generated for each top (e.g. instead of "agwb" in both cases, "agwb_slr1" for the first top, and "agwb_slr2" for the second top.
That solution however generates problems related to interfacing with the user logic, because the same entity can't include either one or the another library depending on generics (which could pass the SLR number).
wzab
commented
3 years ago
Current implementation of AGWB has problems with FPGAs hosting e.g. multiple PCIe devices (an example may be huge Xilinx FPGA with two SLRs). In that case we may have two independent and slightly different WB-based devices, which must be implemented in the same device. The simplest solution would be to prepare two separate top blocks with two different sets of parameters, but that may result in generation of entities with the same names and e.g. different types of ports. This could be solved, by allowing the user to specify the name of the library generated for each top (e.g. instead of "agwb" in both cases, "agwb_slr1" for the first top, and "agwb_slr2" for the second top. That solution however generates problems related to interfacing with the user logic, because the same entity can't include either one or the another library depending on generics (which could pass the SLR number).