[ibis-macro] bird 156.1
- From: Kumar Keshavan <ckumar@xxxxxxxxxxx>
- To: "ibis-macro@xxxxxxxxxxxxx" <ibis-macro@xxxxxxxxxxxxx>
- Date: Wed, 22 May 2013 10:12:25 -0700
Hello:
----------
The Retimer and Redriver flows are very similar. I had an AR to attempt to
integrate Retimers with the Redriver BIRD (and also integrate BIRD 131 if
possible).
I modified v2 1 (enclosed) to include both retimer flows and BIRD 131.
The fundamental difference between Retimers and Redrivers is that a Redriver Rx
does not have a CDR or sampling latch. The waveform generated by the Redriver
Rx is passed directly to the Redriver Tx. The waveform output of a Retimer must
first be sampled ½ UI after each clock tick, and the simulation platform shall
generate a digital stimulus with values of -1/2 and +1/2
I have concerns with the above retimer definition. Basically we are
selectively pulling out some functionality of the retimer - viz symbol
detection/modulation from the model domain and saying it is now the job of the
simulator. This is unwise. The model is now no longer a black box. Symbol
detection/modulation should still be a functionality of the retimer as in a
real device. For example the retimer may do multi level modulation and that
will depend upon specific levels which the simulator does not have a knowledge
of.
Basically I am of the view the retimer rx+tx is strictly a model business and
the simulator should just pass the waveform just like it does in the redriver
case.
Other related posts:
