Zynq UltraScale+ MPSoC devices require 36 address bits to access the full range of DDR memory. Here is an image of the address map: [image: image.png] I discussed this with Jim previously when debugging a PL->PS dataplane issue. We were discussing the PS AXI slave's address width (OpenCPI's axi primitive's s_axi_hp_in_ar_t and s_axi_hp_in_aw_t ADDR) and its connection to SDP. From a previous conversation I had with Jim (quoted below) it turns out that SDP is capable of handling 36 address bits. "The address map says it all: to reach DDR above 2GB, you need to supply at least 36 address bits, and the address of that DRAM starts at 0x8.0000.0000. It looks like you are being provided an address in that window. The AXI addresses are indeed byte addresses. The sdp2axi adapter currently operates at 64 bits wide, and forces the 3 LSBs of the AXI byte address to zero. The width of the AXI address is correctly based on the width of the AXI address field, which should "do the right thing". So for now you need a copy of the adapter which simply has wider AXI address fields." - Jim It turns out that sdp2axi chooses its address width using the "axi_out.AW.ADDR'left", so the SDP address width is set to 36 bits if the s_axi_hp_aw/ar_t's address width is set to 36. So, I will need a version of the OpenCPI AXI primitive with s_axi_hp_in_aw/ar_t's ADDR set 36 bits wide. For now I have just overwritten this, but this will break support for existing OpenCPI platforms. What is the OpenCPI recommended method for having two parameterized versions of a type in an HDL primitive library? Is this possible? Or will I basically just need to create a second VHDL type(s) called 's_axi_hp_in_ar_36_t'? Thanks! -- David Banks dbanks@geontech.com Geon Technologies, LLC

It looks like VHDL-2008 allows for generic types, which would make this pretty easy by just giving the sdp2axi component a generic to fill in the types for its axi_in/out. If I remember correctly, OpenCPI's framework HDL cannot/should not be bound to versions >=VHDL-2008. Is this true? Thanks, David On Mon, Jan 14, 2019 at 9:06 AM David Banks <dbanks@geontech.com> wrote: > Zynq UltraScale+ MPSoC devices require 36 address bits to access the full > range of DDR memory. Here is an image of the address map: > [image: image.png] > I discussed this with Jim previously when debugging a PL->PS dataplane > issue. We were discussing the PS AXI slave's address width (OpenCPI's axi > primitive's s_axi_hp_in_ar_t and s_axi_hp_in_aw_t ADDR) and its connection > to SDP. From a previous conversation I had with Jim (quoted below) it > turns out that SDP is capable of handling 36 address bits. > > "The address map says it all: to reach DDR above 2GB, you need to supply > at least 36 address bits, and the address of that DRAM starts at > 0x8.0000.0000. > It looks like you are being provided an address in that window. > The AXI addresses are indeed byte addresses. > The sdp2axi adapter currently operates at 64 bits wide, and forces the 3 > LSBs of the AXI byte address to zero. > The width of the AXI address is correctly based on the width of the AXI > address field, which should "do the right thing". > So for now you need a copy of the adapter which simply has wider AXI > address fields." - Jim > > It turns out that sdp2axi chooses its address width using the > "axi_out.AW.ADDR'left", so the SDP address width is set to 36 bits if the > s_axi_hp_aw/ar_t's address width is set to 36. So, I will need a version of > the OpenCPI AXI primitive with s_axi_hp_in_aw/ar_t's ADDR set 36 bits wide. > For now I have just overwritten this, but this will break support for > existing OpenCPI platforms. What is the OpenCPI recommended method for > having two parameterized versions of a type in an HDL primitive library? Is > this possible? Or will I basically just need to create a second VHDL > type(s) called 's_axi_hp_in_ar_36_t'? > > Thanks! > -- > David Banks > dbanks@geontech.com > Geon Technologies, LLC > -- David Banks dbanks@geontech.com Geon Technologies, LLC

