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
>
--
David Banks
dbanks_at_geontech.com
Geon Technologies, LLC
Received on Sat Jan 19 2019 - 00:49:48 CST