[Libre-soc-bugs] [Bug 488] Build test serdes on 180nm test chip for oct2020
bugzilla-daemon at libre-soc.org
bugzilla-daemon at libre-soc.org
Fri Sep 11 15:30:11 BST 2020
--- Comment #7 from Jacob Lifshay <programmerjake at gmail.com> ---
(In reply to Staf Verhaegen from comment #6)
> (In reply to Jacob Lifshay from comment #4)
> > (In reply to Staf Verhaegen from comment #3)
> > > I don't see how you guys could do an analog design for the October tape-out
> > > as you don't have access to the PDK.
> > That's true, however, if it doesn't take much work to do the digital side of
> > the serdes, the only non-standard cells needed would be the capacitor for
> > storing the control voltage, a much smaller capacitor for the charge pump
> > for adjusting the control voltage, and the variable delay circuit. I'd guess
> > that the capacitors aren't very much work, and the delay circuit might take
> > a day or two for you to draw.
> You also have the two switches in phase frequency detector; all these have
> to be properly designed and layouted with proper scaling to get right
> filtering response and speed and with good stability.
> It's not a small job and even it is a small job I don't see how you could do
> it without access to the PDK.
use the smallest 3-state buffer as the charge pump and the smallest
transmission gate set to always on between the control voltage capacitor and
the charge pump and a bigger-than-necessary control voltage capacitor, even
though the response time is really slow it will still lock.
| PF det. |
| <- could insert more transmission gates here
+---- to VCO
Vdd --XO-- Vss
> Main problem is that at the high frequencies the parasitic resistances and
> capacitances of the actual layout and the interconnects become important.
> Again I don't see how you could do a design taking that into account without
> access to the PDK.
do the approximate layout in a way where those are taken into account for the
typical PDK, e.g. layout the VCO's delay loop such that it loops back on itself
half way through, so the end is right next to the beginning and is likely to
not have excessive parasitics.
> I would say such an exercise would be much better fit for Sky130 where they
> (plan to) make the needed information to do the design.
IIRC they already have that information available in the git repos for the
> > > Also the paper is just a simulation
> > > excercise which has not been verified in silicon.
> > True, if it doesn't work it most likely won't affect the test chip much, all
> > you do is tell the cpu not to access that particular peripheral and use a
> > transmission gate to short the control voltage capacitor to ground, causing
> > the experimental VCO to stop.
> > If it does work, it would be great evidence that the 50Gbaud serdes would
> > probably work on 40nm/28nm.
> How would you test if the design would or wouldn't work ?
Test the VCOs by running their output through a long enough divider chain that
it doesn't switch too fast for the cpu to measure the divided result and/or
send the divided output to a pin.
the PLL reference frequency can be adjusted by adjusting whatever clock source
is used or just bring that to an external pin. in the circuitjs example, the
reference frequency is 100MHz IIRC, which should be doable. if not, the PLL can
be adjusted to use a lower reference frequency.
Test the serializer output by having one or more d-ff with the clock taken from
a source where the timing can be adjusted in fine increments, e.g. an external
pin hooked to a high-resolution signal generator. the D inputs are connected to
the serialized data. this allows fast sampling of the serialized data.
have the serializer output connected to the deserializer input with the
deserializer selectable between using its own PLL and using the serializer's
PLL. test if sending input to the serializer gives the same output from the
have muxes between the serdes PLLs and the digital logic, allow switching the
clock source to a johnson counter for testing operation at low speeds.
> For such design
> often the design of the test circuit is as involved if not more involved
> than designing the circuit itself.
> You can't simply bring high frequency signals out as output as that will
> always have too much capacitive load on the output signal.
true, hence the above workarounds.
You are receiving this mail because:
You are on the CC list for the bug.
More information about the libre-soc-bugs