[ibis-macro] Re: IBIS-ATM teleconference agenda for 12/5/2006
- From: "Lance Wang" <lwang@xxxxxxxxxxx>
- To: <ibis-macro@xxxxxxxxxxxxx>
- Date: Tue, 5 Dec 2006 09:22:26 -0500
Attached please find the DLL API BIRD Draft for this afternoon's
discussion.
Thanks,
Lance Wang
Cadence Design Systems, Inc.
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Monday, December 04, 2006 4:36 PM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] IBIS-ATM teleconference agenda for 12/5/2006
Audio
=====
Voice dial-in: 877-384-0543
Passcode: 904-37-837
Web
===
Click Here to Join Live Meeting
https://www.livemeeting.com/cc/sisoft/join?id=NKQQN3&role=attend&pw=TP8j
%23-%25%7E5
FIRST TIME USERS: To save time before the meeting, check your
system to make sure it is compatible with Microsoft Office Live
Meeting.
---------------------------------------------------------------------
Agenda
======
1) Opens:
2) Review of ARs:
- Mirmak: Who has permission to access VHDL spec P1076C?
Has anyone tried?
Lance needs access info. Must be an IEEE member.
May be available under IEEE Explorer
Requires a paid account.
- Mike: update macro library documentation
Will do it this week
- Ian: get specifics on pole/zero approach
- Nothing yet
- Will current API proposal work with the pole-zero approach?
- Cadence will start a BIRD
- In internal review.
- Will be sent next week.
- Hemant: share details with Ian before proposing BIRD, and
modify the BIRD so that API could accommodate both types of data.
- Todd: dig up material on public domain HSPICE syntax
- No report.
- Mirmak: send spreadsheet on convolution operators
- Arpad: Write parameter passing syntax proposal for a possible BIRD
3) API discussion. I hope that we would either have a draft BIRD to
discuss, or have a little more meaningful discussion on how the
proposed API would need to be modified to make it work for any
methodology (frequency domain / time domain, etc...). I do not
have a draft for the parameter syntax discussion.
Thanks,
Arpad
=====================================================================
---------------------------------------------------------------------
IBIS Macro website : http://www.eda.org/pub/ibis/macromodel_wip/
IBIS Macro reflector: http://www.freelists.org/list/ibis-macro
To unsubscribe send an email:
To: ibis-macro-request@xxxxxxxxxxxxx
Subject: unsubscribe
---------------------------------------------------------------------
IBIS Macro website : http://www.eda.org/pub/ibis/macromodel_wip/
IBIS Macro reflector: http://www.freelists.org/list/ibis-macro
To unsubscribe send an email:
To: ibis-macro-request@xxxxxxxxxxxxx
Subject: unsubscribe
******************************************************************************
******************************************************************************
BIRD ID#: xx.x
ISSUE TITLE: Algorithmic Modeling API (AMI) support in IBIS
REQUESTER: Hemant Shah, C. Kumar, Cadence Design Systems, Inc.
Joe Abler, IBM
DATE SUBMITTED: 12/5/2006
DATE REVISED:
DATE ACCEPTED BY IBIS OPEN FORUM:
******************************************************************************
******************************************************************************
STATEMENT OF THE ISSUE:
1. The Interoperability Problem
Advanced SERDES parts often contain proprietary algorithms for capabilities
such as Feed Forward Equalization, Decision Feedback Equalization, Clock and
Data Recovery modules,
proprietary noise cancellation techniques, etc. These complex algorithms are
very difficult to capture
with traditional device/circuit level modeling techniques. In addition, the
serial links containing
these devices often need to simulated with extremely long bit streams (10
million to
trillions of bits to accurately predict Bit Error Rates) making high simulation
performance an important consideration.
These circumstances have forced advanced SERDES suppliers to develop,
distribute,
and maintain proprietary software for the modeling and simulation of such
devices. While this can address the initial device modeling issues, proprietary
approaches from the various SERDES suppliers result in a lack of
interoperability between models,
leaving the systems designers unable to simulate their critical serial links.
This approach also adds
a support burden for SERDES IP vendors. Clearly, a new device modeling approach
is needed to allow
SERDES IP vendors to create algorithmic models that plug into commercially
available
PCB system interconnect simulators, while at the same time protecting the
critical IP contained
within the SERDES algorithms.
2. Key Requirements for Solution
Based on a discussion with several SERDES IP vendors, a number of key
requirements have been
identified for the approach that allows IP vendors to
create Algorithmic Models and the Interface between models and simulation
platform:
- Ability to capture complex DSP-like algorithms
-DSP / Filter optimization: CDR, DFE, FFE
- Minimal model development time
- High accuracy (hardware correlated) with minimum simulation time
- Protection of SERDES IP
- Architectural modeling
-Ability to model & evaluate IP before silicon is developed
(pre-silicon)
- Integration with PCB design environment
- Interoperability of models from different IP /IC Vendors
- Supported by EDA vendors
- Available as a public standard
******************************************************************************
STATEMENT OF THE RESOLVED SPECIFICATIONS:
Allow IP vendors to create algorithmic models as a dynamically linked library
(dll) using a standard
Application Procedural Interface (API).
An ANSI C-based interface (AMI) for these algorithmic models needs to be
introduced in IBIS [Model] section.
Changes in Section 3a - K E Y W O R D H I E R A R C H Y
Current Spec:
*****************************
***** Original Text *****
*****************************
|=============================================================================
|
| Section 3a
|
| K E Y W O R D H I E R A R C H Y
|
|=============================================================================
|=============================================================================
|
| .ibs FILE
| ---------
| |-- File Header Section
| | ---------------------
| | |-- [IBIS Ver]
| | |-- [Comment Char]
| | |-- [File Name]
| | |-- [File Rev]
| | |-- [Date]
| | |-- [Source]
| | |-- [Notes]
| | |-- [Disclaimer]
| | |-- [Copyright]
| |
| |-- [Component] Si_location, Timing_location
| | -----------
| | |-- [Manufacturer]
| | |-- [Package] R_pkg, L_pkg, C_pkg
| | |-- [Pin] signal_name, model_name, R_pin,
| | | L_pin, C_pin
| | |-- [Package Model]
| | | ---------------
| | | |-- [Alternate Package Models]
| | | --------------------------
| | | |-- [End Alternate Package Models]
| | |
| | |-- [Pin Mapping] pulldown_ref, pullup_ref,
| | | gnd_clamp_ref, power_clamp_ref,
| | | ext_ref
| | |-- [Diff Pin] inv_pin, vdiff, tdelay_typ,
| | | tdelay_min, tdelay_max
| | |-- [Series Pin Mapping] pin_2, model_name,
| | | function_table_group
| | |-- [Series Switch Groups] On, Off
| | |
| | |-- [Node Declarations]
| | | -------------------
| | | |-- [End Node Declarations]
| | |
| | |-- [Circuit Call] Signal_pin, Diff_signal_pins,
| | -------------- Series_pins, Port_map
| | |-- [End Circuit Call]
| |
| |-- [Model Selector]
| |
| |-- [Model] Model_type, Polarity, Enable,
| | ------- Vinl, Vinh, C_comp, C_comp_pullup,
| | | C_comp_pulldown,
| | | C_comp_power_clamp,
| | | C_comp_gnd_clamp
| | | Vmeas, Cref, Rref, Vref
| | | Rref_diff, Cref_diff
| | |
| | |-- [Model Spec] Vinh, Vinl, Vinh+, Vinh-, Vinl+,
| | | Vinl-, S_overshoot_high,
| | | S_overshoot_low, D_overshoot_high,
| | | D_overshoot_low, D_overshoot_time,
| | | Pulse_high, Pulse_low, Pulse_time,
| | | Vmeas, Cref, Rref, Cref_rising,
| | | Cref_falling, Rref_rising,
| | | Rref_falling, Vref_rising,
| | | Vref_falling, Vmeas_rising,
| | | Vmeas_falling,
| | | Rref_diff, Cref_diff
| | |-- [Receiver Thresholds] Vth, Vth_min, Vth_max, Vinh_ac,
| | | Vinh_dc, Vinl_ac, Vinl_dc,
| | | Threshold_sensitivity,
| | | Reference_supply, Vcross_low,
| | | Vcross_high, Vdiff_ac, Vdiff_dc,
| | | Tslew_ac, Tdiffslew_ac
| | |-- [Add Submodel]
| | |-- [Driver Schedule]
| | |-- [Temperature Range]
| | |-- [Voltage Range]
| | |-- [Pullup Reference]
| | |-- [Pulldown Reference]
| | |-- [POWER Clamp Reference]
| | |-- [GND Clamp Reference]
| | |-- [External Reference]
| | |-- [TTgnd]
| | |-- [TTpower]
| | |-- [Pulldown]
| | |-- [Pullup]
| | |-- [GND Clamp]
| | |-- [POWER Clamp]
| | |-- [Rgnd]
| | |-- [Rpower]
| | |-- [Rac]
| | |-- [Cac]
| | |-- [On]
| | |-- [Off]
| | |-- [R Series]
| | |-- [L Series]
| | |-- [Rl Series]
| | |-- [C Series]
| | |-- [Lc Series]
| | |-- [Rc Series]
| | |-- [Series Current]
| | |-- [Series MOSFET] Vds
| | |-- [Ramp] dV/dt_r, dV/dt_f,
| | | R_load
| | |-- [Rising Waveform] R_fixture, V_fixture,
| | | V_fixture_min, V_fixture_max,
| | | C_fixture, L_fixture, R_dut,
| | | L_dut, C_dut
| | |-- [Falling Waveform] R_fixture, V_fixture,
| | | V_fixture_min, V_fixture_max,
| | | C_fixture, L_fixture, R_dut,
| | | L_dut, C_dut
| | |-- [Test Data] Test_data_type, Driver_model,
| | | ----------- Driver_model_inv, Test_load
| | | |--[Rising Waveform Near]
| | | |--[Falling Waveform Near]
| | | |--[Rising Waveform Far]
| | | |--[Falling Waveform Far]
| | | |--[Diff Rising Waveform Near]
| | | |--[Diff Falling Waveform Near]
| | | |--[Diff Rising Waveform Far]
| | | |--[Diff Falling Waveform Far]
| | | |--[Test Load] Test_load_type, C1_near, Rs_near,
| | | Ls_near, C2_near, Rp1_near,
| | | Rp2_near, Td, Zo, Rp1_far,
| | | Rp2_far, C2_far, Ls_far, Rs_far,
| | | C1_far, V_term1, V_term2,
| | | Receiver_model,
| | | Receiver_model_inv, R_diff_near,
| | | R_diff_far
| | |
| | |-- [External Model] Language, Corner, Parameters,
| | ---------------- Ports, D_to_A, A_to_D
| | |-- [End External Model]
************************************
***** End of Original Text *****
************************************
Revised Spec (Changes are noted with |*)
************************
***** New Text *****
************************
|=============================================================================
|
| Section 3a
|
| K E Y W O R D H I E R A R C H Y
|
|=============================================================================
|=============================================================================
|
| .ibs FILE
| ---------
| |-- File Header Section
| | ---------------------
| | |-- [IBIS Ver]
| | |-- [Comment Char]
| | |-- [File Name]
| | |-- [File Rev]
| | |-- [Date]
| | |-- [Source]
| | |-- [Notes]
| | |-- [Disclaimer]
| | |-- [Copyright]
| |
| |-- [Component] Si_location, Timing_location
| | -----------
| | |-- [Manufacturer]
| | |-- [Package] R_pkg, L_pkg, C_pkg
| | |-- [Pin] signal_name, model_name, R_pin,
| | | L_pin, C_pin
| | |-- [Package Model]
| | | ---------------
| | | |-- [Alternate Package Models]
| | | --------------------------
| | | |-- [End Alternate Package Models]
| | |
| | |-- [Pin Mapping] pulldown_ref, pullup_ref,
| | | gnd_clamp_ref, power_clamp_ref,
| | | ext_ref
| | |-- [Diff Pin] inv_pin, vdiff, tdelay_typ,
| | | tdelay_min, tdelay_max
| | |-- [Series Pin Mapping] pin_2, model_name,
| | | function_table_group
| | |-- [Series Switch Groups] On, Off
| | |
| | |-- [Node Declarations]
| | | -------------------
| | | |-- [End Node Declarations]
| | |
| | |-- [Circuit Call] Signal_pin, Diff_signal_pins,
| | -------------- Series_pins, Port_map
| | |-- [End Circuit Call]
| |
| |-- [Model Selector]
| |
| |-- [Model] Model_type, Polarity, Enable,
| | ------- Vinl, Vinh, C_comp, C_comp_pullup,
| | | C_comp_pulldown,
| | | C_comp_power_clamp,
| | | C_comp_gnd_clamp
| | | Vmeas, Cref, Rref, Vref
| | | Rref_diff, Cref_diff
| | |
| | |-- [Model Spec] Vinh, Vinl, Vinh+, Vinh-, Vinl+,
| | | Vinl-, S_overshoot_high,
| | | S_overshoot_low, D_overshoot_high,
| | | D_overshoot_low, D_overshoot_time,
| | | Pulse_high, Pulse_low, Pulse_time,
| | | Vmeas, Cref, Rref, Cref_rising,
| | | Cref_falling, Rref_rising,
| | | Rref_falling, Vref_rising,
| | | Vref_falling, Vmeas_rising,
| | | Vmeas_falling,
| | | Rref_diff, Cref_diff
| | |-- [Receiver Thresholds] Vth, Vth_min, Vth_max, Vinh_ac,
| | | Vinh_dc, Vinl_ac, Vinl_dc,
| | | Threshold_sensitivity,
| | | Reference_supply, Vcross_low,
| | | Vcross_high, Vdiff_ac, Vdiff_dc,
| | | Tslew_ac, Tdiffslew_ac
| | |-- [Add Submodel]
| | |-- [Driver Schedule]
| | |-- [Temperature Range]
| | |-- [Voltage Range]
| | |-- [Pullup Reference]
| | |-- [Pulldown Reference]
| | |-- [POWER Clamp Reference]
| | |-- [GND Clamp Reference]
| | |-- [External Reference]
| | |-- [TTgnd]
| | |-- [TTpower]
| | |-- [Pulldown]
| | |-- [Pullup]
| | |-- [GND Clamp]
| | |-- [POWER Clamp]
| | |-- [Rgnd]
| | |-- [Rpower]
| | |-- [Rac]
| | |-- [Cac]
| | |-- [On]
| | |-- [Off]
| | |-- [R Series]
| | |-- [L Series]
| | |-- [Rl Series]
| | |-- [C Series]
| | |-- [Lc Series]
| | |-- [Rc Series]
| | |-- [Series Current]
| | |-- [Series MOSFET] Vds
| | |-- [Ramp] dV/dt_r, dV/dt_f,
| | | R_load
| | |-- [Rising Waveform] R_fixture, V_fixture,
| | | V_fixture_min, V_fixture_max,
| | | C_fixture, L_fixture, R_dut,
| | | L_dut, C_dut
| | |-- [Falling Waveform] R_fixture, V_fixture,
| | | V_fixture_min, V_fixture_max,
| | | C_fixture, L_fixture, R_dut,
| | | L_dut, C_dut
| | |-- [Test Data] Test_data_type, Driver_model,
| | | ----------- Driver_model_inv, Test_load
| | | |--[Rising Waveform Near]
| | | |--[Falling Waveform Near]
| | | |--[Rising Waveform Far]
| | | |--[Falling Waveform Far]
| | | |--[Diff Rising Waveform Near]
| | | |--[Diff Falling Waveform Near]
| | | |--[Diff Rising Waveform Far]
| | | |--[Diff Falling Waveform Far]
| | | |--[Test Load] Test_load_type, C1_near, Rs_near,
| | | Ls_near, C2_near, Rp1_near,
| | | Rp2_near, Td, Zo, Rp1_far,
| | | Rp2_far, C2_far, Ls_far, Rs_far,
| | | C1_far, V_term1, V_term2,
| | | Receiver_model,
| | | Receiver_model_inv, R_diff_near,
| | | R_diff_far
| | |
| | |-- [External Model] Language, Corner, Parameters,
| | ---------------- Ports, D_to_A, A_to_D
| | |-- [End External Model]
|* | |-- [AMI] AMI_Init(), AMI_GetWave(),
|* | ----- AMI_Close(), Parameters
|* | |-- [End AMI]
*******************************
***** End of New Text *****
*******************************
Add new keywords [AMI], [End AMI] in Section 6 - M O D E L S T A T E M E N T
************************
***** New Text *****
************************
|=============================================================================
| Keyword: [AMI], [End AMI]
| Required: No
| Sub-Params: AMI_Init(), AMI_GetWave(), AMI_Close(), Parameters
| Description: The [AMI], [END AMI] keyword defines a C-based interface to
| link with excutable dynamic link library that contains
| algorithmic model information. It contains three function
| definitions and parameters that can be passed into.
|
| The following subparameters are defined:
| AMI_Init()
| ? Initialize and optimize channel with
Tx / Rx Model
| ? This is where the IC DSP decides how
to drive the system:
| e.g., filter coefficients, channel
compensation, etc.
| ? Input: Channel Characterization,
system and dll specific
| parameters from config file
| ? bit period, sampling intervals, # of
forward/backward
| coefficients, etc.
| ? Output: Modified Channel
Characterization, status
| Parameters Vaules will be passed into functions
| AMI_GetWave()
| ? Modify continuous time domain
waveform [CDR, Post Processing]
| ? Input: Voltage at Rx input at
specific times
| ? Output: Modified Voltage, Clock tics
(dll specific), status
| AMI_Close()
| ? Clean up, exit
|
| Usage Rules: The [AMI], [End AMI] keyword must be positioned within a
| [Model] section and it may appear many times with unique names
| for each [Model] keyword in a .ibs file. It is
not permitted
| under the [Submodel] keyword.
|
| The [AMI], [End AMI] keyword is an additional function for
[Model].
| It should be with a complete IBIS [Model]'s
data or the [Model]
| with an [External Model].
|
| Algorithmic model requires existing IBIS
structure to represent the
| Tx and Rx load models. These Tx, Rx models
along with the channel
| constitute a Linear Time Invariant (LTI) system
|
| If there are more than one [AMI],[End AMI] in [Model], the API
| calls will follow the syntax sequences (the
first in, the first out)
| in the simulations.
|
| AMI_Init() must be listed in [AMI],[End AMI].
AMI_GetWave() and
| AMI_Close() are optional upon usages.
|
| Paramters definitions can be used in AMI_init()
call only. They
| must follow the AMI_init() function call.
|
| Parameters is optional sub-parameters in
[AMI],[End AMI].
|
| This API is ANSI C compatible.
|
|-----------------------------------------------------------------------------
| Example [AMI] with [External Model]:
|--------------------------------------
|
[Model] ExBufferSPICE
Model_type I/O
Vinh = 2.0
Vinl = 0.8
|
| Other model subparameters are optional
|
| typ min max
[Voltage Range] 3.3 3.0 3.6
|
[Ramp]
dV/dt_r 1.57/0.36n 1.44/0.57n 1.73/0.28n
dV/dt_f 1.57/0.35n 1.46/0.44n 1.68/0.28n
|
[External Model]
Language SPICE
|
| Corner corner_name file_name circuit_name (.subckt name)
Corner Typ buffer_typ.spi buffer_io_typ
Corner Min buffer_min.spi buffer_io_min
Corner Max buffer_max.spi buffer_io_max
|
| Parameters - Not supported in SPICE
|
| Ports List of port names (in same order as in SPICE)
Ports A_signal my_drive my_enable my_receive my_ref
Ports A_puref A_pdref A_pcref A_gcref A_extref
|
| D_to_A d_port port1 port2 vlow vhigh trise tfall corner_name
D_to_A D_drive my_drive my_ref 0.0 3.3 0.5n 0.3n Typ
D_to_A D_enable my_enable A_gcref 0.0 3.3 0.5n 0.3n Typ
|
| A_to_D d_port port1 port2 vlow vhigh corner_name
A_to_D D_receive my_receive my_ref 0.8 2.0 Typ
|
| Note: A_signal might also be used instead of a user-defined interface port
| for measurements taken at the die pads
|
[End External Model]
|
| Decision Feedback Equalization Algorithmic Model
[AMI] DFE
|
| Initialize function
AMI_Init()
| Paramters for AMI_Init()
Parameters forward=3
Parameters backward=5
|
| GetWave Function
AMI_GetWave()
|
| Clear and Close function
AMI_Close()
|
[End AMI]
|
| Clock Data Recovery Algorithmic Model
[AMI] CDR
|
| Initialize function
AMI_Init()
| Parameters for AMI_Init()
| forward coefficients
Parameters forward=3
| backward taps
Parameters backward=4
| verbose, silent setting from 0-3
Parameters message=3
|
| GetWave Function
AMI_GetWave()
|
AMI_Close()
|
[End AMI]
|
******************************************************************************
ANALYSIS PATH/DATA THAT LED TO SPECIFICATION:
Today's serial link communication systems are going up to 5-10+ Gbps. Due to
significant interconnect channel losses, eye openings are common not existing
any more for system analysis. DSP algorithms are used for these advanced
High-Speed system designs.
A standardized ANSI C-based API is proposed for linking with Algorithmic Models
since they often are ANSI C compatible complied dynamic linked libraries (dll).
Several discussions were conducted(6/22/06,7/11/06) with the IBIS
Advacned Technology Modeling Committee (Former Macro-Committee) Meetings and
IBIS DAC Summit(7/25/06).
API Definition:
There are 3 standard API's defined for AMI, listed below:
-AMI_Init
-AMI_getwave
-AMI_close
The first, "AMI_Init", is mandatory. The other 2 are optional, and enable
additional functionality to be supplied in the DLL.
All functions should return one of two status codes (1 for success, 0 for
failure). In an additon, AMI_init() and AMI_GetWave() can optinally send back
detailed messages thru the simple message structure defined as
genchdllmsg_type **msg in the function calls.
AMI_Init
The "AMI_Init" API is mandatory for all AMI DLLs, and is described below.
This call allows the dll to receive set up information from the "ami" statement
such as register settings. The user defined settings will come to the dll
through this call including the location of the dll on users disk.
In this init call, algorithmic model developers are encouraged to allocate any
storage that can needs to be used by other functions (GetWave, Close) in the
dll - such as clock tics, filter coefficients etc.
extern long AMI_Init
(double *a, long row_size, long col_size, double bitp, double tr,
double tf,
void **pdll_server_param_obj, char *dllcontrols, void
*dll_client_param,
genchdllmsg_type **msg)
Call:
long status = AMI_Init(?),
Arguments:
a = matrix of row_size x col_size
This matrix contains impulse response of primary as well as crosstalk channels.
First column is time in seconds. Second column is primary channel (voltages);
third through n are crosstalk channels (voltages).
col_size = (primary channel + number of crosstalk channels + 1)
This value is set by the simulation platform and useful for the dll object for
indexing/accessing data accordingly
bitp = nominal bit period (pulse width) of the characterization in seconds?
Tr, tf = nominal rise and nominal fall times in seconds, useful for
synthesizing
filters (The bitp, tr and tf are the nominal bit width and rise and fall times
in
seconds of the input signal. The dll may use this information to optimize the
filter coefficients)
pdll_server_param_obj - place holder for data structure created by the dll.
Dll's
can use this to store and retrieve additional information. The pointer to
pointer
to allocated storage is stored into pdll_server_param_obj
(hence void **pdll_server_param_obj). This allocated storage should be freed by
the dll when AMI_close is called.
Dllcontrols - the dllcontrols contain the optional parameters specific to the
dll.
The first item is the path where the dll's and associated files are stored.
This is string in a tree data base format and will contain information like dll
version number. It can be also used by the dlls to manage additional features
and
controls; dllcontrols also includes the path to the dll, this allows
algorithmic
model developer to retrieve additional data from any support files that are
distributed with the model. Support files are not required and are expected to
be
read only on the end users system.
Dll_client_param - reserved for future usage
genchdllmsg_type - this is message type. How to create, use this message type
is
described in chdllmsg.h. chdllmsg.c has examples of how to create / pass
messages.
AMI_getwave
The "AMI_getwave" API is optional, and is used when the DLL is intended to
fully
post-process the input waveform and return a modified one. This API is
described
below.
Simulator passes characterized channel. This characterized channel may be
modified by the Tx dll. This call is made many times by the simulation platform
based on how long the user requested the simulation be run. Model developers
should assume that each call may have a different length for the data.
Simulation
platform will pass a block of (waveform) data (voltage, time) to the dll; dll
will
update the data and send it back to the simulation platform.
extern long AMI_getwave
(double *wave_in, long size, double dt, double *cdrclkbuff,
void *dll_server_param_obj, void *dll_client_param,
genchdllmsg_type **msg)
- Input: Voltage at Rx input at specific times
- Output: Modified Voltage, Clock tics, status
where:
long status = AMI_getwave (..)
The arguments in this API are listed below.
wave_in - waveform as seen at the receiver; a vector of voltages (V)
size - size of the vector
dt - sampling interval in seconds
Each element in wave_in is a voltage sampled at time 'dt' from the last one. It
could be any number of samples. The dll will process this waveform and apply
any
modifications(e.g. dfe). The vector is just a waveform of arbitrary length at
fixed sampling period "dt". , Dll can update this waveform and return it in the
variable wave_in.
cdrclkbuff - This buffer is provided for cdr function. The storage is allocated
by
the simulation platform and is of the same size as the wave_in vector. The
simulation platform will put a "-1" value in 0th location. If the dll includes
a
cdr function, it needs to modify this 0th position to something other than a
"-1".
If the cdr function is implemented, it should return expected clock edge times
in
the buffer. This information (clock edges/ clock tics) are used by the
simulation
platform to accurately plot the eye and compute jitter distribution.
The times in the vector should be referenced to the start of the cdrclkbuff.
For example cdrclkbuff = [30n 30.2n 30.4n 0 0 ?.]
0 0 implies the end of clock tic information. In the example above only 3 clock
edges were found at 30n, 30.2n and 30.4n
Upon return, the "AMI_getwave" API replaces the initial "wave_in" in the
simulation
environement with the "wave_in" returned by the dll.
Note: All memory will be freed by the caller.
AMI_close
The "AMI_close" API is optional, and is used together with "AMI_getwave".
This is defined as:
extern long AMI_close (void **ptr_2_dll_server_param_obj)
where:
long status = AMI_close (..)
This call is intended for the algorithmic model developer to free up memory
allocated in AMI_Init (dll_server_param_obj points to that storage).
This is the last call before simulation post processing begins. There will be
no
more calls made to the dll (algorithmic models).
********************************************************************************
Other related posts: