Hello
I have been looking at channel designers from Mentor, Cadence, SiSoft, and Sigrity that claim to support AMI models. However, to date I have only seen Sigrity's channel designer support AMI models "out of the box", and can generate the BER curves, and statistical eye's.
In the case of Mentor, it looks like they only have special support for the Xilinx models embedded within the kit (? is this correrct ?). I assume this means Mentor does not yet have a tool where you can take any vendors AMI model and just drop into a schematic unless you work with them to develop a kit similar to Xilinx.
Does anyone know if/how Mentor (Hyperlynx GHz), Cadence (Signal Explorer), and SiSoft (Quantum Channel Designer) support out of the box AMI models?
________________________________
This communication contains confidential information intended only for the addressee(s). If you have received this communication in error, please notify us immediately and delete this communication from your mail box.
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request (AT) freelists (DOT) org with 'unsubscribe' in the Subject field
Eric,
I believe SiSoft support is "out of the Box" and they do have a quite a few models available (looking at their internal customer site). I know a number of CAD tool vendors are presenting at DesignCon and would recommend contacting them directly for Demo's.
Regards
Bob Haller
Si/Architect
Enterasys Networks
-----Original Message-----
From: si-list-bounce (AT) freelists (DOT) org [mailto:si-list-bounce (AT) freelists (DOT) org] On Behalf Of Eric Monteiro
Sent: Wednesday, February 03, 2010 11:00 AM
To: si-list (AT) freelists (DOT) org
Subject: [SI-LIST] IBIS-AMI Vendor Support Help
Hello
I have been looking at channel designers from Mentor, Cadence, SiSoft, and Sigrity that claim to support AMI models. However, to date I have only seen Sigrity's channel designer support AMI models "out of the box", and can generate the BER curves, and statistical eye's.
In the case of Mentor, it looks like they only have special support for the Xilinx models embedded within the kit (? is this correrct ?). I assume this means Mentor does not yet have a tool where you can take any vendors AMI model and just drop into a schematic unless you work with them to develop a kit similar to Xilinx.
Does anyone know if/how Mentor (Hyperlynx GHz), Cadence (Signal Explorer), and SiSoft (Quantum Channel Designer) support out of the box AMI models?
________________________________
This communication contains confidential information intended only for the addressee(s). If you have received this communication in error, please notify us immediately and delete this communication from your mail box.
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request (AT) freelists (DOT) org with 'unsubscribe' in the Subject field
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request (AT) freelists (DOT) org with 'unsubscribe' in the Subject field
Like other respondents, I am not sure what exactly you meant by
"out of the box" support for AMI models, but I will try to give
you an overview of where the IBIS-AMI specification and models
are today and Mentor's support for them.
IBIS-AMI models consist of three main components.
- Analog models for the Tx and Rx to be used for generating a
channel response for the AMI DLL-s. This would come in the
form of legacy .ibs file(s) containing [Model](s) for the
Tx and Rx buffers and under each of these [Model] statements
a keyword [Algorithmic Model] which points to the AMI DLL
executable(s).
- Algorithmic models (the DLL executables)
- A parameter file (.ami) for each of the algorithmic models.
You must have all three of these to have a complete solution.
Without the analog models you can't characterize the channel and
generate an impulse response which is a fundamental input for the
algorithmic models. (You can make one up, but that is essentially
the same as garbage in, garbage out).
Without the parameter file (.ami file), you have no idea of how
the vary the settings of the algorithmic model, at best you can
hope that it will have default settings which will give you some
results to look at.
And obviously with the DLL itself do can't get anything done,
because you don't have the model itself.
To top it off, all three of these elements need to be written in
an IBIS specification compliant way to ensure Interoperability and
Transportability which are listed as the first two goals in the
"What is IBIS-AMI" article at:
In my experience, this is not always the case with existing IBIS-AMI
solutions. Often there are either missing components or proprietary,
non-compliant solutions distributed as IBIS-AMI models. This makes
it difficult to develop an "out of the box" solution, if this is how
you meant your question.
Regarding your specific question on Mentor's HyperLynx design kit for
the Xilinx product(s), we do not have any technical reason (or
limitation) to "have only special support for the Xilinx models".
In fact you can plug in any other IBIS-AMI DLL into that design kit
and it will work fine. But we cannot release a complete general
solution for IBIS-AMI until we can test it with real and IBIS
compliant model files. So far we were simply unable to get a
complete set of such files for any SERDES product from IC vendors.
If you would like to get more specific information about our solution,
I would like to encourage you to contact us either at DesignCon or
via email. We will be happy to give you demos and more info about
our capabilities.
Thanks,
Arpad
================================================== ======================
==
-----Original Message-----
From: si-list-bounce (AT) freelists (DOT) org [mailto:si-list-bounce (AT) freelists (DOT) org]
On Behalf Of Eric Monteiro
Sent: Wednesday, February 03, 2010 10:00 AM
To: si-list (AT) freelists (DOT) org
Subject: [SI-LIST] IBIS-AMI Vendor Support Help
Hello
I have been looking at channel designers from Mentor, Cadence, SiSoft,
and Sigrity that claim to support AMI models. However, to date I have
only seen Sigrity's channel designer support AMI models "out of the
box", and can generate the BER curves, and statistical eye's.
In the case of Mentor, it looks like they only have special support for
the Xilinx models embedded within the kit (? is this correrct ?). I
assume this means Mentor does not yet have a tool where you can take any
vendors AMI model and just drop into a schematic unless you work with
them to develop a kit similar to Xilinx.
Does anyone know if/how Mentor (Hyperlynx GHz), Cadence (Signal
Explorer), and SiSoft (Quantum Channel Designer) support out of the box
AMI models?
________________________________
This communication contains confidential information intended only for
the addressee(s). If you have received this communication in error,
please notify us immediately and delete this communication from your
mail box.
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request (AT) freelists (DOT) org with 'unsubscribe' in the Subject field
Hi Eric, given how fast the standard is evolving and how varied the
vendor's interpretations are, it seems like there are some significant
differences in the AMI models I've seen. I have to concur with the other
responses that an "out of the box" AMI implementation is a bit unclear.
One convenient way that some EDA vendors are allowing customers to get
meaningful simulation results immediately is through vendor specific
design kits. The end user only needs to input their specific channel
(s-parameters, w-elements, field simulations, etc) and tweak some
parameters to match their specific devices. Ansoft has one of these
design kits available using the latest released version of Designer and
IBM HSS15 models. There is an overview of this kit, as well as HSSCDR
correlation available at http://www.vhdl.org/pub/ibis/summits/nov09a/herrick.pdf. Although I have
not yet put together official design kits, we also have working AMI
examples from Rambus, Broadcom and Xilinx. Of course you will need to
contact these companies individually to obtain the models.
Thanks,
Chris
-----Original Message-----
From: si-list-bounce (AT) freelists (DOT) org [mailto:si-list-bounce (AT) freelists (DOT) org]
On Behalf Of Eric Monteiro
Sent: Wednesday, February 03, 2010 8:00 AM
To: si-list (AT) freelists (DOT) org
Subject: [SI-LIST] IBIS-AMI Vendor Support Help
Hello
I have been looking at channel designers from Mentor, Cadence, SiSoft,
and Sigrity that claim to support AMI models. However, to date I have
only seen Sigrity's channel designer support AMI models "out of the
box", and can generate the BER curves, and statistical eye's.
In the case of Mentor, it looks like they only have special support for
the Xilinx models embedded within the kit (? is this correrct ?). I
assume this means Mentor does not yet have a tool where you can take any
vendors AMI model and just drop into a schematic unless you work with
them to develop a kit similar to Xilinx.
Does anyone know if/how Mentor (Hyperlynx GHz), Cadence (Signal
Explorer), and SiSoft (Quantum Channel Designer) support out of the box
AMI models?
________________________________
This communication contains confidential information intended only for
the addressee(s). If you have received this communication in error,
please notify us immediately and delete this communication from your
mail box.
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request (AT) freelists (DOT) org with 'unsubscribe' in the Subject field
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request (AT) freelists (DOT) org with 'unsubscribe' in the Subject field
Please bear with me if the line wraps in this email are messed up - I'm
trying to figure out how
to author messages in plain text using a new email client.
I'd like to point out a few things about "out of the box" support for
IBIS-AMI.
As Eric has defined it, "out of the box" support means the ability to
read a compliant IBIS-AMI
model into a channel simulator and use it without modification. If you
have access to a Channel Simulator,
you can test whether it supports "out of the box" models yourself, as
reference IBIS-AMI models were
published some time ago. The SiSoft IBIS-AMI simulation toolkit
includes a complete IBIS-AMI model
(.ibs, ami, .dll) that can be used as a test case. Although the model
was published by SiSoft, it's fully
compliant with the standard - in fact, is there's any aspect of the
model you believe to be non-compliant,
we'd appreciate hearing about it.
The latest IBIS-AMI simulation toolkit can be found at:
If you just want to download the model, you'll find links to the .ibs,
..ami and .dll files as well.
Why would a model ever be non-compliant? There are two main reasons.
The first (and possibly the issue
Eric was raising) is that the simulator vendor may not fully support the
standard. The .ami file is a "control file"
that tells the simulator how to load and execute the .dll, and what
model configuration options are available.
From what I've seen, some vendors don't support this fully, and require
a tool-specific model control file instead.
It's usually the same information in a different format, but it does
require that the user understand the details of
a proprietary modeling format.
The second reason a model might be non-compliant is that is uses
extensions to IBIS-AMI that haven't been
accepted as part of the standard yet. A good example of this is the use
of S-parameter data in place of the
analog model. The 5.0 IBIS spec doesn't readily lend itself to
describing the broadband behavior of analog I/O.
IBM, Cisco and SiSoft proposed a method for dealing with this in
February 2009:
Although the exact syntax for this capability is still in discussion,
there *ARE* models out there that use this
syntax, or something very similar. There are a number of semiconductor
vendors that use S-parameter
data to characterize the analog aspects of their I/O, and there's no
good reason, in my opinion, to compromise
model accuracy because we haven't settled on the final syntax for the
standard. The consequence of this
is that the S-parameter data gets included in a slightly different
fashion between tools, but the purpose
and the S-parameter data are the same. Claiming that a model "isn't
compliant!" and "doesn't work out of the
box!" may make for a good sound bite, but this isn't rocket science,
especially since the proposed method
and syntax have been documented publicly.
I think it's worth pointing out what compatibility and compliance issues
you're NOT hearing about, which are
significant by their absence. IBIS-AMI created a completely new kind of
signal integrity model (an executable
algorithmic model) that gets linked into a new class of simulation tool
(a Channel Simulator) at run time. The
interface between the model and the simulator is a complex Application
Programming Interface, or API,
that has to be implemented precisely and correctly by everyone for the
algorithmic models to work at all. This
was a huge challenge - opportunities for miscommunication and error were
many. Publishing reference
models and providing simulation test benches allowed the industry to
create executable algorithmic models
and EDA tools that really do work as intended. I've found it amazing
how quickly algorithmic models from
different semiconductors vendors have come up, and how well the public
reference model / test bench
strategy has worked.
I'm sure the discussion will continue, so I'm going to leave off here
for now.
Todd.
Todd Westerhoff
VP, Software Products
SiSoft
6 Clock Tower Place, Suite 250
Maynard, MA 01754
(978) 461-0449 x24
twesterh (AT) sisoft (DOT) com www.sisoft.com
Eric Monteiro wrote:
> Hello
> I have been looking at channel designers from Mentor, Cadence, SiSoft, and Sigrity that claim to support AMI models. However, to date I have only seen Sigrity's channel designer support AMI models "out of the box", and can generate the BER curves, and statistical eye's.
>
> In the case of Mentor, it looks like they only have special support for the Xilinx models embedded within the kit (? is this correrct ?). I assume this means Mentor does not yet have a tool where you can take any vendors AMI model and just drop into a schematic unless you work with them to develop a kit similar to Xilinx.
>
> Does anyone know if/how Mentor (Hyperlynx GHz), Cadence (Signal Explorer), and SiSoft (Quantum Channel Designer) support out of the box AMI models?
>
> Best Regards,
>
> Eric
>
> Gennum Corporation AMS Division
> 4281 Harvester Road
> Burlington, Ontario L7L-5M4
> Canada
>
> Phone: 905-632-2999 x 4260
>
>
>
>
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request (AT) freelists (DOT) org with 'unsubscribe' in the Subject field
The links to the IBIS-AMI Toolkit and reference model can be found at the bottom of the page. I apologize for any confusion.
Todd.
Todd Westerhoff
VP, Software Products
SiSoft
6 Clock Tower Place, Suite 250
Maynard, MA 01754
(978) 461-0449 x24
twesterh (AT) sisoft (DOT) com www.sisoft.com
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request (AT) freelists (DOT) org with 'unsubscribe' in the Subject field
The links to the IBIS-AMI Toolkit and reference model can be found at
the bottom of the page. I apologize for any confusion.
Todd.
Todd Westerhoff
VP, Software Products
SiSoft
6 Clock Tower Place, Suite 250
Maynard, MA 01754
(978) 461-0449 x24
twesterh (AT) sisoft (DOT) com www.sisoft.com
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request (AT) freelists (DOT) org with 'unsubscribe' in the Subject field
The links to the IBIS-AMI Toolkit and reference model can be found at
the bottom of the page. I apologize for any confusion.
Todd.
Todd Westerhoff
VP, Software Products
SiSoft
6 Clock Tower Place, Suite 250
Maynard, MA 01754
(978) 461-0449 x24
twesterh (AT) sisoft (DOT) com www.sisoft.com
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request (AT) freelists (DOT) org with 'unsubscribe' in the Subject field
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request (AT) freelists (DOT) org with 'unsubscribe' in the Subject field
[SI-LIST] Re: Altera Unveils Innovations for 28-nm/28 Gbps FPGAs
So, what is your question?
Chris
Infineon
-----Original Message-----
From: si-list-bounce (AT) freelists (DOT) org [mailto:si-list-bounce (AT) freelists (DOT) org] On Behalf Of Mike Peng Li
Sent: Monday, February 08, 2010 2:34 PM
To: si-list (AT) freelists (DOT) org
Subject: [SI-LIST] FYI: Altera Unveils Innovations for 28-nm/28 Gbps FPGAs
Altera Unveils Innovations for 28-nm FPGAs
Press Release Source: Altera Corporation On Monday February 1, 2010, 12:00 pm EST
SAN JOSE, Calif.--(BUSINESS WIRE)--Building on its history of technology leadership, Altera Corporation (NASDAQ:ALTR - News) announced today new innovations that will be incorporated into upcoming 28-nm FPGAs. Embedded HardCopy(r) Blocks, a new method for partial reconfiguration and embedded 28-Gbps transceivers will dramatically improve the density and I/O performance of next-generation Altera(r) FPGAs and further strengthen their competitive position versus ASICs and ASSPs.
The rapid growth of bandwidth-intensive applications such as high-definition (HD) video, cloud computing, online data storage and mobile video has created a challenge for both infrastructure and end-user equipment developers. How can they quickly increase system bandwidth while staying within strict power and cost budgets? Altera has developed its latest innovations to solve these challenges.
The new Embedded HardCopy Blocks are customizable hard intellectual property (IP) blocks that leverage Altera's unique HardCopy ASIC capabilities. They are used to harden standard or logic-intensive functions such as interface protocols, application-specific functions, and proprietary custom IP. The Embedded HardCopy Blocks offer customers faster time to market for their designs while also reducing cost and power. For Altera, this innovation allows the company to quickly create variant products and target specific market segments.
Partial reconfiguration allows designers to reconfigure part of the FPGA while other sections remain running. This is extremely important in systems where uptime is critical because it allows designers to make updates or adjust functionality without disrupting services. Lowering power and cost, partial reconfiguration also improves effective logic density by removing the necessity to place in the FPGA functions that do not operate simultaneously. Instead, these functions can be stored in external memory and loaded as needed. This reduces the size of the FPGA by allowing multiple applications on a single FPGA, saving board space and reducing power.
To date, partial reconfiguration solutions have been time-intensive tasks that required designers to know all of the intricate FPGA architecture details. Altera is simplifying the partial reconfiguration process by building the capability on top of the proven incremental compile design flow in its Quartus(r) II design software.
Extending its leadership in embedded transceiver technology, Altera has developed 28-Gbps embedded transceivers, which will also be implemented in upcoming 28-nm FPGAs. These high-speed transceivers will enable customers to implement next-generation designs such as 400G systems on a single chip without the need for costly external components.
"Two years ago, Altera introduced the industry's first 40-nm FPGAs, and continued delivering industry firsts such as embedded 11.3-Gbps transceivers," said John Daane, president, chairman and CEO of Altera. "As we move to the next process node, these new innovations from Altera will take the industry beyond the benefits of Moore's Law to solve bandwidth challenges while staying within cost and power requirements."
About Altera
Altera programmable solutions enable system and semiconductor companies to rapidly and cost-effectively innovate, differentiate and win in their markets. Find out more about Altera's FPGA, CPLD and ASIC devices at www.altera.com. Follow Altera via Facebook, RSS and Twitter.
Altera, the Altera logo, and all other words that are identified as trademarks are, unless noted otherwise, Registered, U.S. Patent and Trademark Office, and the trademarks of Altera Corporation in the U.S. and other countries. All other product or service names are the property of their respective holders.
This contains a forward-looking statement regarding the incorporation of new innovations into upcoming 28 nm FPGAs that is made pursuant to the safe harbor provisions of the Private Securities Litigation Reform Act of 1995. Investors are cautioned that all forward-looking statements involve risks and uncertainty, including without limitation the risk that future performance is dependent on product development schedules, the design performance of software and other tools, as well as the company's and third parties' development technology and manufacture capabilities. Please refer to the company's Securities and Exchange Commission filings, copies of which are available from the company without charge.
Confidentiality Notice.
This message may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient, you are hereby notified that any use, disclosure, dissemination, distribution, or copying of this message, or any attachments, is strictly prohibited. If you have received this message in error, please advise the sender by reply e-mail, and delete the message and any attachments. Thank you.
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request (AT) freelists (DOT) org with 'unsubscribe' in the Subject field
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request (AT) freelists (DOT) org with 'unsubscribe' in the Subject field
[SI-LIST] Re: Correction: Re: IBIS-AMI Vendor Support Help
Syed,
The base receiver model SiSoft uses includes a peaking filter, Decision
Feedback Equalizer and full clock recovery loop. This represents a
substantial development effort and isn't something that we're able to
publish. Having a simpler receiver model that we can publish is
something that we can consider that for a future addition to the toolkit.
I understood the task at hand to be providing a method to determine
whether a given simulator could utilize a standard IBIS-AMI model (.ibs,
..ami, .dll). I believe the reference model in the current toolkit can
be used to accomplish that task.
Thanks,
Todd.
Todd Westerhoff
VP, Software Products
SiSoft
6 Clock Tower Place, Suite 250
Maynard, MA 01754
(978) 461-0449 x24
twesterh (AT) sisoft (DOT) com www.sisoft.com
Syed Huq (huqs) wrote:
> Todd,
> The referenced link only has a sisoft_tx.ibs file. Where is the Receiver
> model ?
>
> Tks
> Syed
>
> -----Original Message-----
> From: si-list-bounce (AT) freelists (DOT) org [mailto:si-list-bounce (AT) freelists (DOT) org]
> On Behalf Of Todd Westerhoff
> Sent: Monday, February 08, 2010 11:16 AM
> To: si-list (AT) freelists (DOT) org
> Subject: [SI-LIST] Correction: Re: IBIS-AMI Vendor Support Help
>
> All,
>
> The URL I posted this morning for the IBIS-AMI simulation toolkit and
> IBIS-AMI reference models was incorrect. The correct link is:
>
> http://www.sisoft.com/elearning_ibis-ami.asp
>
> The links to the IBIS-AMI Toolkit and reference model can be found at
> the bottom of the page. I apologize for any confusion.
>
> Todd.
>
> Todd Westerhoff
> VP, Software Products
> SiSoft
> 6 Clock Tower Place, Suite 250
> Maynard, MA 01754
> (978) 461-0449 x24
> twesterh (AT) sisoft (DOT) com
> www.sisoft.com
>
>
>
> ------------------------------------------------------------------
> To unsubscribe from si-list:
> si-list-request (AT) freelists (DOT) org with 'unsubscribe' in the Subject field
>
> or to administer your membership from a web page, go to:
> http://www.freelists.org/webpage/si-list
>
> For help:
> si-list-request (AT) freelists (DOT) org with 'help' in the Subject field
>
>
> List technical documents are available at:
> http://www.si-list.net
>
> List archives are viewable at:
> http://www.freelists.org/archives/si-list
>
> Old (prior to June 6, 2001) list archives are viewable at:
> http://www.qsl.net/wb6tpu
>
>
>
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request (AT) freelists (DOT) org with 'unsubscribe' in the Subject field
[SI-LIST] Re: FYI: Altera Unveils Innovations for 28-nm/28 Gbps FPGAs
While all very interesting, si-list really isn't the proper venue for
distributing vendor press releases.
In the future I'd appreciate it if Altera would find an alternate place
to distribute your press releases.
(not to single out a particular company, the same goes for all vendors)
-Ray Anderson
Si-list admin
Xilinx Inc.
> -----Original Message-----
> From: si-list-bounce (AT) freelists (DOT) org [mailto:si-list-
> bounce (AT) freelists (DOT) org] On Behalf Of Mike Peng Li
> Sent: Monday, February 08, 2010 11:34 AM
> To: si-list (AT) freelists (DOT) org
> Subject: [SI-LIST] FYI: Altera Unveils Innovations for 28-nm/28 Gbps
> FPGAs
>
> Altera Unveils Innovations for 28-nm FPGAs
>
> Press Release Source: Altera Corporation On Monday February 1, 2010,
> 12:00 pm EST
>
> SAN JOSE, Calif.--(BUSINESS WIRE)--Building on its history of
> technology leadership, Altera Corporation (NASDAQ:ALTR - News)
> announced today new innovations that will be incorporated into
upcoming
> 28-nm FPGAs. Embedded HardCopy(r) Blocks, a new method for partial
> reconfiguration and embedded 28-Gbps transceivers will dramatically
> improve the density and I/O performance of next-generation Altera(r)
> FPGAs and further strengthen their competitive position versus ASICs
> and ASSPs.
>
> The rapid growth of bandwidth-intensive applications such as high-
> definition (HD) video, cloud computing, online data storage and mobile
> video has created a challenge for both infrastructure and end-user
> equipment developers. How can they quickly increase system bandwidth
> while staying within strict power and cost budgets? Altera has
> developed its latest innovations to solve these challenges.
>
> The new Embedded HardCopy Blocks are customizable hard intellectual
> property (IP) blocks that leverage Altera's unique HardCopy ASIC
> capabilities. They are used to harden standard or logic-intensive
> functions such as interface protocols, application-specific functions,
> and proprietary custom IP. The Embedded HardCopy Blocks offer
customers
> faster time to market for their designs while also reducing cost and
> power. For Altera, this innovation allows the company to quickly
create
> variant products and target specific market segments.
>
> Partial reconfiguration allows designers to reconfigure part of the
> FPGA while other sections remain running. This is extremely important
> in systems where uptime is critical because it allows designers to
make
> updates or adjust functionality without disrupting services. Lowering
> power and cost, partial reconfiguration also improves effective logic
> density by removing the necessity to place in the FPGA functions that
> do not operate simultaneously. Instead, these functions can be stored
> in external memory and loaded as needed. This reduces the size of the
> FPGA by allowing multiple applications on a single FPGA, saving board
> space and reducing power.
>
> To date, partial reconfiguration solutions have been time-intensive
> tasks that required designers to know all of the intricate FPGA
> architecture details. Altera is simplifying the partial
reconfiguration
> process by building the capability on top of the proven incremental
> compile design flow in its Quartus(r) II design software.
>
> Extending its leadership in embedded transceiver technology, Altera
has
> developed 28-Gbps embedded transceivers, which will also be
implemented
> in upcoming 28-nm FPGAs. These high-speed transceivers will enable
> customers to implement next-generation designs such as 400G systems on
> a single chip without the need for costly external components.
>
> "Two years ago, Altera introduced the industry's first 40-nm FPGAs,
and
> continued delivering industry firsts such as embedded 11.3-Gbps
> transceivers," said John Daane, president, chairman and CEO of Altera.
> "As we move to the next process node, these new innovations from
Altera
> will take the industry beyond the benefits of Moore's Law to solve
> bandwidth challenges while staying within cost and power
requirements."
>
> About Altera
>
> Altera programmable solutions enable system and semiconductor
companies
> to rapidly and cost-effectively innovate, differentiate and win in
> their markets. Find out more about Altera's FPGA, CPLD and ASIC
devices
> at www.altera.com. Follow Altera via Facebook, RSS and Twitter.
>
> Altera, the Altera logo, and all other words that are identified as
> trademarks are, unless noted otherwise, Registered, U.S. Patent and
> Trademark Office, and the trademarks of Altera Corporation in the U.S.
> and other countries. All other product or service names are the
> property of their respective holders.
>
> This contains a forward-looking statement regarding the incorporation
> of new innovations into upcoming 28 nm FPGAs that is made pursuant to
> the safe harbor provisions of the Private Securities Litigation Reform
> Act of 1995. Investors are cautioned that all forward-looking
> statements involve risks and uncertainty, including without limitation
> the risk that future performance is dependent on product development
> schedules, the design performance of software and other tools, as well
> as the company's and third parties' development technology and
> manufacture capabilities. Please refer to the company's Securities and
> Exchange Commission filings, copies of which are available from the
> company without charge.
>
>
>
> Confidentiality Notice.
> This message may contain information that is confidential or otherwise
> protected from disclosure. If you are not the intended recipient, you
> are hereby notified that any use, disclosure, dissemination,
> distribution, or copying of this message, or any attachments, is
> strictly prohibited. If you have received this message in error,
> please advise the sender by reply e-mail, and delete the message and
> any attachments. Thank you.
>
> ------------------------------------------------------------------
> To unsubscribe from si-list:
> si-list-request (AT) freelists (DOT) org with 'unsubscribe' in the Subject field
>
> or to administer your membership from a web page, go to:
> http://www.freelists.org/webpage/si-list
>
> For help:
> si-list-request (AT) freelists (DOT) org with 'help' in the Subject field
>
>
> List technical documents are available at:
> http://www.si-list.net
>
> List archives are viewable at:
> http://www.freelists.org/archives/si-list
>
> Old (prior to June 6, 2001) list archives are viewable at:
> http://www.qsl.net/wb6tpu
>
>
This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately..
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request (AT) freelists (DOT) org with 'unsubscribe' in the Subject field
[SI-LIST] Re: Altera Unveils Innovations for 28-nm/28 Gbps FPGAs
Chris,
I suspect I'm not the only one who finds this type of response
completely lacking in value and somewhat unprofessional. You are
certainly entitled to an opinion as to whether press releases belong on
SI-list (I happen to think they don't!!), but the Altera posting does
at least contain information of interest to some members of the SI
community.
If you feel strongly enough to express opposition in a public forum of
your peers, I'd respectively suggest that a more constructive approach
would reflect better on both yourself and Infineon.
-----Original Message-----
From: si-list-bounce (AT) freelists (DOT) org [mailto:si-list-bounce (AT) freelists (DOT) org]
On Behalf Of Christopher.Jakubiec (AT) infineon (DOT) com
Sent: Monday, February 08, 2010 11:51 AM
To: mpli (AT) altera (DOT) com; si-list (AT) freelists (DOT) org
Subject: [SI-LIST] Re: Altera Unveils Innovations for 28-nm/28 Gbps
FPGAs
So, what is your question?
Chris
Infineon
-----Original Message-----
From: si-list-bounce (AT) freelists (DOT) org [mailto:si-list-bounce (AT) freelists (DOT) org]
On Behalf Of Mike Peng Li
Sent: Monday, February 08, 2010 2:34 PM
To: si-list (AT) freelists (DOT) org
Subject: [SI-LIST] FYI: Altera Unveils Innovations for 28-nm/28 Gbps
FPGAs
Altera Unveils Innovations for 28-nm FPGAs
Press Release Source: Altera Corporation On Monday February 1, 2010,
12:00 pm EST
SAN JOSE, Calif.--(BUSINESS WIRE)--Building on its history of technology
leadership, Altera Corporation (NASDAQ:ALTR - News) announced today new
innovations that will be incorporated into upcoming 28-nm FPGAs.
Embedded HardCopy(r) Blocks, a new method for partial reconfiguration
and embedded 28-Gbps transceivers will dramatically improve the density
and I/O performance of next-generation Altera(r) FPGAs and further
strengthen their competitive position versus ASICs and ASSPs.
The rapid growth of bandwidth-intensive applications such as
high-definition (HD) video, cloud computing, online data storage and
mobile video has created a challenge for both infrastructure and
end-user equipment developers. How can they quickly increase system
bandwidth while staying within strict power and cost budgets? Altera has
developed its latest innovations to solve these challenges.
The new Embedded HardCopy Blocks are customizable hard intellectual
property (IP) blocks that leverage Altera's unique HardCopy ASIC
capabilities. They are used to harden standard or logic-intensive
functions such as interface protocols, application-specific functions,
and proprietary custom IP. The Embedded HardCopy Blocks offer customers
faster time to market for their designs while also reducing cost and
power. For Altera, this innovation allows the company to quickly create
variant products and target specific market segments.
Partial reconfiguration allows designers to reconfigure part of the FPGA
while other sections remain running. This is extremely important in
systems where uptime is critical because it allows designers to make
updates or adjust functionality without disrupting services. Lowering
power and cost, partial reconfiguration also improves effective logic
density by removing the necessity to place in the FPGA functions that do
not operate simultaneously. Instead, these functions can be stored in
external memory and loaded as needed. This reduces the size of the FPGA
by allowing multiple applications on a single FPGA, saving board space
and reducing power.
To date, partial reconfiguration solutions have been time-intensive
tasks that required designers to know all of the intricate FPGA
architecture details. Altera is simplifying the partial reconfiguration
process by building the capability on top of the proven incremental
compile design flow in its Quartus(r) II design software.
Extending its leadership in embedded transceiver technology, Altera has
developed 28-Gbps embedded transceivers, which will also be implemented
in upcoming 28-nm FPGAs. These high-speed transceivers will enable
customers to implement next-generation designs such as 400G systems on a
single chip without the need for costly external components.
"Two years ago, Altera introduced the industry's first 40-nm FPGAs, and
continued delivering industry firsts such as embedded 11.3-Gbps
transceivers," said John Daane, president, chairman and CEO of Altera.
"As we move to the next process node, these new innovations from Altera
will take the industry beyond the benefits of Moore's Law to solve
bandwidth challenges while staying within cost and power requirements."
About Altera
Altera programmable solutions enable system and semiconductor companies
to rapidly and cost-effectively innovate, differentiate and win in their
markets. Find out more about Altera's FPGA, CPLD and ASIC devices at www.altera.com. Follow Altera via Facebook, RSS and Twitter.
Altera, the Altera logo, and all other words that are identified as
trademarks are, unless noted otherwise, Registered, U.S. Patent and
Trademark Office, and the trademarks of Altera Corporation in the U.S.
and other countries. All other product or service names are the property
of their respective holders.
This contains a forward-looking statement regarding the incorporation of
new innovations into upcoming 28 nm FPGAs that is made pursuant to the
safe harbor provisions of the Private Securities Litigation Reform Act
of 1995. Investors are cautioned that all forward-looking statements
involve risks and uncertainty, including without limitation the risk
that future performance is dependent on product development schedules,
the design performance of software and other tools, as well as the
company's and third parties' development technology and manufacture
capabilities. Please refer to the company's Securities and Exchange
Commission filings, copies of which are available from the company
without charge.
Confidentiality Notice.
This message may contain information that is confidential or otherwise
protected from disclosure. If you are not the intended recipient, you
are hereby notified that any use, disclosure, dissemination,
distribution, or copying of this message, or any attachments, is
strictly prohibited. If you have received this message in error, please
advise the sender by reply e-mail, and delete the message and any
attachments. Thank you.
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request (AT) freelists (DOT) org with 'unsubscribe' in the Subject field
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request (AT) freelists (DOT) org with 'unsubscribe' in the Subject field
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request (AT) freelists (DOT) org with 'unsubscribe' in the Subject field
[SI-LIST] Re: Correction: Re: IBIS-AMI Vendor Support Help
Hi Todd,
Pls correct me if I am wrong. I believe a RX Analog front end is needed
(Along with a TX Analog IO model) for the Impulse response of the
Channel. So how is that possible in the tool kit without a RX model.
Tks
Syed
-----Original Message-----
From: Todd Westerhoff [mailto:twesterh (AT) sisoft (DOT) com]
Sent: Monday, February 08, 2010 12:13 PM
To: Syed Huq (huqs)
Cc: si-list (AT) freelists (DOT) org
Subject: Re: [SI-LIST] Correction: Re: IBIS-AMI Vendor Support Help
Syed,
The base receiver model SiSoft uses includes a peaking filter, Decision
Feedback Equalizer and full clock recovery loop. This represents a
substantial development effort and isn't something that we're able to
publish. Having a simpler receiver model that we can publish is
something that we can consider that for a future addition to the
toolkit.
I understood the task at hand to be providing a method to determine
whether a given simulator could utilize a standard IBIS-AMI model (.ibs,
..ami, .dll). I believe the reference model in the current toolkit can
be used to accomplish that task.
Thanks,
Todd.
Todd Westerhoff
VP, Software Products
SiSoft
6 Clock Tower Place, Suite 250
Maynard, MA 01754
(978) 461-0449 x24
twesterh (AT) sisoft (DOT) com www.sisoft.com
Syed Huq (huqs) wrote:
> Todd,
> The referenced link only has a sisoft_tx.ibs file. Where is the
Receiver
> model ?
>
> Tks
> Syed
>
> -----Original Message-----
> From: si-list-bounce (AT) freelists (DOT) org
[mailto:si-list-bounce (AT) freelists (DOT) org]
> On Behalf Of Todd Westerhoff
> Sent: Monday, February 08, 2010 11:16 AM
> To: si-list (AT) freelists (DOT) org
> Subject: [SI-LIST] Correction: Re: IBIS-AMI Vendor Support Help
>
> All,
>
> The URL I posted this morning for the IBIS-AMI simulation toolkit and
> IBIS-AMI reference models was incorrect. The correct link is:
>
> http://www.sisoft.com/elearning_ibis-ami.asp
>
> The links to the IBIS-AMI Toolkit and reference model can be found at
> the bottom of the page. I apologize for any confusion.
>
> Todd.
>
> Todd Westerhoff
> VP, Software Products
> SiSoft
> 6 Clock Tower Place, Suite 250
> Maynard, MA 01754
> (978) 461-0449 x24
> twesterh (AT) sisoft (DOT) com
> www.sisoft.com
>
>
>
> ------------------------------------------------------------------
> To unsubscribe from si-list:
> si-list-request (AT) freelists (DOT) org with 'unsubscribe' in the Subject field
>
> or to administer your membership from a web page, go to:
> http://www.freelists.org/webpage/si-list
>
> For help:
> si-list-request (AT) freelists (DOT) org with 'help' in the Subject field
>
>
> List technical documents are available at:
> http://www.si-list.net
>
> List archives are viewable at:
> http://www.freelists.org/archives/si-list
>
> Old (prior to June 6, 2001) list archives are viewable at:
> http://www.qsl.net/wb6tpu
>
>
>
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request (AT) freelists (DOT) org with 'unsubscribe' in the Subject field
I would like to add a few more items to your list on why (and
how) some AMI models are non-compliant.
I don't know if I can mention the company name openly, but there
are some released AMI DLL-s which use a certain parameter format
that is not AMI spec compliant. The answer I was given when I
questioned this was that these models existed before the AMI spec
was finished, and it would be too much work for the IC vendor to
rewrite their models to obey the AMI syntax. I understand that
Walter's proposed AMI BIRD contains changes that will make these
models compliant, but for the time being they will only work with
tools which are willing to support them out-of-spec.
While I agree with your discussion about S-parameters, I would
like to mention that I have seen non-compliant .ibs files in
which there were no S-parameter references and many of the
non-compliant features could have been described by simple,
existing IBIS syntax. Also, I have seen files which do not
pass the parser because they contain obvious spec violations,
such as not having a number in the typical column of various
items, or omitting required keywords and/or subparameters,
or even because of the incorrect spelling of the OS under
the brand new [Algorithmic Model] keyword.
One could call these problems accidental mistakes or typos, but
that's what we have a parser for, right?
-----Original Message-----
From: si-list-bounce (AT) freelists (DOT) org [mailto:si-list-bounce (AT) freelists (DOT) org]
On Behalf Of Todd Westerhoff
Sent: Monday, February 08, 2010 9:25 AM
To: Eric Monteiro
Cc: si-list (AT) freelists (DOT) org
Subject: [SI-LIST] Re: IBIS-AMI Vendor Support Help
All,
....
....
Why would a model ever be non-compliant? There are two main reasons.
The first (and possibly the issue
Eric was raising) is that the simulator vendor may not fully support the
standard. The .ami file is a "control file"
that tells the simulator how to load and execute the .dll, and what
model configuration options are available.
From what I've seen, some vendors don't support this fully, and require
a tool-specific model control file instead.
It's usually the same information in a different format, but it does
require that the user understand the details of
a proprietary modeling format.
The second reason a model might be non-compliant is that is uses
extensions to IBIS-AMI that haven't been
accepted as part of the standard yet. A good example of this is the use
of S-parameter data in place of the
analog model. The 5.0 IBIS spec doesn't readily lend itself to
describing the broadband behavior of analog I/O.
IBM, Cisco and SiSoft proposed a method for dealing with this in
February 2009:
Although the exact syntax for this capability is still in discussion,
there *ARE* models out there that use this
syntax, or something very similar. There are a number of semiconductor
vendors that use S-parameter
data to characterize the analog aspects of their I/O, and there's no
good reason, in my opinion, to compromise
model accuracy because we haven't settled on the final syntax for the
standard. The consequence of this
is that the S-parameter data gets included in a slightly different
fashion between tools, but the purpose
and the S-parameter data are the same. Claiming that a model "isn't
compliant!" and "doesn't work out of the
box!" may make for a good sound bite, but this isn't rocket science,
especially since the proposed method
and syntax have been documented publicly.
....
....
I'm sure the discussion will continue, so I'm going to leave off here
for now.
Todd.
Todd Westerhoff
VP, Software Products
SiSoft
6 Clock Tower Place, Suite 250
Maynard, MA 01754
(978) 461-0449 x24
twesterh (AT) sisoft (DOT) com www.sisoft.com
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request (AT) freelists (DOT) org with 'unsubscribe' in the Subject field
What will be your advice to companies who are ramping up on AMI? Should
they include some non-AMI syntax for package modeling assuming that IBIS
AMI standard will support these keywords in near future or provide these
package model as a separate Touchstone file which can be integrated
within simulation environment?
Best regards
Sanjeev
-----Original Message-----
From: si-list-bounce (AT) freelists (DOT) org [mailto:si-list-bounce (AT) freelists (DOT) org]
On Behalf Of Muranyi, Arpad
Sent: Monday, February 08, 2010 3:06 PM
To: si-list (AT) freelists (DOT) org
Subject: [SI-LIST] Re: IBIS-AMI Vendor Support Help
Todd,
I would like to add a few more items to your list on why (and
how) some AMI models are non-compliant.
I don't know if I can mention the company name openly, but there
are some released AMI DLL-s which use a certain parameter format
that is not AMI spec compliant. The answer I was given when I
questioned this was that these models existed before the AMI spec
was finished, and it would be too much work for the IC vendor to
rewrite their models to obey the AMI syntax. I understand that
Walter's proposed AMI BIRD contains changes that will make these
models compliant, but for the time being they will only work with
tools which are willing to support them out-of-spec.
While I agree with your discussion about S-parameters, I would
like to mention that I have seen non-compliant .ibs files in
which there were no S-parameter references and many of the
non-compliant features could have been described by simple,
existing IBIS syntax. Also, I have seen files which do not
pass the parser because they contain obvious spec violations,
such as not having a number in the typical column of various
items, or omitting required keywords and/or subparameters,
or even because of the incorrect spelling of the OS under
the brand new [Algorithmic Model] keyword.
One could call these problems accidental mistakes or typos, but
that's what we have a parser for, right?
-----Original Message-----
From: si-list-bounce (AT) freelists (DOT) org [mailto:si-list-bounce (AT) freelists (DOT) org]
On Behalf Of Todd Westerhoff
Sent: Monday, February 08, 2010 9:25 AM
To: Eric Monteiro
Cc: si-list (AT) freelists (DOT) org
Subject: [SI-LIST] Re: IBIS-AMI Vendor Support Help
All,
....
....
Why would a model ever be non-compliant? There are two main reasons.
The first (and possibly the issue
Eric was raising) is that the simulator vendor may not fully support the
standard. The .ami file is a "control file"
that tells the simulator how to load and execute the .dll, and what
model configuration options are available.
From what I've seen, some vendors don't support this fully, and require
a tool-specific model control file instead.
It's usually the same information in a different format, but it does
require that the user understand the details of
a proprietary modeling format.
The second reason a model might be non-compliant is that is uses
extensions to IBIS-AMI that haven't been
accepted as part of the standard yet. A good example of this is the use
of S-parameter data in place of the
analog model. The 5.0 IBIS spec doesn't readily lend itself to
describing the broadband behavior of analog I/O.
IBM, Cisco and SiSoft proposed a method for dealing with this in
February 2009:
Although the exact syntax for this capability is still in discussion,
there *ARE* models out there that use this
syntax, or something very similar. There are a number of semiconductor
vendors that use S-parameter
data to characterize the analog aspects of their I/O, and there's no
good reason, in my opinion, to compromise
model accuracy because we haven't settled on the final syntax for the
standard. The consequence of this
is that the S-parameter data gets included in a slightly different
fashion between tools, but the purpose
and the S-parameter data are the same. Claiming that a model "isn't
compliant!" and "doesn't work out of the
box!" may make for a good sound bite, but this isn't rocket science,
especially since the proposed method
and syntax have been documented publicly.
....
....
I'm sure the discussion will continue, so I'm going to leave off here
for now.
Todd.
Todd Westerhoff
VP, Software Products
SiSoft
6 Clock Tower Place, Suite 250
Maynard, MA 01754
(978) 461-0449 x24
twesterh (AT) sisoft (DOT) com www.sisoft.com
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request (AT) freelists (DOT) org with 'unsubscribe' in the Subject field
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request (AT) freelists (DOT) org with 'unsubscribe' in the Subject field
Zero out the package related stuff in the .ibs file to
basically turn package modeling off in it.
Provide an S-parameter package file separately the same
way as the channel's S-parameter file would be distributed.
This could be documented in the .ibs file behind comments.
The customer will use whatever method to include this in
their favorite EDA tool.
If there is a need for on-die interconnect parasitic modeling,
it could be done the same way as the package model described
in the previous paragraph. The two might even be combined into
a single S-parameter file if that is more convenient or practical.
I would NOT provide a speculated IBIS syntax or any tool
specific syntax in the .ibs file for anything, unless a
clear and unambiguous description is given, so that another
EDA vendor could reproduce the same results with their products.
For the rest of the buffer description I would encourage
everyone to use existing IBIS constructs as far as possible.
And again, if certain features cannot be described that way,
I would encourage everyone to provide a detailed description
for what needs to be modeled so that anyone could make their
own model implementations using their favorite EDA tools
based on that description.
-----Original Message-----
From: sanjeev_gupta (AT) agilent (DOT) com [mailto:sanjeev_gupta (AT) agilent (DOT) com]
Sent: Monday, February 08, 2010 5:29 PM
To: Muranyi, Arpad; si-list (AT) freelists (DOT) org
Cc: sanjeev_gupta (AT) agilent (DOT) com
Subject: RE: [SI-LIST] Re: IBIS-AMI Vendor Support Help
Hello Arpad,
What will be your advice to companies who are ramping up on AMI? Should
they include some non-AMI syntax for package modeling assuming that IBIS
AMI standard will support these keywords in near future or provide these
package model as a separate Touchstone file which can be integrated
within simulation environment?
Best regards
Sanjeev
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request (AT) freelists (DOT) org with 'unsubscribe' in the Subject field
Moreover I think it will avoid uncertainty in AMI models if two EDA
tools provide good correlation.
Best regards and have a nice day
Sanjeev
-----Original Message-----
From: si-list-bounce (AT) freelists (DOT) org [mailto:si-list-bounce (AT) freelists (DOT) org]
On Behalf Of Muranyi, Arpad
Sent: Monday, February 08, 2010 3:49 PM
To: si-list (AT) freelists (DOT) org
Subject: [SI-LIST] Re: IBIS-AMI Vendor Support Help
Sanjeev,
I would recommend the following:
Zero out the package related stuff in the .ibs file to
basically turn package modeling off in it.
Provide an S-parameter package file separately the same
way as the channel's S-parameter file would be distributed.
This could be documented in the .ibs file behind comments.
The customer will use whatever method to include this in
their favorite EDA tool.
If there is a need for on-die interconnect parasitic modeling,
it could be done the same way as the package model described
in the previous paragraph. The two might even be combined into
a single S-parameter file if that is more convenient or practical.
I would NOT provide a speculated IBIS syntax or any tool
specific syntax in the .ibs file for anything, unless a
clear and unambiguous description is given, so that another
EDA vendor could reproduce the same results with their products.
For the rest of the buffer description I would encourage
everyone to use existing IBIS constructs as far as possible.
And again, if certain features cannot be described that way,
I would encourage everyone to provide a detailed description
for what needs to be modeled so that anyone could make their
own model implementations using their favorite EDA tools
based on that description.
-----Original Message-----
From: sanjeev_gupta (AT) agilent (DOT) com [mailto:sanjeev_gupta (AT) agilent (DOT) com]
Sent: Monday, February 08, 2010 5:29 PM
To: Muranyi, Arpad; si-list (AT) freelists (DOT) org
Cc: sanjeev_gupta (AT) agilent (DOT) com
Subject: RE: [SI-LIST] Re: IBIS-AMI Vendor Support Help
Hello Arpad,
What will be your advice to companies who are ramping up on AMI? Should
they include some non-AMI syntax for package modeling assuming that IBIS
AMI standard will support these keywords in near future or provide these
package model as a separate Touchstone file which can be integrated
within simulation environment?
Best regards
Sanjeev
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request (AT) freelists (DOT) org with 'unsubscribe' in the Subject field
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request (AT) freelists (DOT) org with 'unsubscribe' in the Subject field
I agree. In fact, I think it would be a wonderful thing if multiple EDA
tools utilizing IBIS-AMI models were able to show correlation to
physical measurements of a complex reference channel with multiple
identifiable defects, and sources of noise. Cross-correlation of that
channel to jitter and BER estimation related measurement instrumentation
would also be a big plus.
regards,
Scott
sanjeev_gupta (AT) agilent (DOT) com wrote:
> Hello Arpad,
>
> Thank you for your reply!
>
> Moreover I think it will avoid uncertainty in AMI models if two EDA
> tools provide good correlation.
>
> Best regards and have a nice day
> Sanjeev
>
> -----Original Message-----
> From: si-list-bounce (AT) freelists (DOT) org [mailto:si-list-bounce (AT) freelists (DOT) org]
> On Behalf Of Muranyi, Arpad
> Sent: Monday, February 08, 2010 3:49 PM
> To: si-list (AT) freelists (DOT) org
> Subject: [SI-LIST] Re: IBIS-AMI Vendor Support Help
>
> Sanjeev,
>
> I would recommend the following:
>
> Zero out the package related stuff in the .ibs file to
> basically turn package modeling off in it.
>
> Provide an S-parameter package file separately the same
> way as the channel's S-parameter file would be distributed.
> This could be documented in the .ibs file behind comments.
> The customer will use whatever method to include this in
> their favorite EDA tool.
>
> If there is a need for on-die interconnect parasitic modeling,
> it could be done the same way as the package model described
> in the previous paragraph. The two might even be combined into
> a single S-parameter file if that is more convenient or practical.
>
> I would NOT provide a speculated IBIS syntax or any tool
> specific syntax in the .ibs file for anything, unless a
> clear and unambiguous description is given, so that another
> EDA vendor could reproduce the same results with their products.
>
> For the rest of the buffer description I would encourage
> everyone to use existing IBIS constructs as far as possible.
> And again, if certain features cannot be described that way,
> I would encourage everyone to provide a detailed description
> for what needs to be modeled so that anyone could make their
> own model implementations using their favorite EDA tools
> based on that description.
>
> Thanks for asking the question.
>
> Arpad
> ================================================== ==============
>
>
> -----Original Message-----
> From: sanjeev_gupta (AT) agilent (DOT) com [mailto:sanjeev_gupta (AT) agilent (DOT) com]
> Sent: Monday, February 08, 2010 5:29 PM
> To: Muranyi, Arpad; si-list (AT) freelists (DOT) org
> Cc: sanjeev_gupta (AT) agilent (DOT) com
> Subject: RE: [SI-LIST] Re: IBIS-AMI Vendor Support Help
>
> Hello Arpad,
>
> What will be your advice to companies who are ramping up on AMI? Should
> they include some non-AMI syntax for package modeling assuming that IBIS
> AMI standard will support these keywords in near future or provide these
> package model as a separate Touchstone file which can be integrated
> within simulation environment?
>
> Best regards
> Sanjeev
> ------------------------------------------------------------------
> To unsubscribe from si-list:
> si-list-request (AT) freelists (DOT) org with 'unsubscribe' in the Subject field
>
> or to administer your membership from a web page, go to:
> http://www.freelists.org/webpage/si-list
>
> For help:
> si-list-request (AT) freelists (DOT) org with 'help' in the Subject field
>
>
> List technical documents are available at:
> http://www.si-list.net
>
> List archives are viewable at:
> http://www.freelists.org/archives/si-list
>
> Old (prior to June 6, 2001) list archives are viewable at:
> http://www.qsl.net/wb6tpu
>
>
>
>
> ------------------------------------------------------------------
> To unsubscribe from si-list:
> si-list-request (AT) freelists (DOT) org with 'unsubscribe' in the Subject field
>
> or to administer your membership from a web page, go to:
> http://www.freelists.org/webpage/si-list
>
> For help:
> si-list-request (AT) freelists (DOT) org with 'help' in the Subject field
>
>
> List technical documents are available at:
> http://www.si-list.net
>
> List archives are viewable at:
> http://www.freelists.org/archives/si-list
>
> Old (prior to June 6, 2001) list archives are viewable at:
> http://www.qsl.net/wb6tpu
>
>
>
>
--
Scott McMorrow
Teraspeed Consulting Group LLC
121 North River Drive
Narragansett, RI 02882
(401) 284-1827 Business
(401) 284-1840 Fax
Teraspeed® is the registered service mark of
Teraspeed Consulting Group LLC
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request (AT) freelists (DOT) org with 'unsubscribe' in the Subject field
1) I think there's a balance between adapting models to fit the current
standard and extending the standard to improve the way we utilize vendor
data. One of the goals we had for IBIS-AMI was to utilize model data
vendors already have, S-parameter characterizations of on-die behavior
being the obvious case. This should legitimately be considered part of
the device model and IBIS-AMI should accommodate it as such. Telling
people to include on-die S-parameters as part of the channel may comply
with the current spec, but I don't think that's the way semiconductor
vendors or users want to manage that data ... it just creates more
opportunity for error.
2) A clear and unambiguous definition of on-die S-parameter syntax was
presented at the Feb 2009 IBIS Summit, for exactly the reasons you
mentioned.
Thanks,
Todd.
Todd Westerhoff
VP, Software Products
SiSoft
6 Clock Tower Place, Suite 250
Maynard, MA 01754
(978) 461-0449 x24
twesterh (AT) sisoft (DOT) com www.sisoft.com
Muranyi, Arpad wrote:
> Sanjeev,
>
> I would recommend the following:
>
> Zero out the package related stuff in the .ibs file to
> basically turn package modeling off in it.
>
> Provide an S-parameter package file separately the same
> way as the channel's S-parameter file would be distributed.
> This could be documented in the .ibs file behind comments.
> The customer will use whatever method to include this in
> their favorite EDA tool.
>
> If there is a need for on-die interconnect parasitic modeling,
> it could be done the same way as the package model described
> in the previous paragraph. The two might even be combined into
> a single S-parameter file if that is more convenient or practical.
>
> I would NOT provide a speculated IBIS syntax or any tool
> specific syntax in the .ibs file for anything, unless a
> clear and unambiguous description is given, so that another
> EDA vendor could reproduce the same results with their products.
>
> For the rest of the buffer description I would encourage
> everyone to use existing IBIS constructs as far as possible.
> And again, if certain features cannot be described that way,
> I would encourage everyone to provide a detailed description
> for what needs to be modeled so that anyone could make their
> own model implementations using their favorite EDA tools
> based on that description.
>
> Thanks for asking the question.
>
> Arpad
> ================================================== ==============
>
>
> -----Original Message-----
> From: sanjeev_gupta (AT) agilent (DOT) com [mailto:sanjeev_gupta (AT) agilent (DOT) com]
> Sent: Monday, February 08, 2010 5:29 PM
> To: Muranyi, Arpad; si-list (AT) freelists (DOT) org
> Cc: sanjeev_gupta (AT) agilent (DOT) com
> Subject: RE: [SI-LIST] Re: IBIS-AMI Vendor Support Help
>
> Hello Arpad,
>
> What will be your advice to companies who are ramping up on AMI? Should
> they include some non-AMI syntax for package modeling assuming that IBIS
> AMI standard will support these keywords in near future or provide these
> package model as a separate Touchstone file which can be integrated
> within simulation environment?
>
> Best regards
> Sanjeev
> ------------------------------------------------------------------
> To unsubscribe from si-list:
> si-list-request (AT) freelists (DOT) org with 'unsubscribe' in the Subject field
>
> or to administer your membership from a web page, go to:
> http://www.freelists.org/webpage/si-list
>
> For help:
> si-list-request (AT) freelists (DOT) org with 'help' in the Subject field
>
>
> List technical documents are available at:
> http://www.si-list.net
>
> List archives are viewable at:
> http://www.freelists.org/archives/si-list
>
> Old (prior to June 6, 2001) list archives are viewable at:
> http://www.qsl.net/wb6tpu
>
>
>
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request (AT) freelists (DOT) org with 'unsubscribe' in the Subject field
1) I didn't tell people "to include on-die S-parameters as part of the
channel",
I only mentioned that the on-die S-parameters could optionally be
combined with
the ***PACKAGE*** S-parameters "if that is more convenient or
practical". In
other words, I was not saying that this was the (only) way to go, I only
suggested
that as an option.
2) I would actually challenge you on your statement that the
presentation you
reference has "A clear and unambiguous definition of on-die S-parameter
syntax",
because I don't think anyone could sit down and write a working
simulation
netlist based on the "schematics" shown on pg. 7, 8, 10 in that
presentation: http://www.vhdl.org/pub/ibis/summits/feb09/hawes.pdf
This is exactly the problem I am talking about. If someone writes a
..ibs file
with unexplained syntax or a presentation that is not precise enough to
know
how to build a simulation netlist, it creates confusion. Everyone can
read
something of their own interpretation into it, and your mileage and
results
may vary. This is why I suggested that while we are in this situation
with
the lacking .ibs capabilities, anyone using a non standard syntax should
also provide a clear and unambiguous explanation along with it so that
everyone
else reading it could still make a simulation netlist for it.
If the first two primary goals of IBIS-AMI is interoperability and
transportability,
this shouldn't be too much to ask for...
-----Original Message-----
From: Todd Westerhoff [mailto:twesterh (AT) sisoft (DOT) com]
Sent: Tuesday, February 09, 2010 8:29 AM
To: Muranyi, Arpad
Cc: si-list (AT) freelists (DOT) org
Subject: Re: [SI-LIST] Re: IBIS-AMI Vendor Support Help
Arpad,
Two points worthy of note:
1) I think there's a balance between adapting models to fit the current
standard and extending the standard to improve the way we utilize vendor
data. One of the goals we had for IBIS-AMI was to utilize model data
vendors already have, S-parameter characterizations of on-die behavior
being the obvious case. This should legitimately be considered part of
the device model and IBIS-AMI should accommodate it as such. Telling
people to include on-die S-parameters as part of the channel may comply
with the current spec, but I don't think that's the way semiconductor
vendors or users want to manage that data ... it just creates more
opportunity for error.
2) A clear and unambiguous definition of on-die S-parameter syntax was
presented at the Feb 2009 IBIS Summit, for exactly the reasons you
mentioned.
Thanks,
Todd.
Todd Westerhoff
VP, Software Products
SiSoft
6 Clock Tower Place, Suite 250
Maynard, MA 01754
(978) 461-0449 x24
twesterh (AT) sisoft (DOT) com www.sisoft.com
Muranyi, Arpad wrote:
> Sanjeev,
>
> I would recommend the following:
>
> Zero out the package related stuff in the .ibs file to
> basically turn package modeling off in it.
>
> Provide an S-parameter package file separately the same
> way as the channel's S-parameter file would be distributed.
> This could be documented in the .ibs file behind comments.
> The customer will use whatever method to include this in
> their favorite EDA tool.
>
> If there is a need for on-die interconnect parasitic modeling,
> it could be done the same way as the package model described
> in the previous paragraph. The two might even be combined into
> a single S-parameter file if that is more convenient or practical.
>
> I would NOT provide a speculated IBIS syntax or any tool
> specific syntax in the .ibs file for anything, unless a
> clear and unambiguous description is given, so that another
> EDA vendor could reproduce the same results with their products.
>
> For the rest of the buffer description I would encourage
> everyone to use existing IBIS constructs as far as possible.
> And again, if certain features cannot be described that way,
> I would encourage everyone to provide a detailed description
> for what needs to be modeled so that anyone could make their
> own model implementations using their favorite EDA tools
> based on that description.
>
> Thanks for asking the question.
>
> Arpad
> ================================================== ==============
>
>
> -----Original Message-----
> From: sanjeev_gupta (AT) agilent (DOT) com [mailto:sanjeev_gupta (AT) agilent (DOT) com]
> Sent: Monday, February 08, 2010 5:29 PM
> To: Muranyi, Arpad; si-list (AT) freelists (DOT) org
> Cc: sanjeev_gupta (AT) agilent (DOT) com
> Subject: RE: [SI-LIST] Re: IBIS-AMI Vendor Support Help
>
> Hello Arpad,
>
> What will be your advice to companies who are ramping up on AMI?
Should
> they include some non-AMI syntax for package modeling assuming that
IBIS
> AMI standard will support these keywords in near future or provide
these
> package model as a separate Touchstone file which can be integrated
> within simulation environment?
>
> Best regards
> Sanjeev
> ------------------------------------------------------------------
> To unsubscribe from si-list:
> si-list-request (AT) freelists (DOT) org with 'unsubscribe' in the Subject field
>
> or to administer your membership from a web page, go to:
> http://www.freelists.org/webpage/si-list
>
> For help:
> si-list-request (AT) freelists (DOT) org with 'help' in the Subject field
>
>
> List technical documents are available at:
> http://www.si-list.net
>
> List archives are viewable at:
> http://www.freelists.org/archives/si-list
>
> Old (prior to June 6, 2001) list archives are viewable at:
> http://www.qsl.net/wb6tpu
>
>
>
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request (AT) freelists (DOT) org with 'unsubscribe' in the Subject field
[External Model] may not work because it is specifically designed to
replace the [Model] with a better modeling language content while
preserving the same connectivity of the [Model] keyword. This means
that the all of the nodes of [Model] or [External Model] are supposed
to be connected the same exact way, which would prevent us to put die
parasitics between the buffer model and the pads.
However, [External Circuit] does not have this restriction, so we
could potentially make use of that keyword for this purpose, perhaps
referencing the new (proposed) IBIS-ISS capabilities which allow
us to use S-parameters. If we went with this route, the question
is, can we have a [Model] behind the [External Circuit], which is
something I don't remember for sure now. I need to research the
spec on that a little more...
-----Original Message-----
From: Ken Willis [mailto:kwillis (AT) sigrity (DOT) com]
Sent: Tuesday, February 09, 2010 9:19 AM
To: 'Todd Westerhoff'; Muranyi, Arpad
Cc: si-list (AT) freelists (DOT) org
Subject: RE: [SI-LIST] Re: IBIS-AMI Vendor Support Help
Hi Todd,
On #1, it makes sense to incorporate S-parameters into IO models,
especially
since some major IP suppliers have this data today. I think the item
that
brings some uncertainty is why this would be pushed into the algorithmic
(AMI) portion of the model, especially if new syntax/API has to be
invented
and supported. The intent of AMI was to capture the adaptive filtering
behavior of these advanced Serdes devices, which you couldn't really
model
well in a circuit model. If the S-parameters are largely parasitic data,
it
seems more straightforward to include them in the analog circuit part of
the
model.
I understand that there is no standard "IBIS" syntax for S-params right
now,
but I would agree with Arpad that Touchstone is widely supported. Maybe
we
should be looking at [External Model] > Touchstone or something like
that.
But we can continue the discussion in the IBIS forum.
Thanks,
Ken Willis
Sigrity, Inc.
860-871-7070
kwillis (AT) sigrity (DOT) com
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request (AT) freelists (DOT) org with 'unsubscribe' in the Subject field
1) Sorry - am I missing something? I thought you recommended zeroing out
thepackage parasitics in the IBIS model and including the S-parameter data
for the package explicitly in the schematic (I agree with this method, given
the current limitations of IBIS package modeling). If the package data
becomes just one more set of passive cascaded S-parameters, how is the
simulator supposed to know which S-parameters represent the package and
whichrepresent boards or connectors? If we bundle the on-die S-params into
the package, and the package is effectively part of the channel, isn't that
the same as making the on-die S-parameters part of the channel?
I realize I'm debating semantics here and don't want to. The point I was
trying to make - we need to take all the data associated with the component
and make it part of the IBIS model. The problem at the moment is that the
modeling methods IBIS supports don't always give us the fidelity we need for
the analog and package models - so, let's improve them. This is a drum
SiSoft (and Walter in particular) has been banging for a long time.
2) Here's the thing - I look at slide 10 in http://www.vhdl.org/pub/ibis/summits/feb09/hawes.pdf[1] and it's clear to me
what the syntax is, and how the S-parameter data is being used. Of course,
I'm close to the issue and have that advantage. Making sure this is clear
toeveryone is exactly what the standardization process is all about.
The challenge here is moving the standard forward quickly and effectively..
Let's all work together and do that!
Muranyi, Arpad wrote: Todd, 1) I didn't tell people "to include on-die
S-parameters as part of the channel", I only mentioned that the on-die
S-parameters could optionally be combined with the ***PACKAGE***
S-parameters"if that is more convenient or practical". In other words, I was
not saying that this was the (only) way to go, I only suggested that as an
option. 2) I would actually challenge you on your statement that the
presentation you reference has "A clear and unambiguous definition of on-die
S-parameter syntax", because I don't think anyone could sit down and write a
working simulation netlist based on the "schematics" shown on pg. 7, 8, 10
inthat presentation: http://www.vhdl.org/pub/ibis/summits/feb09/hawes.pdf[4]
This is exactly the problem I am talking about. If someone writes a .ibs
filewith unexplained syntax or a presentation that is not precise enough to
know how to build a simulation netlist, it creates confusion. Everyone can
read something of their own interpretation into it, and your mileage and
results may vary. This is why I suggested that while we are in this
situationwith the lacking .ibs capabilities, anyone using a non standard
syntax should also provide a clear and unambiguous explanation along with it
so that everyone else reading it could still make a simulation netlist for
it. If the first two primary goals of IBIS-AMI is interoperability and
transportability, this shouldn't be too much to ask for... Arpad
================================================== ======================
============ -----Original Message----- From: Todd Westerhoff
[mailto:twesterh (AT) sisoft (DOT) com[5]] Sent: Tuesday, February 09, 2010 8:29 AM To:
Muranyi, Arpad Cc: si-list (AT) freelists (DOT) org[6] Subject: Re: [SI-LIST] Re:
IBIS-AMI Vendor Support Help Arpad, Two points worthy of note: 1) I think
there's a balance between adapting models to fit the current standard and
extending the standard to improve the way we utilize vendor data. One of the
goals we had for IBIS-AMI was to utilize model data vendors already have,
S-parameter characterizations of on-die behavior being the obvious case.
Thisshould legitimately be considered part of the device model and IBIS-AMI
should accommodate it as such. Telling people to include on-die S-parameters
as part of the channel may comply with the current spec, but I don't think
that's the way semiconductor vendors or users want to manage that data ....
itjust creates more opportunity for error. 2) A clear and unambiguous
definition of on-die S-parameter syntax was presented at the Feb 2009 IBIS
Summit, for exactly the reasons you mentioned. Thanks, Todd. Todd Westerhoff
VP, Software Products SiSoft 6 Clock Tower Place, Suite 250 Maynard, MA
01754(978) 461-0449 x24 twesterh (AT) sisoft (DOT) com[7] www.sisoft.com[8] Muranyi,
Arpad wrote: Sanjeev, I would recommend the following: Zero out the package
related stuff in the .ibs file to basically turn package modeling off in it.
Provide an S-parameter package file separately the same way as the channel's
S-parameter file would be distributed. This could be documented in the .ibs
file behind comments. The customer will use whatever method to include this
in their favorite EDA tool. If there is a need for on-die interconnect
parasitic modeling, it could be done the same way as the package model
described in the previous paragraph. The two might even be combined into a
single S-parameter file if that is more convenient or practical. I would NOT
provide a speculated IBIS syntax or any tool specific syntax in the .ibs
filefor anything, unless a clear and unambiguous description is given, so
that another EDA vendor could reproduce the same results with their
products.For the rest of the buffer description I would encourage everyone
touse existing IBIS constructs as far as possible. And again, if certain
features cannot be described that way, I would encourage everyone to provide
a detailed description for what needs to be modeled so that anyone could
maketheir own model implementations using their favorite EDA tools based on
that description. Thanks for asking the question. Arpad
================================================== ==============
-----Original Message----- From: sanjeev_gupta (AT) agilent (DOT) com[9]
[mailto:sanjeev_gupta (AT) agilent (DOT) com[10]] Sent: Monday, February 08, 2010 5:29
PM To: Muranyi, Arpad; si-list (AT) freelists (DOT) org[11] Cc:
sanjeev_gupta (AT) agilent (DOT) com[12] Subject: RE: [SI-LIST] Re: IBIS-AMI Vendor
Support Help Hello Arpad, What will be your advice to companies who are
ramping up on AMI? Should they include some non-AMI syntax for package
modeling assuming that IBIS AMI standard will support these keywords in near
future or provide these package model as a separate Touchstone file which
canbe integrated within simulation environment? Best regards Sanjeev
------------------------------------------------------------------ To
unsubscribe from si-list: si-list-request (AT) freelists (DOT) org[13] with
'unsubscribe' in the Subject field or to administer your membership from a
web page, go to: http://www.freelists.org/webpage/si-list[14] For help:
si-list-request (AT) freelists (DOT) org[15] with 'help' in the Subject field List
technical documents are available at: http://www.si-list.net[16] List
archives are viewable at: http://www.freelists.org/archives/si-list[17] Old
(prior to June 6, 2001) list archives are viewable at: http://www.qsl.net/wb6tpu[18]
------------------------------------------------------------------ To
unsubscribe from si-list: si-list-request (AT) freelists (DOT) org[19] with
'unsubscribe' in the Subject field or to administer your membership from a
web page, go to: http://www.freelists.org/webpage/si-list[20] For help:
si-list-request (AT) freelists (DOT) org[21] with 'help' in the Subject field List
technical documents are available at: http://www.si-list.net[22] List
archives are viewable at: http://www.freelists.org/archives/si-list[23] Old
(prior to June 6, 2001) list archives are viewable at: http://www.qsl.net/wb6tpu[24]
Actually the diagram is only clear for one differential 4-port path
without DC biasing networks or coupling to other circuits. How will a
standard handle these?
Scott
--
Scott McMorrow
Teraspeed Consulting Group LLC
121 North River Drive
Narragansett, RI 02882
(401) 284-1827 Business
(401) 284-1840 Fax
Teraspeed® is the registered service mark of
Teraspeed Consulting Group LLC
> 2) Here's the thing - I look at slide 10 in
> http://www.vhdl.org/pub/ibis/summits/feb09/hawes.pdf[1] and it's clear to me
> what the syntax is, and how the S-parameter data is being used. Of course,
> I'm close to the issue and have that advantage. Making sure this is clear
> toeveryone is exactly what the standardization process is all about.
>
>
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request (AT) freelists (DOT) org with 'unsubscribe' in the Subject field
1) I think this discussion is spiraling into a rat hole because of some
terminology differences. I don't think it is worth our time to go
deeper
into it... But to answer the questions you raise, yes, your summary of
my recommendation is correct. I suggested to take the package (and
possibly
the on-die interconnect) model(s) out of the .ibs file context and put
it
(them) into the schematic editor of the tool. I used the word "channel"
for anything that is between the package models of the Tx and Rx,
regardless
of where and how these package models are modeled. You seem to use the
same
word for anything that is in the schematic editor, regardless of what
they
represent. (I may add, someone else might use the word to describe
anything
that is between the Tx and Rx buffer models on the die). But I think
this
is all irrelevant. The point was that we were discussing the
limitations of
..ibs and I made a recommendation for how we could get around it while we
wait for .ibs to get improved. It sounds like you are in agreement with
that recommendation, so let's put this topic to rest...
You raise the question, how does the tool know which S-parameter block
is what. Does the simulator really have to know that?
2) Sorry, but that drawing on slide 10 drives me nuts. Why are there
two
voltage sources there back to back without anything connected to the
node that is between them? Is that node assumed to be GND? Is the
entire
circuit really floating as it is drawn? Etc...
From: Todd Westerhoff [mailto:twesterh (AT) sisoft (DOT) com]
Sent: Tuesday, February 09, 2010 10:10 AM
To: Muranyi, Arpad
Cc: si-list (AT) freelists (DOT) org
Subject: Re: [SI-LIST] Re: IBIS-AMI Vendor Support Help
Arpad,
1) Sorry - am I missing something? I thought you recommended zeroing
out the package parasitics in the IBIS model and including the
S-parameter data for the package explicitly in the schematic (I agree
with this method, given the current limitations of IBIS package
modeling). If the package data becomes just one more set of passive
cascaded S-parameters, how is the simulator supposed to know which
S-parameters represent the package and which represent boards or
connectors? If we bundle the on-die S-params into the package, and the
package is effectively part of the channel, isn't that the same as
making the on-die S-parameters part of the channel?
I realize I'm debating semantics here and don't want to. The point I
was trying to make - we need to take all the data associated with the
component and make it part of the IBIS model. The problem at the moment
is that the modeling methods IBIS supports don't always give us the
fidelity we need for the analog and package models - so, let's improve
them. This is a drum SiSoft (and Walter in particular) has been banging
for a long time.
and it's clear to me what the syntax is, and how the S-parameter data is
being used. Of course, I'm close to the issue and have that advantage.
Making sure this is clear to everyone is exactly what the
standardization process is all about.
The challenge here is moving the standard forward quickly and
effectively. Let's all work together and do that!
Todd.
Todd Westerhoff
VP, Software Products
SiSoft
6 Clock Tower Place, Suite 250
Maynard, MA 01754
(978) 461-0449 x24
twesterh (AT) sisoft (DOT) com www.sisoft.com
Muranyi, Arpad wrote:
Todd,
1) I didn't tell people "to include on-die S-parameters as part
of the
channel",
I only mentioned that the on-die S-parameters could optionally
be
combined with
the ***PACKAGE*** S-parameters "if that is more convenient or
practical". In
other words, I was not saying that this was the (only) way to
go, I only
suggested
that as an option.
2) I would actually challenge you on your statement that the
presentation you
reference has "A clear and unambiguous definition of on-die
S-parameter
syntax",
because I don't think anyone could sit down and write a working
simulation
netlist based on the "schematics" shown on pg. 7, 8, 10 in that
presentation: http://www.vhdl.org/pub/ibis/summits/feb09/hawes.pdf
This is exactly the problem I am talking about. If someone
writes a
.ibs file
with unexplained syntax or a presentation that is not precise
enough to
know
how to build a simulation netlist, it creates confusion.
Everyone can
read
something of their own interpretation into it, and your mileage
and
results
may vary. This is why I suggested that while we are in this
situation
with
the lacking .ibs capabilities, anyone using a non standard
syntax should
also provide a clear and unambiguous explanation along with it
so that
everyone
else reading it could still make a simulation netlist for it.
If the first two primary goals of IBIS-AMI is interoperability
and
transportability,
this shouldn't be too much to ask for...
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request (AT) freelists (DOT) org with 'unsubscribe' in the Subject field
I agree - let's take this one back into IBIS-ATM and get it sorted out.
Todd.
Todd Westerhoff
VP, Software Products
SiSoft
6 Clock Tower Place, Suite 250
Maynard, MA 01754
(978) 461-0449 x24
twesterh (AT) sisoft (DOT) com www.sisoft.com
Muranyi, Arpad wrote:
> Todd,
>
> 1) I think this discussion is spiraling into a rat hole because of some
> terminology differences. I don't think it is worth our time to go
> deeper
> into it... But to answer the questions you raise, yes, your summary of
> my recommendation is correct. I suggested to take the package (and
> possibly
> the on-die interconnect) model(s) out of the .ibs file context and put
> it
> (them) into the schematic editor of the tool. I used the word "channel"
> for anything that is between the package models of the Tx and Rx,
> regardless
> of where and how these package models are modeled. You seem to use the
> same
> word for anything that is in the schematic editor, regardless of what
> they
> represent. (I may add, someone else might use the word to describe
> anything
> that is between the Tx and Rx buffer models on the die). But I think
> this
> is all irrelevant. The point was that we were discussing the
> limitations of
> .ibs and I made a recommendation for how we could get around it while we
> wait for .ibs to get improved. It sounds like you are in agreement with
> that recommendation, so let's put this topic to rest...
>
> You raise the question, how does the tool know which S-parameter block
> is what. Does the simulator really have to know that?
>
> 2) Sorry, but that drawing on slide 10 drives me nuts. Why are there
> two
> voltage sources there back to back without anything connected to the
> node that is between them? Is that node assumed to be GND? Is the
> entire
> circuit really floating as it is drawn? Etc...
>
> Thanks,
>
> Arpad
> ================================================== ======================
> ===
>
>
>
> ________________________________
>
> From: Todd Westerhoff [mailto:twesterh (AT) sisoft (DOT) com]
> Sent: Tuesday, February 09, 2010 10:10 AM
> To: Muranyi, Arpad
> Cc: si-list (AT) freelists (DOT) org
> Subject: Re: [SI-LIST] Re: IBIS-AMI Vendor Support Help
>
>
> Arpad,
>
> 1) Sorry - am I missing something? I thought you recommended zeroing
> out the package parasitics in the IBIS model and including the
> S-parameter data for the package explicitly in the schematic (I agree
> with this method, given the current limitations of IBIS package
> modeling). If the package data becomes just one more set of passive
> cascaded S-parameters, how is the simulator supposed to know which
> S-parameters represent the package and which represent boards or
> connectors? If we bundle the on-die S-params into the package, and the
> package is effectively part of the channel, isn't that the same as
> making the on-die S-parameters part of the channel?
>
> I realize I'm debating semantics here and don't want to. The point I
> was trying to make - we need to take all the data associated with the
> component and make it part of the IBIS model. The problem at the moment
> is that the modeling methods IBIS supports don't always give us the
> fidelity we need for the analog and package models - so, let's improve
> them. This is a drum SiSoft (and Walter in particular) has been banging
> for a long time.
>
> 2) Here's the thing - I look at slide 10 in
>
> http://www.vhdl.org/pub/ibis/summits/feb09/hawes.pdf
>
> and it's clear to me what the syntax is, and how the S-parameter data is
> being used. Of course, I'm close to the issue and have that advantage.
> Making sure this is clear to everyone is exactly what the
> standardization process is all about.
>
> The challenge here is moving the standard forward quickly and
> effectively. Let's all work together and do that!
>
> Todd.
>
> Todd Westerhoff
> VP, Software Products
> SiSoft
> 6 Clock Tower Place, Suite 250
> Maynard, MA 01754
> (978) 461-0449 x24
> twesterh (AT) sisoft (DOT) com
> www.sisoft.com
>
>
> Muranyi, Arpad wrote:
>
> Todd,
>
> 1) I didn't tell people "to include on-die S-parameters as part
> of the
> channel",
> I only mentioned that the on-die S-parameters could optionally
> be
> combined with
> the ***PACKAGE*** S-parameters "if that is more convenient or
> practical". In
> other words, I was not saying that this was the (only) way to
> go, I only
> suggested
> that as an option.
>
> 2) I would actually challenge you on your statement that the
> presentation you
> reference has "A clear and unambiguous definition of on-die
> S-parameter
> syntax",
> because I don't think anyone could sit down and write a working
> simulation
> netlist based on the "schematics" shown on pg. 7, 8, 10 in that
> presentation:
> http://www.vhdl.org/pub/ibis/summits/feb09/hawes.pdf
>
> This is exactly the problem I am talking about. If someone
> writes a
> .ibs file
> with unexplained syntax or a presentation that is not precise
> enough to
> know
> how to build a simulation netlist, it creates confusion.
> Everyone can
> read
> something of their own interpretation into it, and your mileage
> and
> results
> may vary. This is why I suggested that while we are in this
> situation
> with
> the lacking .ibs capabilities, anyone using a non standard
> syntax should
> also provide a clear and unambiguous explanation along with it
> so that
> everyone
> else reading it could still make a simulation netlist for it.
>
> If the first two primary goals of IBIS-AMI is interoperability
> and
> transportability,
> this shouldn't be too much to ask for...
>
> Arpad
>
> ================================================== ======================
>
>
> ------------------------------------------------------------------
> To unsubscribe from si-list:
> si-list-request (AT) freelists (DOT) org with 'unsubscribe' in the Subject field
>
> or to administer your membership from a web page, go to:
> http://www.freelists.org/webpage/si-list
>
> For help:
> si-list-request (AT) freelists (DOT) org with 'help' in the Subject field
>
>
> List technical documents are available at:
> http://www.si-list.net
>
> List archives are viewable at:
> http://www.freelists.org/archives/si-list
>
> Old (prior to June 6, 2001) list archives are viewable at:
> http://www.qsl.net/wb6tpu
>
>
>
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request (AT) freelists (DOT) org with 'unsubscribe' in the Subject field