[ibis-macro] Re: IBIS-ATM teleconference - Agenda for 10/6/2009
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: "IBIS-ATM" <ibis-macro@xxxxxxxxxxxxx>
- Date: Wed, 7 Oct 2009 18:28:12 -0700
Danil,
Thank you very much for your comments and questions. This is the
best time to bring these up, before the spec is finalized.
I agree with you on trying to keep things simple. The complications
arose from the notion to keep old models working while allowing for
the changes in the new flow. The fundamental question is whether we
want to simplify the new flow so that it is straightforward and easy,
but without support for the old models (or flow), or keep the old
models working while making the new flow possible also.
The need for the Init function returning filter only was explained
by Walter on slides 8-9 of this presentation:
http://www.vhdl.org/pub/ibis/macromodel_wip/archive/20090921/walterkatz/
New%20Reference%20Flow/New_Reference_Flow.pdf
Another "need" may be to simplify the model writer's job by eliminating
the convolution from the model and let it be done by the EDA tool,
although it is not too hard to find code examples on the internet for
implementing a convolution.
Regarding: "For many FFE algorithms h_tei is just a sum of several
delta functions, so we might see some numerical problems if engine
and model writers have different algorithms for convolution." I can't
respond to this with a meaningful answer, but if this was a problem,
we could perhaps spell some rules out in the AMI specification on how
to describe the filter appropriately, and/or how the EDA tool supposed
to treat the information coming from the Init function.
Another reason for needing to return "filter only" is to be able to
execute the right side of the flow diagram without duplicating any
of the convolutions under all circumstances i.e. all possible
combinations for the GetWave functions being present or absent.
I think your suggestion:
Simulation:
x(t) -> TX_Getwave -> Engine convolution with h_ac()*h_tei()*h_rei() ->
RX_Getwave
may not work for all situations, because your engine convolution
includes h_TEI(t) and h_REI(t) before Rx_GetWave. My understanding
is that you only need to include these if their corresponding GetWave
functions is missing.
Please don't hesitate to continue this discussion either in this
email forum or in the upcoming meetings. My goal is to arrive at
a solution that is useful to all of us involved.
Thanks,
Arpad
=======================================================================
-----Original Message-----
From: Danil Kirsanov [mailto:dkirsanov@xxxxxxxxxx]
Sent: Tuesday, October 06, 2009 1:17 PM
To: Muranyi, Arpad; 'IBIS-ATM'
Cc: 'Steve Pytel'
Subject: RE: [ibis-macro] IBIS-ATM teleconference - Agenda for 10/6/2009
Hi Arpad,
Thank you one more time for leading this discussion. Here are my
comments on
new AMI specs on behalf of Ansoft (sorry if I am re-iterating some of
the
questions you answered before):
- we totally agree with the change proposed on 9/8 (TX Getwave goes in
front
of channel convolution).
- for the rest of the changes, we believe that we need more discussion
before they go into the final spec. We are concerned that the AMI chart
is
getting more and more complicated, while in some cases these
complications
can be avoided.
For example, we believe that the simulator behavior should not depend on
the
fact whether GetWave function exists or not (9/29 proposition). By
definition, this is just a non-linear part of the transmitter/receiver
algorithm that is applied on the simulation stage. If the model writer
does
not need it, he should not include it in the library or should just
include
an empty function. So far I do not see that any problems with this
workflow.
Similarly, we are concerned about the case where in the Init function
the
model returns only the impulse response of the model h_tei(), instead of
returning h_ac()*h_tei(). For many FFE algorithms h_tei is just a sum of
several delta functions, so we might see some numerical problems if
engine
and model writers have different algorithms for convolution. Is the only
reason that we need h_tei separately is that some simulators might
introduce
noise after transmitter but before the channel?
So it would be great if we have some examples that show why these
particular
complications in AMI flow are necessary. I've seen some discussions on
these
topics in the previous meetings of AMI committee, but I failed to find
the
summary of those discussions (sorry if I missed something).
So, could we, for example, consider the simplest implementation of AMI
algorithm:
Initialization:
h_ac -> TX_Init -> h_ac()*h_tei() -> RX_Init -> h_ac()*h_tei()*h_rei()
Simulation:
x(t) -> TX_Getwave -> Engine convolution with h_ac()*h_tei()*h_rei() ->
RX_Getwave
It would be great if we could discuss the cases where this simple scheme
wouldn't work (assuming the model writer can write any code in Init and
Getwave).
Sorry one more time if I missed some previous arguments on this topic; I
did
my best to go through the documents related to the previous AMI
meetings.
Unfortunately, I won't be able to participate in today's discussion (I
have
to be on AMI-promoting presentation on our road show), so I hope that
you
can take our concerns into consideration, and maybe forward my e-mail to
the
other people on the committee.
Thank you one more time for all your work,
Danil
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Tuesday, October 06, 2009 1:08 PM
To: IBIS-ATM
Subject: [ibis-macro] IBIS-ATM teleconference - Agenda for 10/6/2009
Time: October 6, 2009 Noon US Pacific Daylight Time
=====
Audio:
======
Voice dial-in: (800) 637-5822
International: +1 (647) 723-3937 <--- (For Canada)
0114501530 <--- (For Sweden)
0201400572 <--- (For Sweden Toll Free)
069509594672 <--- (For Germany)
08001014542 <--- (For Germany Toll free)
Access Code: 685-0440
Web
===
Click Here to Join Live Meeting:
http://tinyurl.com/yvmesj
or:
https://www.livemeeting.com/cc/sisoft/join?id=NKQQN3&role=attend&pw=TP8j
%23-%25%7E5
Mentor Global Crossing Teleconference commands:
http://www.globalcrossing.com/customer/collaboration/cust_ready_access_t
ips.aspx
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) Call for any related patent disclosures
3) Review of ARs:
Arpad: Write a clarification BIRD to discuss accuracy issues
related to the various AMI clock_tick algorithms in an
IBIS-AMI DLL
- not done yet
Todd: Update the BIRD for IBIS S-parameter box based on
feedback from discussion
- not done yet
Any other AR-s?
Old ARs:
- Arpad: Write parameter passing syntax proposal (BIRD draft)
for *-AMS models in IBIS that is consistent with the
parameter passing syntax of the AMI models
- not done
- TBD: Propose a parameter passing syntax for the SPICE
[External ...] also?
- Arpad: Review the documentation (annotation) in the macro libraries.
- deferred until a demand arises or we have nothing else to do
4) Discuss the AMI flow that was suggested in the last meeting
(Its graphical representation is on the ATM web site).
5) Discuss IBIS-ISS open questions so it could be released to the
Open Forum for review soon.
Thanks,
Arpad
=====================================================================
---------------------------------------------------------------------
IBIS Macro website : http://www.eda.org/pub/ibis/macromodel_wip/
IBIS Macro reflector: //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: //www.freelists.org/list/ibis-macro
To unsubscribe send an email:
To: ibis-macro-request@xxxxxxxxxxxxx
Subject: unsubscribe
Other related posts:
