Non-zero rise/fall time

[dghan0219]

PyBERT launches a signal with zero rise/fall times. The only way to fix this is to adjust Tx_Cout when using the internal transmission line model. How about an option to input the rise/fall time and then give it Gaussian shaping per Howard Johnson's second book?

[capn-freako]

@dghan0219 a few thoughts by way of reply that I'm hoping you'll respond to, in order to help move this forward:

1. I think you meant to say, "infinite slew rate, zero rise/fall times."
   Is that correct?

2. You say, "...only way to fix this...," which implies you think starting with a perfect signal is a problem.
   Can you explain why you believe it to be a problem?

3. Actually, most of the channel parameters will affect the final pulse shape, not just Tx_Cout.

4. When you say, "option to input rise/fall time...," do you mean an attempt to model the slew rate of the Tx output driver stage?
   If so, consider:

   Slew rate is a very non-linear phenomenon.
   And throughout the channel modeling process in PyBERT we are assuming that we can apply linear systems theory.
   That is, we assume that we can use convolution to compose the effects of the various channel components.
   If we were to toss out the linear assumption (by, for instance, allowing something like slew rate modeling to be a part of the channel) then we'd need to completely change the way we compose the various channel components, in order to form the final channel impulse response.
   And I'm not sure:

   1. this is even possible, or that
   2. I want to undertake this sort of Herculean effort, given the questionable ROI.

5. Regarding your suggestion to, "...give it Gaussian shaping...," I'm hesitant to start adding any sort of shaping to the pulse not induced by the channel itself, as that seems like a departure from the physical reality of what we're trying to model.

Your thoughts?

Thanks,
-db

[dghan0219]

See my comments below...

@dghan0219 a few thoughts by way of reply that I'm hoping you'll respond to, in order to help move this forward:

1. I think you meant to say, "infinite _slew rate_, zero rise/fall times."
   Is that correct?

Yes, you stated correctly what I should have written. I have corrected the issue name.

2. You say, "...only way to _fix_ this...," which implies you think starting with a perfect signal is a problem.
   Can you explain _why_ you believe it to be a problem?

The eyes aren't as realistic looking as they could be. With a simulator that I co-wrote with Mathcad, which is not nearly as good as PyBERT, I get the waveform PyBERT shows only with a rise/fall time near zero. With something more realistic, such as 24 to 36 ps (20-80%) with Gaussian shaping, I get the more classic eye that is measured with an oscilloscope or what HyperLynx shows. I thought using an IBIS-AMI model would adjust the rise/fall times, but it still looks the same as not using a model.

3. Actually, _most_ of the channel parameters will affect the final pulse shape, not just _Tx_Cout_.

I'm looking at just the signal launched by setting the line length to zero and all other parameters to ideal. I then adjust Tx_Cout until I get the rise/fall time I want and then run a full simulation with that. However, the internal model for a transmission line is based on a cable and is not the same as a PCB trace; so when I switch to providing my own model, I don't have Tx_Cout to adjust anymore.

4. When you say, "option to input rise/fall time...," do you mean an attempt to model the _slew rate_ of the Tx output driver stage?

Yes, what is specified in a device's data sheet.

   If so, consider:
   Slew rate is a very non-linear phenomenon.

Slew rate is defined by Laplace equations that use 10-90% rise/fall time (Johnson's first book has to/from 20-80, 10-90, and 0-100% conversion equations) and frequency.

   And throughout the channel modeling process in PyBERT we are assuming that we can apply linear systems theory.

The Gaussian, linear, and quadratic shaping are defined by Laplace equations. I think this is just another block, similar to S-parameters or an impulse response file, is part of the PRBS generator, and is not something that would influence your other graphs, such as frequency, impulse, pulse, and step responses. Shaping also helps to remove Gibbs phenomena except for linear.

   That is, we assume that we can use _convolution_ to compose the effects of the various channel components.
   If we were to toss out the linear assumption (by, for instance, allowing something like slew rate modeling to be a part of the channel) then we'd need to completely change the way we compose the various channel components, in order to form the final channel impulse response.
   And I'm not sure:
   
   1. this is even possible, or that
   2. I want to undertake this sort of Herculean effort, given the questionable ROI.

5. Regarding your suggestion to, "...give it Gaussian shaping...," I'm hesitant to start adding any sort of shaping to the pulse not induced by the channel itself, as that seems like a departure from the physical reality of what we're trying to model.

The shaping is what makes the slew rate realistic. As Johnson stated, the device's output stage and package will already make a signal Gaussian in appearance. He also shows equations for linear and quadratic shapes, but states that Gaussian is the most realistic because the other shapes will become Gaussian by the time the signal is launched from the device pads. To model the channel only, a zero rise/fall time can still be used. By including the option of using IBIS-AMI models, I think you are trying to model more than just the channel, especially since you include DFE, CTLE, emphasis, etc.

Your thoughts?

Thanks,
-db

[capn-freako]

Note the following when addressing this issue:

1. IBIS defines the [Ramp] keyword as the "20% - 80%" value.

2. IBIS states that the [Ramp] and [{Rising,Falling} Waveform] keywords should include the effect of [Ccomp].

   • How to avoid double-counting the effect of [Ccomp] if I'm:

     1. using it in an analytic channel model, and
     2. convolving with some "shaping" function taking its cue from the [Ramp], or [{Rising,Falling} Waveform] keyword?

3. The pyibisami.ibis.model.Model class has a slew property (V/ns).