All, 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. Walter From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of fangyi_rao@xxxxxxxxxxx Sent: Monday, May 20, 2013 5:59 PM To: Arpad_Muranyi@xxxxxxxxxx; ibis-macro@xxxxxxxxxxxxx Subject: [ibis-macro] Re: Comments on BIRD 156.1 Thank Arpad, Walter, Ambrish, Bob, Michael and others in the ATM discussion for all your input. I incorporated them into the attached revision of BIRD 156. Main modifications include - Rephrase description of redriver Tx analog model - Additional figure to illustrate simulation flow and replace Tx/Rx triangle with pentagon (I hope you like the new shape for Tx/Rx J) - Rephrase time domain flow description - Add statistical flow Thanks, Fangyi From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad Sent: Wednesday, May 08, 2013 11:35 AM To: IBIS-ATM Subject: [ibis-macro] Comments on BIRD 156.1 Fangyi, I took some time after the ATM meeting yesterday to re-read BIRD 156.1 with a fresh mind. I would like to make the following comments: #1) From an editorial point of view, you need to organize the BIRD a little differently so we would know what is going to go into the specification and where. Obviously, the ANALYSIS PATH/DATA THAT LED TO SPECIFICATION section will not go into the specification, but it is not clear whether you intended everything that follows that paragraph to be in the specification or not, and where in the spec should things be placed. Should all this be a new chapter of its own, or added to an existing chapter or keyword, and if the latter, which one. Please make specific recommendations for that. This way the editorial committee is not going to know what to do with the content of the BIRD. #2) Please try to follow the formatting of the existing specification and use Courier New 10 font for the example. #3) The following sentence seems to be somewhat problematic: Therefore, the output analog model is expected to describe an analog circuit as oppose to the conventional digital-to-analog converter. First a typographical correction: a d is missing from as opposed to towards the end. Second, the wording conventional digital-to-analog converter is misleading. I understand that you are trying to describe the nature of the [Model] keyword which essentially converts a digital event stimulus to an analog waveform in the simulation environment, but calling these digital-to-analog converters doesnt seem to be appropriate, because their functionality in the purpose of a simulation is not what a D/A or A/D does, it is what an analog buffer does. I understand what your reasons are for using these words, since this topic was discussed in the recent months, but the reader of the spec will not know any of that a few years from now, and I think this will be confusing to them. However, the bigger problem with the above sentence is that you dont explain how this can be achieved. Since the stimulus to [Model] is a digital event (as you stated it) we cant use that keyword for this purpose unless we make provisions for that somehow in this or another BIRD. The same reasoning applies to [External Model] also. The only keyword that could be used currently for buffer modeling with an analog input in this way is the [External Circuit]. It would be nice if this was explained in the BIRD and consequently in the spec and illustrated in the example. The current example you have cleverly side steps this by using .... You might also want to establish some rules for this, for example, that a redriver analog output model may only be modeled with the [External Circuit] keyword. Or did you have something else in mind? #4) I have a problem with the sentence: It is the input impulse to the redriver input algorithmic models AMI_Init function., because the hAC1 impulse response is first passed to what you call SerDes Tx algorithmic model, and it is only passed to the redriver input algorithmic model after that. This sentence seems to suggest that it is passed directly to the redriver input algorithmic model, which doesnt seem to agree with step 2 later in the BIRD. #5) I would insert the words (or something similar) in red bold in the following sentence in step 7 to make it a little more clear to the reader: The simulation platform performs simulation on the upstream channel, which consists of the Tx algorithmic model, the upstream physical channel, and the redrivers input algorithmic model, making use of the AMI_GetWave functions of the algorithmic models if present according to the AMI flow defined in the specification for channels without redriver. #6) Similarly, I would insert the following words in step 8: which consists of the redrivers output algorithmic model, the downstream physical channel, and the Rx algorithmic model, making use of the AMI_GetWave functions of the algorithmic models if present according to the AMI flow defined in the specification for channels without redriver. Thanks, Arpad ===============================================================
Attachment:
Redriver_BIRD_Maxim_Agilent _v2 1_Retimers.docx
Description: application/vnd.openxmlformats-officedocument.wordprocessingml.document
