[libre-riscv-dev] [Bug 21] LPDDR3/LPDDR4 needed

[bugzilla-daemon at libre-riscv.org]

http://bugs.libre-riscv.org/show_bug.cgi?id=21

Jacob Lifshay <programmerjake at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |programmerjake at gmail.com

--- Comment #2 from Jacob Lifshay <programmerjake at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #1)
> found LPDDR3 PHY through edmund (thank you!)
> 
> * LPDDR3 PHY - BSD-licensed: USD $200k

any source code links?

If we do go with the proprietary DDR PHY, for the test chip it might be a good
idea to include even a partial implementation of a libre PHY (maybe with a
separate power domain if we're worried about shorts) and include a pin-mux on
the DDR pins, or just include both of them wired to separate pins, the extra
pins shouldn't be too much of a concern for the test chip since the major cost
is for masks, rather than die packaging.

For the actual DDR PHY, the only special (not standard digital) parts are:

* a VDD/2 power rail (can be provided by an external power supply)
* differential input amplifiers (some of which can be used to compare
single-ended inputs with VDD/2).
* output drivers (basically high-current buffers with a high-impedance mode) --
may need series impedance matching resistors between drivers and pins.
* the memory clock PLLs (we need PLLs anyway for driving the other clock
domains)
* termination resistors with transmission gates to enable/disable them
* a delay-locked-loop (DLL).

The only part that seems complex to design (ignoring the PLL, since we need one
anyway) is the DLL, however we may be able to get away without a DLL if we can
run the PLL at 2x the transfers-per-sec rate (4x or 8x the DDR clock -- icr
which) and dynamically select between clocking on the positive or negative edge
of that 2x clock. the 2x clock would only run to the flip-flops at the DDR
inputs so shouldn't be a major power draw since it doesn't need to go off-chip.

If we turn out to need the DLL, we could try building an all-digital DLL by
having:
* the variable delay element be a chain of buffers with a mux to select which
point to get the signal from that chain. we could also have an xor gate to
easily add another 180deg phase shift.
* the phase detector be a flip-flop with D attached to one input and clk to the
other. we might need an additional synchronizing flip-flop (or two) on the
output.
* the rest of the DLL could be an up/down counter that counts up if the phase
detector signals "too-early" and counts down for "too-late", where the count
selects the number of delay stages that the delay element enables.

we would need to design avoiding glitches, since those would mess-up the DLL
output.

-- 
You are receiving this mail because:
You are on the CC list for the bug.