[ibis-macro] Re: One MORE time without the typo ... RE: Re: Question about Model Specific parameters

  • From: Todd Westerhoff <twesterh@xxxxxxxxxx>
  • To: "Arpad_Muranyi@xxxxxxxxxx" <Arpad_Muranyi@xxxxxxxxxx>
  • Date: Mon, 21 Feb 2011 11:11:48 -0500 (EST)

Arpad,

I'm say the tool collects all the parameter data, in a format suitable for 
display.

Let me put together an example for you.  I should have some time mid afternoon 
to pull something together.

Todd.


--

Todd Westerhoff
VP, Software Products
SiSoft
6 Clock Tower Place, Suite 250
Maynard, MA. 01754
(978) 461-0449 x24
twesterh@xxxxxxxxxx
www.sisoft.com


On Feb 21, 2011, at 10:41 AM, "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx> wrote:

> Todd,
> 
>  
> 
> This was exactly my point.  On what bases would an EDA tool
> 
> be expected to plot Type Tap and none of the other Types?
> 
> Or, are we saying that the tool is expected to plot any Usage
> 
> InOut/Out regardless of its Type?  And could any other
> 
> expectations from the tool arise for the other Types,
> 
> depending on what their meaning is?  This is where the
> 
> spec is clear as mud.
> 
>  
> 
> If we say that the tool should plot the Type Tap, because
> 
> we know the meaning of it (Tap), people could also come up
> 
> with other rationale for the other types.  But these
> 
> expectations may all be very subjective, personally biased.
> 
> We can’t have such expectations and such loose ends in a
> 
> specification.
> 
>  
> 
> On the other hand, if we do not have such expectations, then
> 
> why would we allow to have InOut/Out for Model Specific
> 
> parameters?  It just doesn’t make sense…
> 
>  
> 
> In my opinion the specification should mention what the tool
> 
> should or could do with these InOut/Out parameters, or
> 
> prohibit them.
> 
>  
> 
> Thanks,
> 
>  
> 
> Arpad
> 
> =============================================================
> 
>  
> 
> From: ibis-macro-bounce@xxxxxxxxxxxxx 
> [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Todd Westerhoff
> Sent: Monday, February 21, 2011 8:08 AM
> To: ibis-macro@xxxxxxxxxxxxx
> Subject: [ibis-macro] Re: One MORE time without the typo ... RE: Re: Question 
> about Model Specific parameters
> 
>  
> 
> Arpad,
> 
>  
> 
> It’s School Vacation week here in MA and I’m out this week – which just means 
> my access to email will be sporadic, so please bear with me.
> 
>  
> 
> 1.       If we collect data returned by a parameter of (Type Tap), we get a 
> list of timestamps and floating point numbers
> 
> 2.       If we collect data returned by a parameter of (Type Float), we get a 
> list of timestamps and floating point numbers
> 
> 3.       If we collect data returned by a parameter of (Type Integer), we get 
> a list of timestamps and integer numbers
> 
> 4.       If we collect data returned by a parameter of (Type String), we get 
> a list of timestamps and strings
> 
>  
> 
> There’s nothing special about (Type Tap).
> 
>  
> 
> Does that help?  I have to run a few errands, but can put an example together 
> later today if needed.
> 
>  
> 
> Todd.
> 
>  
> 
> ________________________
> 
> 
> Todd Westerhoff
> VP, Software Products
> SiSoft
> 6 Clock Tower Place, Suite 250
> Maynard, MA 01754
> (978) 461-0449 x24
> twesterh@xxxxxxxxxx
> www.sisoft.com
> 
>  
> 
> From: ibis-macro-bounce@xxxxxxxxxxxxx 
> [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
> Sent: Sunday, February 20, 2011 12:35 PM
> To: ibis-macro@xxxxxxxxxxxxx
> Subject: [ibis-macro] Re: One MORE time without the typo ... RE: Re: Question 
> about Model Specific parameters
> 
>  
> 
> Todd, Scott,
> 
>  
> 
> Let’s put the finger pointing and personal overtones aside
> 
> and talk on a technical level.  The issue is not whether
> 
> anyone did or does something special.  The issue is that
> 
> the spec allows that to happen.
> 
>  
> 
> Todd,
> 
>  
> 
> SiSoft’s responses to this thread mentioned on multiple
> 
> occasions that since the parameter is a Type Tap, the tool
> 
> should know to plot the returned values.  In that case we
> 
> should put it into the specification that for Type Tap the
> 
> tool is expected or encouraged to plot, or write a log file,
> 
> or report the returned values in some way that is useful to
> 
> the user.  But we have other Types in the spec in addition
> 
> to Tap.  What are we suggesting for the EDA tool to do with
> 
> those?
> 
>  
> 
> Regarding “The model’s documentation should describe what each parameter
> 
> represents, and therefore whether it makes sense to plot it in some special 
> way”
> 
> I don’t see how you can say that an EDA tool could do anything
> 
> based on interpreting each model’s documentation and respond
> 
> accordingly.  This would take a little too much of artificial
> 
> intelligence and a self modifying software code.  Remember,
> 
> there are other Types of Model Specific parameters of Usage
> 
> Out or InOut.  What should be the expectations for those?
> 
>  
> 
> Take for example my previous example of the Float parameter
> 
> CorDeNuit.  If I put it in the “Description” of this parameter
> 
> that the EDA tool should blow its horn, but only at night,
> 
> is your tool going to be able to read and interpret this
> 
> description (documentation) and blow its horn if this
> 
> parameter returns a value during the night time hours?
> 
> Besides, what is the definition of night time hours?  Is it
> 
> midnight to 6 a.m. or 5 p.m. to 8 a.m., etc…?  In addition,
> 
> I don’t see how an EDA tool will read a Word document or PDF
> 
> file, or a Readme.txt file to find out how to interpret the
> 
> Model Specific parameters of an .ami file…  This sounds a
> 
> little too new age-ish to me…
> 
>  
> 
> Arpad
> 
> ===============================================================
> 
>  
> 
> From: ibis-macro-bounce@xxxxxxxxxxxxx 
> [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Todd Westerhoff
> Sent: Friday, February 18, 2011 5:15 PM
> To: ibis-macro@xxxxxxxxxxxxx
> Subject: [ibis-macro] Re: One MORE time without the typo ... RE: Re: Question 
> about Model Specific parameters
> 
>  
> 
> Scott,
> 
>  
> 
> Looks like you’re assuming we’re doing something special because we “know” 
> something about the parameter being plotted.  That isn’t the case.  The .ami 
> file snippet for the model in Mike’s paper looks something like this:
> 
>  
> 
>       (dfe
> 
>          (taps
> 
>              (1 (Usage InOut)(Format Range 0 -1.0 1.0)(Type Tap)
> 
>                  (Default 0)(Description "First DFE tap."))
> 
>              (2 (Usage InOut)(Format Range 0 -1.0 1.0)(Type Tap)
> 
>                  (Default 0)(Description "Second DFE tap."))
> 
>              (3 (Usage InOut)(Format Range 0 -1.0 1.0)(Type Tap)
> 
>                  (Default 0)(Description "Third DFE tap."))
> 
>              (4 (Usage InOut)(Format Range 0 -1.0 1.0)(Type Tap)
> 
>                  (Default 0)(Description "Fourth DFE tap.")))
> 
>  
> 
> This declares the parameter names used to pass tap data into the model, and 
> tells the simulator the model may pass data back via ami_parameters_out using 
> the same parameter names.  Declaring the parameters as (Type Tap) tells the 
> simulator the data to be passed to/from the model is a floating point number 
> – so, in this case, the simulator collects the values for each parameter at 
> each Getwave call, associates them with the appropriate timestamp, and then 
> plots them.  No magic there.
> 
>  
> 
> Fact is, we could have just as easily called the parameters “Frobozz” or 
> “My_Little_Froggie” with (Type Float) … and the process would have worked the 
> same. There’s nothing magic about the parameter names.  If you want to 
> collect a whole bunch of parameters and scatter plot them against each other, 
> go for it.  The model’s documentation should describe what each parameter 
> represents, and therefore whether it makes sense to plot it in some special 
> way.  When a parameter returns a number, it just makes sense to plot how that 
> value progresses throughout the simulation.  I can’t imagine why it wouldn’t. 
> Making that “illegal” makes no sense at all.
> 
>  
> 
> If you’re proposing a standardized form of post-processing ami_parameters_out 
> data, then write it down & let’s discuss it in the Tuesday meetings.  Talking 
> about potential applications is all well and good, but it doesn’t move the 
> spec forward.
> 
>  
> 
> Have a good weekend,
> 
>  
> 
> Todd.
> 
>  
> 
> ________________________
> 
> 
> Todd Westerhoff
> VP, Software Products
> SiSoft
> 6 Clock Tower Place, Suite 250
> Maynard, MA 01754
> (978) 461-0449 x24
> twesterh@xxxxxxxxxx
> www.sisoft.com
> 
>  
> 
> From: ibis-macro-bounce@xxxxxxxxxxxxx 
> [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Scott McMorrow
> Sent: Friday, February 18, 2011 2:14 PM
> To: ibis-macro@xxxxxxxxxxxxx
> Subject: [ibis-macro] Re: One MORE time without the typo ... RE: Re: Question 
> about Model Specific parameters
> 
>  
> 
> Todd
> 
> In short, no.  You keep avoiding the point.  Your last step is undefined and 
> requires someone, either the EDA software writer, or the end-user, to 
> determine:
> 
> What the parameter is.
> What to do with the parameter.
> 
> If you are both the model maker and the EDA vendor, then you are in the 
> privileged position of knowing what the parameters are, how they work, and 
> whether or not there is an "interesting" way to present or post-process the 
> data.  Since a model specific parameter is provided blind, without additional 
> documentation, processing or presentation of these parameters by anyone else, 
> would be a guess, possibly educated, but still a guess.
> 
> The only way to know how to plot, present, or post-process a Model Specific 
> output parameter today is via a-priori knowledge of the "meaning" of the 
> parameter.  Yes, DFE taps are a no-brainer, only because we all believe we 
> have a-priori knowledge of what a Tap is.  The parameters could have just as 
> easily have been named  XYZ_frog1, XYZ_frog2 ... etc.  Do you know how to 
> deal with this parameter?  Neither do I. 
> 
> I maintain that the model maker needs to document, in a machine and human 
> understandable way, what the EDA tool is expected to do with these parameters 
> whether it be, plotting, presentation, or post-processing.  Otherwise, the 
> parameter is not needed.  This means that we as a committee have to come up 
> with documentation on what to do with these model specific output parameters. 
>  The point is, no one knows whether these outputs are important unless they 
> are documented.  IF they are unimportant, then they should not be there.
> 
> An example of acceptable processing might be:
> 
> Reserved for Model Development/Debug
> Plot with respect to time
> Plot against another parameter as a scatter plot
> Status with a some sort of text description
> For example 0 = PLL out of lock, 1 = PLL locked
> Loss of signal
> 
> Scott
> 
> Scott McMorrow
> Teraspeed Consulting Group LLC
> 121 North River Drive
> Narragansett, RI 02882
> (401) 284-1827 Business
> (401) 284-1840 Fax
>  
> http://www.teraspeed.com
>  
> Teraspeed® is the registered service mark of
> Teraspeed Consulting Group LLC
> 
> On 2/18/2011 1:38 PM, Todd Westerhoff wrote:
> 
> Arpad (and Scott),
> 
>  
> 
> For anyone who may not recognize the picture, the excerpted diagram is Figure 
> 7 from the 2008 DesignCon Paper “Demonstration of SerDes Modeling using the 
> Algorithmic Modeling Interface (AMI) Standard”.
> 
> The paper is available on-line from both the DesignCon InfoVault 
> (http://www.designcon.com/infovault/) and SiSoft’s eLearning site 
> (http://www.sisoft.com/elearning/).
> 
>  
> 
> I think we’re debating a semantic difference between post-processing and 
> plotting.  The graph in the presentation was created by accumulating the 
> AMI_parameters_out data passed back from each Getwave call and then plotting 
> the value of the DFE taps as a function of time.  I’m hoping you’ll agree 
> that the EDA tool knows the timestamp associated with Getwave call, so we 
> don’t need to debate the meaning of “as a function of time.”
> 
>  
> 
> If you believe we need to spell this out in more detail, how does the 
> following text:
> 
>  
> 
>  
> 
> Add the following step to each of the application scenarios in section 10.2:
> 
> Optionally, the EDA platform may log the contents of AMI_parameters_out for 
> later display. The generic steps to do this are:
> 
> Parse AMI_parameters_out according to the syntax definition provided in 
> section 10.3.1.2.6.
> 
> Record the name and value of each leaf of the parameter tree. The type of 
> each value is determined directly by the BNF syntax rules that were used to 
> parse the value's representation in the parameter string.
> 
> Present the data to the user in whatever manner the EDA tool deems suitable
> 
>  
> 
>  
> 
> Suit you?
> 
>  
> 
> Todd.
> 
>  
> 
> P.S.  I really proofread this one … hopefully I got all the typos out!
> 
>  
> 
> ________________________
> 
> 
> Todd Westerhoff
> VP, Software Products
> SiSoft
> 6 Clock Tower Place, Suite 250
> Maynard, MA 01754
> (978) 461-0449 x24
> twesterh@xxxxxxxxxx
> www.sisoft.com
> 
>  
> 
> From: Muranyi, Arpad [mailto:Arpad_Muranyi@xxxxxxxxxx] 
> Sent: Friday, February 18, 2011 9:53 AM
> To: twesterh@xxxxxxxxxx; ibis-macro@xxxxxxxxxxxxx
> Subject: RE: [ibis-macro] One MORE time without the typo ... RE: Re: Question 
> about Model Specific parameters
> 
>  
> 
> Todd,
> 
>  
> 
> Regarding “Thus far, I don’t see any examples of that, which leaves me 
> wondering what
> 
> the actual problem we’re debating here is.” your own tools and presentations
> 
> are the examples for that…  The very fact that your tool displays a
> 
> plot of the tap coefficients as they converge to a final value as
> 
> the optimizer is doing its job is post processing.
> 
>  
> 
> <image001.png>
> 
>  
> 
> Or even just putting these values into a log file is post processing.
> 
> The only thing that is not post processing is if these returned parameters
> 
> would be ignored.  But in that case the model might as well not return
> 
> them, which is the same as prohibiting Out and InOut for Model Specific
> 
> parameters…
> 
>  
> 
> Arpad
> 
> ===========================================================================
> 
>  
> 
>  
> 
>  
> 
> From: ibis-macro-bounce@xxxxxxxxxxxxx 
> [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Todd Westerhoff
> Sent: Friday, February 18, 2011 7:27 AM
> To: ibis-macro@xxxxxxxxxxxxx
> Subject: [ibis-macro] One MORE time without the typo ... RE: Re: Question 
> about Model Specific parameters
> 
>  
> 
> Man, I hate it when this happens … perhaps a sign that I should be using my 
> reading glasses more often?
> 
>  
> 
>  
> 
>  
> 
> All,
> 
>  
> 
> I’d like to point out that Model Specific output parameters already have a 
> machine parsable spec, because their names, data types and output format 
> (i.e. how the model passes them back) are defined by the combination of the 
> IBIS 5.0 spec and the .ami file.  Thus, if the EDA tool wants to collect and 
> display that data (even if it’s in a tool-dependent fashion), there’s 
> absolutely nothing wrong with that.
> 
>  
> 
> The potential issue with model portability arises when the simulator is 
> expected to post-process the Parameters_Out data in some fashion, affecting 
> the assessment of the link’S BER (or whatever other key metric you choose to 
> focus on).  Thus far, I don’t see any examples of that, which leaves me 
> wondering what the actual problem we’re debating here is.
> 
>  
> 
> My $0.02.
> 
>  
> 
> Todd.
> 
> ________________________
> 
> 
> Todd Westerhoff
> VP, Software Products
> SiSoft
> 6 Clock Tower Place, Suite 250
> Maynard, MA 01754
> (978) 461-0449 x24
> twesterh@xxxxxxxxxx
> www.sisoft.com
> 
>  
> 
> From: ibis-macro-bounce@xxxxxxxxxxxxx 
> [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Scott McMorrow
> Sent: Thursday, February 17, 2011 9:22 PM
> To: kwillis@xxxxxxxxxxx; Arpad_Muranyi@xxxxxxxxxx; ibis-macro@xxxxxxxxxxxxx
> Subject: [ibis-macro] Re: Question about Model Specific parameters
> 
>  
> 
> Ken
> 
> I agree and would like to make model specific output parameters illegal when 
> they are not accompanied with a machine parsible spec for processing.
> 
> Scott McMorrow
> President
> Teraspeed Consulting Group LLC
> (401) 284-1827
> 
> 
> -----Original message-----
> 
> From: Ken Willis <kwillis@xxxxxxxxxxx>
> To: Arpad_Muranyi@xxxxxxxxxx, ibis-macro@xxxxxxxxxxxxx
> Sent: Thu, Feb 17, 2011 15:47:43 GMT+00:00
> Subject: [ibis-macro] Re: Question about Model Specific parameters
> 
> Hi Arpad,
> 
> I am working on a back-channel BIRD draft now, so this will hopefully help
> to shed some light on the parameter usage being considered. But I agree that
> if there are standard things the EDA tools are supposed to do with model
> outputs, they have to go in the spec. Otherwise it is all open to
> interpretation and model makers don't have a standard to build their models
> to.
> 
> Thanks,
> 
> Ken Willis
> Sigrity, Inc.
> 860-871-7070
> kwillis@xxxxxxxxxxx
> 
> 
> -----Original Message-----
> From: ibis-macro-bounce@xxxxxxxxxxxxx
> [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
> Sent: Thursday, February 17, 2011 10:36 AM
> To: ibis-macro@xxxxxxxxxxxxx
> Subject: [ibis-macro] Re: Question about Model Specific parameters
> 
> Thanks for all the responses. None of these concepts were unfamiliar
> to me, but it was still nice to see them mentioned and summarized.
> But most of you missed the point of my question, most notably Mike's
> question at the end of his reply:
> 
> 
> > Given that so much information has been publicly and widely available 
> > since before IBIS 5.0 was ratified, how is it that you came to
> conclude 
> > that "no EDA vendor has the knowledge on how to interpret or post 
> > process these returned parameters"?
> 
> 
> The answer to Mike's question "how is it that you came to conclude" is
> exactly the point of my discussion: ---> Because the specification
> doesn't say so. A Model Specific parameter can be anything. I agree
> that in case of a Type Tap the EDA tool could have some clues to show
> or print the returned values to the user, but the specification doesn't
> say so. If this is an expectation from the EDA tool, then the
> specification
> should talk about that. But the bigger problem is that there are other
> Types also which could be Out or InOut. What if my AMI model has a
> parameter called CorDeNuit, Type Float, Usage Out? What should my tool
> do with it? Blow its horn at the frequency given in the parameter
> value?
> (Those of you who know pipe organs will get this...) :-)
> 
> I am not challenging the technical explanations give to me in any of
> your responses. The point I am trying to make is that this is simply
> bad spec writing. If the model returns something to the tool which
> supposed to be plotted or printed, or post processed in any way as shown
> in Mike's DesignCon 2008 paper, the specification should define the
> appropriate mechanisms to do so.
> 
> I am getting even more concerned that the Back Channel communication
> was also mentioned in this discussion as a reason to keep Out and
> InOut for Model Specific parameters. I am concerned that these will
> cause further problems and confusions in the future. I think we should
> strive to have a well defined feature set in the specification so that
> individual misinterpretations or tool specific features based on secret
> insider information etc... could be prevented.
> 
> Any comments or suggestions?
> 
> Thanks,
> 
> Arpad
> ========================================================================
> ===
> 
> 
> 
> 
> 
> 
> 
> -----Original Message-----
> From: ibis-macro-bounce@xxxxxxxxxxxxx
> [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Mike Steinberger
> Sent: Thursday, February 17, 2011 8:43 AM
> To: ibis-macro@xxxxxxxxxxxxx
> Subject: [ibis-macro] Re: Question about Model Specific parameters
> 
> Arpad-
> 
> Please find attached a copy of our DesignCon2008 paper on AMI modeling. 
> Among other things, this paper describes the use of parameters of Usage 
> Out to monitor the adaptive loops in receivers. In point of fact, every 
> receiver model that SiSoft writes (and most will admit that's a fair 
> few) reports the behavior of its adaptive loops in exactly this way. 
> Furthermore, many users of SiSoft's Quantum Channel Designer use this 
> data to obtain valuable information about their systems.
> 
> Even at the last IBIS Summit, there were two presentations on channel 
> optimization that reported the application of parameters of Usage Out 
> and InOut.
> 
> If you want to know how all this is done, Mike LaBonte's explanation is 
> right on target..
> 
> Given that so much information has been publicly and widely available 
> since before IBIS 5.0 was ratified, how is it that you came to conclude 
> that "no EDA vendor has the knowledge on how to interpret or post 
> process these returned parameters"?
> 
> Mike S.
> 
> On 2/16/2011 7:02 PM, Muranyi, Arpad wrote:
> > Hello everyone,
> >
> > I stumbled on a situation with an .ami file which has
> > a few Model Specific parameters of Usage InOut. Our
> > customer is wondering why we don't do this and that
> > with the data that is returned by the model in those
> > parameters. This triggers the following thoughts in
> > my mind.
> >
> > Model Specific parameters are specific to the model and
> > their meaning is not described by the AMI specification.
> > Therefore no EDA vendor has the knowledge on how to
> > interpret or post process these returned parameters
> > because there is simply no way of knowing what to do
> > with them.
> >
> > For this reason, I would suggest that we make a rule in
> > the IBIS AMI specification that Model Specific parameter
> > must be Usage In, and Usage Out or InOut should not be
> > allowed.
> >
> > Any Comments?
> >
> > 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
> 
> 
> ---------------------------------------------------------------------
> 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:

  1. Home
  2. ibis-macro
  3. Archive
  4. 02-2011