[ibis-macro] Re: bird 156.1
- From: <fangyi_rao@xxxxxxxxxxx>
- To: <ckumar@xxxxxxxxxxx>, <ibis-macro@xxxxxxxxxxxxx>
- Date: Wed, 22 May 2013 11:23:16 -0600
Kumar;
The current ibis 5.1 spec defines the digital stimulus to be NRZ between -1/2
and ½, so we are not including multi-level standard yet. If a model developer
wants to encapsulate everything inside the model, he can always declare
Repeater_Type to be Redriver.
Regards,
Fangyi
From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx]
On Behalf Of Kumar Keshavan
Sent: Wednesday, May 22, 2013 10:12 AM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] bird 156.1
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:
