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_at_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_at_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_at_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_at_geontech.com
> >>>> Geon Technologies, LLC
> >>>>
> >>
> >> _______________________________________________
> >> discuss mailing list
> >> discuss_at_lists.opencpi.org
> >> http://lists.opencpi.org/mailman/listinfo/discuss_lists.opencpi.org
> >>
> >
>
>
> _______________________________________________
> discuss mailing list
> discuss_at_lists.opencpi.org
> http://lists.opencpi.org/mailman/listinfo/discuss_lists.opencpi.org
>
--
David Banks
dbanks_at_geontech.com
Geon Technologies, LLC
Received on Tue Jan 22 2019 - 14:51:28 CST