No code in OpenCPI currently depends on VHDL-2008 since tool support is do spotty. Its hard to know for sure without trying it on a variety of tools. Even googling around suggests that at least some version of Vivado crashes on this construct. I would still avoid it if it was not supported across the current tool set (isim/xsim/modelsim/ise/vivado2015+/quartus12+?). Too bad since it is a great solution... On 1/18/19 4:37 PM, David Banks wrote: > It looks like VHDL-2008 allows for generic types, which would make this > pretty easy by just giving the sdp2axi component a generic to fill in the > types for its axi_in/out. > > If I remember correctly, OpenCPI's framework HDL cannot/should not be bound > to versions >=VHDL-2008. Is this true? > > Thanks, > David > > On Mon, Jan 14, 2019 at 9:06 AM David Banks <dbanks@geontech.com> wrote: > >> Zynq UltraScale+ MPSoC devices require 36 address bits to access the full >> range of DDR memory. Here is an image of the address map: >> [image: image.png] >> I discussed this with Jim previously when debugging a PL->PS dataplane >> issue. We were discussing the PS AXI slave's address width (OpenCPI's axi >> primitive's s_axi_hp_in_ar_t and s_axi_hp_in_aw_t ADDR) and its connection >> to SDP. From a previous conversation I had with Jim (quoted below) it >> turns out that SDP is capable of handling 36 address bits. >> >> "The address map says it all: to reach DDR above 2GB, you need to supply >> at least 36 address bits, and the address of that DRAM starts at >> 0x8.0000.0000. >> It looks like you are being provided an address in that window. >> The AXI addresses are indeed byte addresses. >> The sdp2axi adapter currently operates at 64 bits wide, and forces the 3 >> LSBs of the AXI byte address to zero. >> The width of the AXI address is correctly based on the width of the AXI >> address field, which should "do the right thing". >> So for now you need a copy of the adapter which simply has wider AXI >> address fields." - Jim >> >> It turns out that sdp2axi chooses its address width using the >> "axi_out.AW.ADDR'left", so the SDP address width is set to 36 bits if the >> s_axi_hp_aw/ar_t's address width is set to 36. So, I will need a version of >> the OpenCPI AXI primitive with s_axi_hp_in_aw/ar_t's ADDR set 36 bits wide. >> For now I have just overwritten this, but this will break support for >> existing OpenCPI platforms. What is the OpenCPI recommended method for >> having two parameterized versions of a type in an HDL primitive library? Is >> this possible? Or will I basically just need to create a second VHDL >> type(s) called 's_axi_hp_in_ar_36_t'? >> >> Thanks! >> -- >> David Banks >> dbanks@geontech.com >> Geon Technologies, LLC >> >

