06-13-2019 04:11 AM
I need to implement an LPDDR3 memory interface in Zynq Ultrascale+ Programmable Logic (PL) which is x64 bits wide (using two x32 Micron devices), however, the Xilinx LPDDR3 IP is limited to a single memory device of width x32.
Is it safe to instantiate two independent LPDDR3 controllers and combine the user interfaces to make a double width data port to the application?
The two controllers will use the same sys_clk, (each generating UI_CLK for its user interface). Commands and data can be passed from the application to each LPDDR3 controller with a FIFO, to cross the clock domains, and buffer commands for each memory channel. Data flow can be controlled with the *_RDY signals.
I’m concerned that the two controllers will start at different times (if calibration time is variable) and so will execute refresh cycles at different times. If one channel has to wait while the controller is doing ‘housekeeping’, what is the worst case buffering that’s required?
The LPDDR3 controller uses command re-ordering. Could this cause the controllers to get out of sync? Can it be switched it off?
I’m trying to understand if this is a safe and reliable solution.
Any thoughts welcome!
06-13-2019 10:10 AM
Hello @sg24 ,
Trying to get this working is a non-trivial task. I've seen a few cases where users would make custom logic which presents itself as a single app_interface at the top level of the IP but splits it in half and drives two separate MIG instances. Yes, your controllers will exit calibration at separate times which means things like refreshes and periodic reads will be operating out of sync between the two controllers so you'll have to take this in to account when designing your shim. If this were a DDR3/DDR4 design then it would be easier to deal with this since these IPs allow the user to insert their own Refresh and ZQ_cal commands but LPDDR3 doesn't have that option. You may be able to modify the core to do this but it's not supported by Xilinx. As for reordering it won't matter since both LPDDR3 controllers will get the same physical DRAM address with every command but the data payload will be different so any reordering that occurs will be identical in both cores. The hardest part here will be managing the Write and Read command traffic at the top level while building in enough buffer in the shim to handle cases when app_rdy/app_wdf_rdy deassert independently for each core (refresh, ZQ, periodic read). If bandwidth isn't a concern then you could design the shim with this in mind and be aware it's possible you'll take twice as much protocol down time but it will simplify things. Meaning don't drive traffic if any one controller's _rdy signals are Low, but depending on when the controllers start operating you'll be exposed to both tRFC intervals which is a lot of lost efficiency. The safety and reliability of this approach is up to the quality of your solution and is beyond the scope of what Xilinx can support.