[ibis-macro] Re: Samples_per_bit question

  • From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
  • To: "ibis-macro@xxxxxxxxxxxxx" <ibis-macro@xxxxxxxxxxxxx>
  • Date: Wed, 20 Jul 2011 22:47:12 +0000

Scott,

Didn’t we actually move in that direction
(i.e. taking some of the convolutions out
of  the model) as the flow was evolving?

Arpad
==========================================

From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] 
On Behalf Of Scott McMorrow
Sent: Wednesday, July 20, 2011 5:44 PM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: Samples_per_bit question

I'm not saying that I disagree, but wouldn't the same argument apply to 
convolution code?




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 7/20/2011 6:41 PM, Mike Steinberger wrote:
Ambrish-

I ran into at least one case in which, although the model developer knew how to 
implement the required resampling, an implementation in the EDA tool was much 
more efficient computationally.

Another way to look at this is as a software architecture problem. Consider 
that if many models were each to implement resampling, then there would be that 
many implementations floating around, and they would probably all have slightly 
different characteristics. A better software architecture would contain one 
implementation of what could be a commonly used function, and put that 
implementation in a central location. That point of view argues in favor of 
putting the resampling function in the EDA tool, since there are fewer EDA 
tools than there are models.

Now if a given model required very specific characteristics in its resampler, 
then the developer of that model should provide their own implementation...

My 2c.
Mike S.

On 07/20/2011 05:17 PM, Ambrish Varma wrote:

Arpad,

The Tx, Rx hardware must have sampling capabilities in them. The models are 
supposed to emulate the hardware. I don’t understand if we are trying simply to 
make things work or we are trying to improve something.



If the model makers can program complexeties like CDR, Equalization and the 
like, I think we can expect them to do resampling too.



Regards,

-Ambrish.



Ambrish Varma   |  Member of Consulting Staff

P: 978.262.6431   www.cadence.com<http://www.cadence.com>













-----Original Message-----

From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> 
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad

Sent: Wednesday, July 20, 2011 6:08 PM

To: ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>

Subject: [ibis-macro] Re: Samples_per_bit question



While I agree it is ugly, it is probably far better

then require that the AMI model author should do the

same in the model.



For one, if it is done in the tool, you will have only

as many copies of the sample converter code as many

tools exist, but if it is in the model, you will have

to have as many copies of the code as many models exist.



But more importantly, I would rather trust the EDA tools

for doing this conversion than the model makers.  Don't

forget that GetWave is called multiple times, and the

model will also have to take into account those boundaries

correctly...



Arpad

=============================================================



-----Original Message-----

From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> 
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Scott McMorrow

Sent: Wednesday, July 20, 2011 5:02 PM

To: ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>

Subject: [ibis-macro] Re: Samples_per_bit question



In that case, the EDA software must perform the necessary sample rate

conversion.  I agree that it's ugly.







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 7/20/2011 6:00 PM, ckumar wrote:

I do not agree with that.

What happens if the tx and rx requires different samples per bit? Things

can get convoluted very fast.



That is why the emphasis should be on that the models are always seeing

continuous signals. Any way that is what devices do in real life too. They

sample a continuous signal coming into them. Software should be no

different.



On Wed, 20 Jul 2011 21:47:23 +0000, "Muranyi, Arpad"

<Arpad_Muranyi@xxxxxxxxxx><mailto:Arpad_Muranyi@xxxxxxxxxx>  wrote:

Mike, Scott, Kumar,



First, the models I ran into recently were brand new models,

probably not even released yet.  I don't know the reason, but

it appears that the problem might be learning curve related

on the author's part.



This is why I tend to not agree with requiring the models to

do the re-sampling for themselves.  This is extra burden on

the model makers which we should try to avoid.  EDA vendors

are probably better at writing such algorithms, and if the

EDA vendor knows what sampling rate the model works with

(using the proposed required and reserved parameter for that),

they can do the re-sampling for the model if necessary before

executing it.



I would prefer to put this Sample_per_bit parameter in the

AMI spec, and make it required, reserved.





Ambrish,



I agree that "to require a certain samples_per_bit for the model to work

is not good"

but it does happen unfortunately.  But I am not sure what you mean

by "We can deal with this at a tool level and not put anything in the

spec".  How would

the tool know how to deal with a certain model if it doesn't know

what sample rate(s) the model works with?  I think the only way

a tool can deal with this if every model would be required to

tell the tool with a reserved parameter what its sampling rate

needs/capabilities are.



Thanks,



Arpad

=====================================================================





From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>

[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Mike Steinberger

Sent: Wednesday, July 20, 2011 4:17 PM

To: ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>

Subject: [ibis-macro] Re: Samples_per_bit question



Scott-



Moving forward, we could conceivably take the approach you suggest. That

approach still doesn't address the models that are already out there,

however. I, for one, don't want to be in the position of telling users

they

can no longer run models that they've been running for years. (Actually,

I

know for a fact that I personally won't be in that position, so it's

really

a choice for others to make.)