Okay, thanks for the information. For now, I was able to move the entity declaration into a separate file. I then have another file with same declaration but using the axi_in type with 36-bit addresses. I also have a second sdp_axi_pkg file with the sdp2axi component declaration that uses 36-bit addresses for axi_in. In the Makefile, I then choose whether to use the 32 or 36 bit versions of sdp2axi's component and entity based on whether the HdlTarget is 'zynq_ultra'. This is how I am getting around duplicating the sdp2axi architecture. This way sdp2axi is always referred to with that name no matter where it is used, but its axi_in port changes its type (really just address-width) based on which HdlTarget is being used. Let me know if you have any better/cleaner ideas. Thanks, David On Fri, Jan 18, 2019 at 4:48 PM James Kulp <jek@parera.com> wrote: > No code in OpenCPI currently depends on VHDL-2008 since tool support is > do spotty. > Its hard to know for sure without trying it on a variety of tools. > Even googling around suggests that at least some version of Vivado > crashes on this construct. > > I would still avoid it if it was not supported across the current tool > set (isim/xsim/modelsim/ise/vivado2015+/quartus12+?). > > Too bad since it is a great solution... > > > > > > > On 1/18/19 4:37 PM, David Banks wrote: > > It looks like VHDL-2008 allows for generic types, which would make this > > pretty easy by just giving the sdp2axi component a generic to fill in the > > types for its axi_in/out. > > > > If I remember correctly, OpenCPI's framework HDL cannot/should not be > bound > > to versions >=VHDL-2008. Is this true? > > > > Thanks, > > David > > > > On Mon, Jan 14, 2019 at 9:06 AM David Banks <dbanks@geontech.com> wrote: > > > >> Zynq UltraScale+ MPSoC devices require 36 address bits to access the > full > >> range of DDR memory. Here is an image of the address map: > >> [image: image.png] > >> I discussed this with Jim previously when debugging a PL->PS dataplane > >> issue. We were discussing the PS AXI slave's address width (OpenCPI's > axi > >> primitive's s_axi_hp_in_ar_t and s_axi_hp_in_aw_t ADDR) and its > connection > >> to SDP. From a previous conversation I had with Jim (quoted below) it > >> turns out that SDP is capable of handling 36 address bits. > >> > >> "The address map says it all: to reach DDR above 2GB, you need to supply > >> at least 36 address bits, and the address of that DRAM starts at > >> 0x8.0000.0000. > >> It looks like you are being provided an address in that window. > >> The AXI addresses are indeed byte addresses. > >> The sdp2axi adapter currently operates at 64 bits wide, and forces the 3 > >> LSBs of the AXI byte address to zero. > >> The width of the AXI address is correctly based on the width of the AXI > >> address field, which should "do the right thing". > >> So for now you need a copy of the adapter which simply has wider AXI > >> address fields." - Jim > >> > >> It turns out that sdp2axi chooses its address width using the > >> "axi_out.AW.ADDR'left", so the SDP address width is set to 36 bits if > the > >> s_axi_hp_aw/ar_t's address width is set to 36. So, I will need a > version of > >> the OpenCPI AXI primitive with s_axi_hp_in_aw/ar_t's ADDR set 36 bits > wide. > >> For now I have just overwritten this, but this will break support for > >> existing OpenCPI platforms. What is the OpenCPI recommended method for > >> having two parameterized versions of a type in an HDL primitive > library? Is > >> this possible? Or will I basically just need to create a second VHDL > >> type(s) called 's_axi_hp_in_ar_36_t'? > >> > >> Thanks! > >> -- > >> David Banks > >> dbanks@geontech.com > >> Geon Technologies, LLC > >> > > > > > _______________________________________________ > discuss mailing list > discuss@lists.opencpi.org > http://lists.opencpi.org/mailman/listinfo/discuss_lists.opencpi.org > -- David Banks dbanks@geontech.com Geon Technologies, LLC

