PcieHost.bsv fails to build for multiple targets about connectal HOT 11 CLOSED

On Tue, Nov 9, 2021 at 12:06 PM Radhika Ghosal ***@***.***> wrote: Hi Jamey, thanks for your reply! So we've been trying to get open-source bluespec to play well with Connectal for an accelerator design we have (which previously used closed-source bluespec), for the vcu118 hardware target. We grabbed the open source versions of bsc and bsc-contrib and installed them in the appropriate places, and got the open source stuff working in simulation (using the build.verilator target). However we started hitting snags for build.vcu118. This is the first error we hit: BSV_BO [<path>/connectal/generated/xilinx/PCIEWRAPPER3u.bsv] make[1]: *** No rule to make target 'obj/XilinxVirtex7PCIE.bo', needed by 'obj/Pcie3EndpointX7.bo'. Stop. connectal/Makefile.connectal:57: recipe for target 'build.vcu118' failed make: *** [build.vcu118] Error 2 I couldn't find XilinxVirtex7PCIE.bo in any of B-Lang-Org <https://github.com/B-Lang-org/>'s official repos. I did however find it in an ancient unofficial copy <https://github.com/GaloisInc/BESSPIN-BSC/blob/master/src/lib/BSVSource/Xilinx/XilinxVirtex7PCIE.bsv> of the bluespec source floating around on GitHub, and copied that into Connectal. Compilation moved a bit further along but finally died at: Error: "<path>/connectal/bsv/PcieHost.bsv", line 87, column 8: (T0031) The provisos for this expression could not be resolved because there are no instances of the form: Add#(0, 16, 32) The proviso was implied by expressions at the following positions: "<path>/connectal/bsv/PcieHost.bsv", line 88, column 26 Error: "<path>/connectal/bsv/PcieHost.bsv", line 127, column 4: (T0031) The provisos for this expression could not be resolved because there are no instances of the form: Connectable::Connectable#(ClientServer::Server#(PCIE::TLPData#(16), PCIE::TLPData#(16)), ClientServer::Client#(PCIE::TLPData#(32), PCIE::TLPData#(32))) obj/Makefile:384: recipe for target 'obj/PcieHost.bo' failed I decided to get the examples compiled to narrow down where exactly do things break. Most of the examples compiled (for the vcu118, vc707g2, and the vcu108 targets), except memread256 and memwrite256, which died with the same error as above. It turns out keeping DataBusWidth=256 is the problem; our Connectal code uses DataBusWidth=256 as well. *The fix:* We've temporarily downgraded our Connectal interface to DataBusWidth=128 and everything compiles and runs okay for us. However our Connectal interface did work with DataBusWidth=256 with closed source bluespec, which leads me to suspect that either the open source version is missing some library, or Connectal itself isn't playing well with a bus size 256 wide. It would be great if you could help us figure this out! — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#185 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AASTPM27RMZ5PK5OL6YQ7YDULFIITANCNFSM5HPY6DEA> .

On Tue, Nov 9, 2021 at 2:28 PM Jamey Hicks ***@***.***> wrote: Hi Radhika, Please file a separate but about DataBusWidth=256. I had this working a long time ago, but the branch never got merged. I'm sure we can get it working again. Some of the Xilinx libraries were rejected from bsc-contrib for some reason. I don't know why. Importing into Connectal seems like a way to deal with it. On Tue, Nov 9, 2021 at 12:06 PM Radhika Ghosal ***@***.***> wrote: > Hi Jamey, thanks for your reply! > > So we've been trying to get open-source bluespec to play well with > Connectal for an accelerator design we have (which previously used > closed-source bluespec), for the vcu118 hardware target. > > We grabbed the open source versions of bsc and bsc-contrib and installed > them in the appropriate places, and got the open source stuff working in > simulation (using the build.verilator target). > > However we started hitting snags for build.vcu118. This is the first > error we hit: > > BSV_BO [<path>/connectal/generated/xilinx/PCIEWRAPPER3u.bsv] > make[1]: *** No rule to make target 'obj/XilinxVirtex7PCIE.bo', needed by 'obj/Pcie3EndpointX7.bo'. Stop. > connectal/Makefile.connectal:57: recipe for target 'build.vcu118' failed > make: *** [build.vcu118] Error 2 > > I couldn't find XilinxVirtex7PCIE.bo in any of B-Lang-Org > <https://github.com/B-Lang-org/>'s official repos. I did however find it > in an ancient unofficial copy > <https://github.com/GaloisInc/BESSPIN-BSC/blob/master/src/lib/BSVSource/Xilinx/XilinxVirtex7PCIE.bsv> > of the bluespec source floating around on GitHub, and copied that into > Connectal. > > Compilation moved a bit further along but finally died at: > > Error: "<path>/connectal/bsv/PcieHost.bsv", line 87, column 8: (T0031) > The provisos for this expression could not be resolved because there are no > instances of the form: > Add#(0, 16, 32) > The proviso was implied by expressions at the following positions: > "<path>/connectal/bsv/PcieHost.bsv", line 88, column 26 > Error: "<path>/connectal/bsv/PcieHost.bsv", line 127, column 4: (T0031) > The provisos for this expression could not be resolved because there are no > instances of the form: > Connectable::Connectable#(ClientServer::Server#(PCIE::TLPData#(16), PCIE::TLPData#(16)), ClientServer::Client#(PCIE::TLPData#(32), PCIE::TLPData#(32))) > obj/Makefile:384: recipe for target 'obj/PcieHost.bo' failed > > I decided to get the examples compiled to narrow down where exactly do > things break. Most of the examples compiled (for the vcu118, vc707g2, and > the vcu108 targets), except memread256 and memwrite256, which died with > the same error as above. > > It turns out keeping DataBusWidth=256 is the problem; our Connectal code > uses DataBusWidth=256 as well. > > *The fix:* > > We've temporarily downgraded our Connectal interface to DataBusWidth=128 > and everything compiles and runs okay for us. > > However our Connectal interface did work with DataBusWidth=256 with > closed source bluespec, which leads me to suspect that either the open > source version is missing some library, or Connectal itself isn't playing > well with a bus size 256 wide. > > It would be great if you could help us figure this out! > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <#185 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AASTPM27RMZ5PK5OL6YQ7YDULFIITANCNFSM5HPY6DEA> > . >