Hi Walter,
Regarding my proposal of the new GetWave2 API for clock forwarding modeling,
you suggested moving all DQS Rx GetWave's functionalities into DQ Rx GetWave2.
Here is one example that shows why imposing such requirement is not a good idea.
Assume that I am simulating a 64-bit channel with 64 DQ lines and 8 DQS pairs.
DQS Rx has CTLE. Each DQS Rx output signal is used to drive 8 DQ Rx DFEs.
1. When setting up the simulation, if CTLE is implemented in DQS Rx, then user
only need to type in CTLE pole and zero values for 8 DQS models. If CTLE is
implemented in DQ Rx as you suggested, then user needs to type in pole and zero
values for 64 DQ models. The same setup of each DQS CTLE will be repeated 8
times.
2. During the simulation, if CTLE is implemented in DQS Rx, then only 8 CTLEs
need to be run. If CTLE is implemented in DQ Rx as you suggested, then 64 CTLEs
need to be run. The same computation of each DQS CTLE will be repeated 8 times,
as pointed out by Arpad at today's ATM.
Also, as illustrated in my presentation at the ATM, the complexity of handling
DQS Rx GetWave in the simulation flow is minor.
Regards,
Fangyi