The conditional/alternative package file seems like a reasonable pre-vhdl-2008 stop-gap. Conditionalizing it based on HdlTarget is also ok but not ideal since there is no real connection between HDL/FPGA "family" and the AXI flavor. But then why does the sdp2axi entity need to be different since it can just use the same package names? Jim On 1/18/19 7:49 PM, David Banks wrote: > Okay, thanks for the information. For now, I was able to move the entity > declaration into a separate file. I then have another file with same > declaration but using the axi_in type with 36-bit addresses. I also have a > second sdp_axi_pkg file with the sdp2axi component declaration that uses > 36-bit addresses for axi_in. > > In the Makefile, I then choose whether to use the 32 or 36 bit versions of > sdp2axi's component and entity based on whether the HdlTarget is > 'zynq_ultra'. This is how I am getting around duplicating the sdp2axi > architecture. This way sdp2axi is always referred to with that name no > matter where it is used, but its axi_in port changes its type (really just > address-width) based on which HdlTarget is being used. Let me know if you > have any better/cleaner ideas. > > Thanks, > David > > On Fri, Jan 18, 2019 at 4:48 PM James Kulp <jek@parera.com> wrote: > >> No code in OpenCPI currently depends on VHDL-2008 since tool support is >> do spotty. >> Its hard to know for sure without trying it on a variety of tools. >> Even googling around suggests that at least some version of Vivado >> crashes on this construct. >> >> I would still avoid it if it was not supported across the current tool >> set (isim/xsim/modelsim/ise/vivado2015+/quartus12+?). >> >> Too bad since it is a great solution... >> >> >> >> >> >> >> On 1/18/19 4:37 PM, David Banks wrote: >>> It looks like VHDL-2008 allows for generic types, which would make this >>> pretty easy by just giving the sdp2axi component a generic to fill in the >>> types for its axi_in/out. >>> >>> If I remember correctly, OpenCPI's framework HDL cannot/should not be >> bound >>> to versions >=VHDL-2008. Is this true? >>> >>> Thanks, >>> David >>> >>> On Mon, Jan 14, 2019 at 9:06 AM David Banks <dbanks@geontech.com> wrote: >>> >>>> Zynq UltraScale+ MPSoC devices require 36 address bits to access the >> full >>>> range of DDR memory. Here is an image of the address map: >>>> [image: image.png] >>>> I discussed this with Jim previously when debugging a PL->PS dataplane >>>> issue. We were discussing the PS AXI slave's address width (OpenCPI's >> axi >>>> primitive's s_axi_hp_in_ar_t and s_axi_hp_in_aw_t ADDR) and its >> connection >>>> to SDP. From a previous conversation I had with Jim (quoted below) it >>>> turns out that SDP is capable of handling 36 address bits. >>>> >>>> "The address map says it all: to reach DDR above 2GB, you need to supply >>>> at least 36 address bits, and the address of that DRAM starts at >>>> 0x8.0000.0000. >>>> It looks like you are being provided an address in that window. >>>> The AXI addresses are indeed byte addresses. >>>> The sdp2axi adapter currently operates at 64 bits wide, and forces the 3 >>>> LSBs of the AXI byte address to zero. >>>> The width of the AXI address is correctly based on the width of the AXI >>>> address field, which should "do the right thing". >>>> So for now you need a copy of the adapter which simply has wider AXI >>>> address fields." - Jim >>>> >>>> It turns out that sdp2axi chooses its address width using the >>>> "axi_out.AW.ADDR'left", so the SDP address width is set to 36 bits if >> the >>>> s_axi_hp_aw/ar_t's address width is set to 36. So, I will need a >> version of >>>> the OpenCPI AXI primitive with s_axi_hp_in_aw/ar_t's ADDR set 36 bits >> wide. >>>> For now I have just overwritten this, but this will break support for >>>> existing OpenCPI platforms. What is the OpenCPI recommended method for >>>> having two parameterized versions of a type in an HDL primitive >> library? Is >>>> this possible? Or will I basically just need to create a second VHDL >>>> type(s) called 's_axi_hp_in_ar_36_t'? >>>> >>>> Thanks! >>>> -- >>>> David Banks >>>> dbanks@geontech.com >>>> Geon Technologies, LLC >>>> >> >> _______________________________________________ >> discuss mailing list >> discuss@lists.opencpi.org >> http://lists.opencpi.org/mailman/listinfo/discuss_lists.opencpi.org >> >

The sdp2axi entity requires a version for axi_in with 32 address bits and with 36 address bits. So, one uses type s_axi_hp_in_t for axi_in and the other uses type s_axi_hp_in_addr36_t. On Sat, Jan 19, 2019 at 7:51 AM James Kulp <jek@parera.com> wrote: > The conditional/alternative package file seems like a reasonable > pre-vhdl-2008 stop-gap. > Conditionalizing it based on HdlTarget is also ok but not ideal since > there is no real connection between HDL/FPGA "family" and the AXI flavor. > > But then why does the sdp2axi entity need to be different since it can > just use the same package names? > > Jim > > > On 1/18/19 7:49 PM, David Banks wrote: > > Okay, thanks for the information. For now, I was able to move the entity > > declaration into a separate file. I then have another file with same > > declaration but using the axi_in type with 36-bit addresses. I also have > a > > second sdp_axi_pkg file with the sdp2axi component declaration that uses > > 36-bit addresses for axi_in. > > > > In the Makefile, I then choose whether to use the 32 or 36 bit versions > of > > sdp2axi's component and entity based on whether the HdlTarget is > > 'zynq_ultra'. This is how I am getting around duplicating the sdp2axi > > architecture. This way sdp2axi is always referred to with that name no > > matter where it is used, but its axi_in port changes its type (really > just > > address-width) based on which HdlTarget is being used. Let me know if you > > have any better/cleaner ideas. > > > > Thanks, > > David > > > > On Fri, Jan 18, 2019 at 4:48 PM James Kulp <jek@parera.com> wrote: > > > >> No code in OpenCPI currently depends on VHDL-2008 since tool support is > >> do spotty. > >> Its hard to know for sure without trying it on a variety of tools. > >> Even googling around suggests that at least some version of Vivado > >> crashes on this construct. > >> > >> I would still avoid it if it was not supported across the current tool > >> set (isim/xsim/modelsim/ise/vivado2015+/quartus12+?). > >> > >> Too bad since it is a great solution... > >> > >> > >> > >> > >> > >> > >> On 1/18/19 4:37 PM, David Banks wrote: > >>> It looks like VHDL-2008 allows for generic types, which would make this > >>> pretty easy by just giving the sdp2axi component a generic to fill in > the > >>> types for its axi_in/out. > >>> > >>> If I remember correctly, OpenCPI's framework HDL cannot/should not be > >> bound > >>> to versions >=VHDL-2008. Is this true? > >>> > >>> Thanks, > >>> David > >>> > >>> On Mon, Jan 14, 2019 at 9:06 AM David Banks <dbanks@geontech.com> > wrote: > >>> > >>>> Zynq UltraScale+ MPSoC devices require 36 address bits to access the > >> full > >>>> range of DDR memory. Here is an image of the address map: > >>>> [image: image.png] > >>>> I discussed this with Jim previously when debugging a PL->PS dataplane > >>>> issue. We were discussing the PS AXI slave's address width (OpenCPI's > >> axi > >>>> primitive's s_axi_hp_in_ar_t and s_axi_hp_in_aw_t ADDR) and its > >> connection > >>>> to SDP. From a previous conversation I had with Jim (quoted below) it > >>>> turns out that SDP is capable of handling 36 address bits. > >>>> > >>>> "The address map says it all: to reach DDR above 2GB, you need to > supply > >>>> at least 36 address bits, and the address of that DRAM starts at > >>>> 0x8.0000.0000. > >>>> It looks like you are being provided an address in that window. > >>>> The AXI addresses are indeed byte addresses. > >>>> The sdp2axi adapter currently operates at 64 bits wide, and forces > the 3 > >>>> LSBs of the AXI byte address to zero. > >>>> The width of the AXI address is correctly based on the width of the > AXI > >>>> address field, which should "do the right thing". > >>>> So for now you need a copy of the adapter which simply has wider AXI > >>>> address fields." - Jim > >>>> > >>>> It turns out that sdp2axi chooses its address width using the > >>>> "axi_out.AW.ADDR'left", so the SDP address width is set to 36 bits if > >> the > >>>> s_axi_hp_aw/ar_t's address width is set to 36. So, I will need a > >> version of > >>>> the OpenCPI AXI primitive with s_axi_hp_in_aw/ar_t's ADDR set 36 bits > >> wide. > >>>> For now I have just overwritten this, but this will break support for > >>>> existing OpenCPI platforms. What is the OpenCPI recommended method for > >>>> having two parameterized versions of a type in an HDL primitive > >> library? Is > >>>> this possible? Or will I basically just need to create a second VHDL > >>>> type(s) called 's_axi_hp_in_ar_36_t'? > >>>> > >>>> Thanks! > >>>> -- > >>>> David Banks > >>>> dbanks@geontech.com > >>>> Geon Technologies, LLC > >>>> > >> > >> _______________________________________________ > >> discuss mailing list > >> discuss@lists.opencpi.org > >> http://lists.opencpi.org/mailman/listinfo/discuss_lists.opencpi.org > >> > > > > > _______________________________________________ > discuss mailing list > discuss@lists.opencpi.org > http://lists.opencpi.org/mailman/listinfo/discuss_lists.opencpi.org > -- David Banks dbanks@geontech.com Geon Technologies, LLC