Mike S.



On 07/20/2011 03:53 PM, Scott McMorrow wrote:

Ambrish



Why not go the other direction, which would be to explicitly require

that

the model perform sample rate conversion to any sample rate.



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(r) is the registered service mark of



Teraspeed Consulting Group LLC



On 7/20/2011 4:49 PM, Ambrish Varma wrote:

I think we all agree that to require a certain samples_per_bit for the

model to work is not good. We can deal with this at a tool level and not

put anything in the spec as this will most definitely give it more

prominence. In other words, model makers will feel compelled to 'do

something' with this parameter.

My 2 cents.



-Ambrish.









[cid:image002.gif@01CC46FB.CCC6FBB0]







Ambrish Varma   |  Member of Consulting Staff



P: 978.262.6431   
www.cadence.com<http://www.cadence.com><http://www.cadence.com><http://www.cadence.com>





















________________________________

From:

ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx><mailto:ibis-macro-bounce@xxxxxxxxxxxxx><mailto:ibis-macro-bounce@xxxxxxxxxxxxx>

[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Dmitriev-Zdorov,

Vladimir

Sent: Wednesday, July 20, 2011 4:25 PM

To: 
msteinb@xxxxxxxxxx<mailto:msteinb@xxxxxxxxxx><mailto:msteinb@xxxxxxxxxx><mailto:msteinb@xxxxxxxxxx>;

ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx><mailto:ibis-macro@xxxxxxxxxxxxx><mailto:ibis-macro@xxxxxxxxxxxxx>

Subject: [ibis-macro] Re: Samples_per_bit question





Agree,







We also encountered with such models. The problem is when something does

not work it is difficult to guess what's the problem and even after that

it

takes several tries to find an appropriate parameter.







Vladimir





From:

ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx><mailto:ibis-macro-bounce@xxxxxxxxxxxxx><mailto:ibis-macro-bounce@xxxxxxxxxxxxx>

[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Mike Steinberger

Sent: Wednesday, July 20, 2011 2:18 PM

To: 
ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx><mailto:ibis-macro@xxxxxxxxxxxxx><mailto:ibis-macro@xxxxxxxxxxxxx>

Subject: [ibis-macro] Re: Samples_per_bit question



Kumar-



We agree with you in principle, and on the two occasions (years ago now)

when we encountered a model that required a specific number of samples

per

bit, we did ask the model developers to make their models more general.

Unfortunately, neither the IBIS spec nor any customer required them to

support an arbitrary number of samples per bit, so the model developers

did

not accept our suggestion.



These models have now been in widespread use for several years. Given

that, how should we handle the problem? To date, the solution we've

proposed is the Samples_per_bit reserved parameter.



Thanks.

Mike S.



On 07/20/2011 03:07 PM, ckumar wrote:



the ami model should treat the waveforms as continuous. They should



resample it inside the model for their requirements.



Requiring specific sample size is an unnecessary constraint.



On Wed, 20 Jul 2011 19:44:03 +0000, "Muranyi, Arpad"



<Arpad_Muranyi@xxxxxxxxxx><mailto:Arpad_Muranyi@xxxxxxxxxx><mailto:Arpad_Muranyi@xxxxxxxxxx><mailto:Arpad_Muranyi@xxxxxxxxxx>
  wrote:



Hello everyone,







I recall that we asked Walter to remove the proposed Samples_per_bit



Reserved AMI parameter from BIRD 121, which he did in BIRD 121.1.



What I don't remember is whether we made this request because we



decided that we didn't want/need this reserved parameter in the AMI



specification at all, or whether we just didn't want to propose this



in BIRD 121, since it seemed unrelated to the rest of the BIRD 121



content.  Could someone please refresh my memory on that?







The reason I am asking is because just recently I ran across a couple



of AMI models which only work at certain samples per bit settings



but there was no documentation that I am aware of that came with the



model that stated that.







I am not sure if this was done intentionally by the model's authors,



but it seems that a required reserved parameter would at least serve



as a reminder to the model makers to document the value at which



their model works, if not remind them to write models that work at



any reasonable samples per bit values.







Based on this experience I tend to feel that a required, and reserved



parameter for Samples_per_bit would be very useful in the AMI spec...







Comments, suggestions are welcome.







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<mailto:ibis-macro-request@xxxxxxxxxxxxx><mailto:ibis-macro-request@xxxxxxxxxxxxx><mailto: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<mailto: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<mailto:ibis-macro-request@xxxxxxxxxxxxx>

  Subject: unsubscribe



!#r�0y�"��m����

‑u�+��no�����i�蚇^����HHƜ���~W������

0~���+-����X�����ɚr���칻�&ޱ��jw�j)S�&�f���ު笵��zX���+�+���-�{.n�+��

 
1�+���+^��i��0��Z��?�������f����u�p�����i����y�h�m�����y�b��(��������+�:.�˛���m�‑�֧zf��:"n+&i���z�_�祊�l�����rۧ���r��e===

Other related posts:

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