![]() |
ddrpsv
Vitis Drivers API Documentation
|
The Xilinx DdrPsv driver. This driver supports the Xilinx axi_noc IP core.
MODIFICATION HISTORY:
Ver Who Date Changes
1.0 mus 03/16/19 First Release 1.3 mus 05/08/20 Updated tcl to include detailed #defines for all NOC IPs present in the design. Also, updated logic to create canonical #defines.
In case, if more than 1 NOC IP in design is connected to
same DDR segment through different address range,
generated #defines could be wrong, as existing logic
doesnt generate unique #define, so names would be
repeated and values would be wrong in certain scenarios. Now, new logic is adding 2 major enhancements. First
one is, it is creating detailed #defines for each
connection to the DDR segment, which includes NOC IP
instance name, DDR segment name and master
interface name, it would avoid repeatation in names.
So, xparameters.h would reflect each NOC connection
in HW design.
Second enhancement is, it would create canonicals
for each DDR segment, which would be consumed by
translation table/MPU in BSP. Base address canonical
would point to lowest base address value for that
specific DDR segemnt in HW design, and high address
canonical would point to highest high address for
that DDR segment in given HW design. Limitation which still exist: In case, if
different NOC instances are connected to same DDR
region through different address ranges, we are
assuming that there is no hole in that address
ranges. If HW design contains holes in those
address ranges, canonical #defines would point to
base address and high address with holes.
For example, specific HW design is having 2 NOC
instances NOC1 and NOC2. NoC1 is connected to DDR_LOW_0
with base address 0x0 and high address as 0x3FFF.
NOC2 is connected to DDR_LOW_0 with base address as
0x4000_0000 and high address as 0x4FFF_FFFF. Now, as per
logic, generated base address canonical for DDR_LOW_0
would point to 0x0 and high address canonical
points to 0x4FFF_FFFF. It is incorrect as, there is
hole in address range starting from 0x4000 to
0x3FFF_FFFF.
1.4 mus 08/09/21 Updated generate proc to add checks for psv_pmc and
psv_psm processor. As macros exported by this tcl are
consumed by only ARM based BSP's, we can skip
it for firmware processor BSP. It fixes CR#1105828.