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
>>
>
Received on Sat Jan 19 2019 - 12:50:32 CST