I'd like to address #1 and #3:
1) This should be mentioned at vote time, but the editorial task group
clearly will fix any such items when the time comes. Making it X.X might
help make it stand out more.
3) We have the precedent of placeholders DLL_Path and DLL_ID, filled in
at run time. Unlike bit_time and sample_interval, DC_Offset is not
always required. I'm OK with it as an AMI parameter.
Mike
On 3/27/2019 1:52 PM, Mirmak, Michael wrote:
Sorry not to have raised these earlier, but the recent posting of BIRD197.2 to the IBIS reflector in advance of the Open Forum vote has “inspired” some questions…
1. The BIRD explicitly states under “Required” that the parameter
DC_Offset is “illegal before AMI_Version 7.0”. Should this read
“7.1”, or even be left as “X.X” until the BIRD is formally
integrated into a specific IBIS document?
2. The BIRD definition and part of the BIRD change text mention step
responses. Are there any other adjustments to IBIS language
needed to make explicit that both step responses and impulse
responses are now legal waveform types as part of AMI simulation?
The concern is that the model and tool may not have unambiguous
information about the waveform to generate/expect.
3. DC_Offset is somewhat “weird” in that we are declaring an input
parameter as part of a .ami file but which is essentially only a
placeholder. In other words, we have other “inputs” to a DLL
which are defined in the specification but are not formally part
of the .ami file structure (the waveform itself is one such
instance, as is bit_time). Anything part of the .ami file is
actually determined by the model maker. Shouldn’t DC_Offset be
part of the AMI function calls, similar to bit_time?
Thanks in advance…
* MM
