Every time I sit down to simulate a PCB, quickly download IBIS models and produce meaningful results in minutes, I am still amazed. I can’t help but think about how things used to be, back when all this wasn’t possible. Not only were simulators slow and cumbersome, component-level device models simply did not exist. True, there were a few transistor-level models around, but using them made simulation even more slow and cumbersome. There had to be a better way. After all, I’m designing a PCB not an IC.
Some SI old-timers call me “the father of IBIS”, and I suppose to some degree it is true. I’ll endeavor to tell the story here, in which you’ll learn about the people and forces that birthed IBIS. It has been more than 25 years since I held the first “IBIS Open Forum” meeting, and – thanks to the hard work of many engineers – today IBIS still stands as the dominant format for SI models. With dozens of member companies, meetings all over the planet, and a 7th Generation Specification, IBIS has remained relevant as operating frequencies have increased 3 orders of magnitude. Wow. How did that happen?
Necessity, the Mother of Invention
As the PC entered the 1990s it was time for a new I/O bus. ISA was too slow, EISA was unwieldy, and IC integration was rapidly increasing. Intel, quickly gaining clout to lead the definition the PC’s Architecture, envisioned a new standard in which low-power ASICs sat directly on the I/O bus operating at a sizzling data rate of 33 MHz. Gasp?! How could that be done?
As I had some experience with I/O bus standards and signal integrity, I was asked to lead the development of the electrical portion of the new standard. To assist with the task I was offered an almost unlimited supply of young engineers, one of whom was Arpad Muranyi. Realizing our success hinged on simulation, our team set out to explore our options. Sitting one day listening to a laundry list of features from a sales rep, we learned about SPICE elements that could represent transistors behaviorally; voltage-controlled current sources, and the like. We realized that if we could mathematically model an ASIC’s I/O without the burden of its gate dimensions, oxide thickness, p/n doping etc., we might be able to simulate our ideas fast enough to develop the new standard. While I went off to negotiate I/O loads, timings, topologies, and divisional intricacies, Arpad set out to craft a behavioral I/O model in SPICE. And he succeeded. His model would later become the original template for IBIS, although we didn’t realize it at the time.
Our team went on to use Arpad’s behavioral I/O model to design the original PCI Bus. Logging 5,000 hours of SPICE simulation validated by test boards and lab measurements, we originated “dynamic AC specifications” to achieve “reflected-wave switching” amidst up to 10 ASICs on a 33 MHz “speedway”. While that was a good accomplishment, perhaps our greatest achievement was using our mound of data to negotiate 11 ns – more than 1/3 of the clock cycle – to allow the signals to bounce around the interconnect and achieve the desired voltage. And it worked. Throughout the next couple decades, millions of systems used those 11 ns to successfully implement a variety of configurations.
Figure 1: The Blue Shirts. Part of the original PCI design team: Koelling, Telian, Muranyi, Saunders
Following the success of PCI, we were asked to resolve the interconnect between the first Pentium processor and its chipset using our newly-developed behavioral modeling environment. As we did this work in a “technical marketing” (apps) group, we were also asked to enable customer simulation of the interface. And so we provided our I/O buffer’s characteristics in formatted spreadsheets that had both tables and graphs of behavioral data such as I/V curves, edge rates, and die capacitance. As I was explaining it all to my manager one day he asked me what it’s called, so I awkwardly read the techy title at the top of the spreadsheet: “Er, Uh, Intel Buffer Information Sheets?”. With some frustration he replied: “Telian, I’m going to teach you how to market this stuff. Call it IBIS!”. And so we did.
A Match on Dynamite
We believed our “IBIS” spreadsheets would work for customers because a number of open-market simulators used behavioral I/O model constructs similar to ours; most notably XTK, SimNet, and Hyperlynx. But how could we transfer our paper-based spreadsheet of data reliably and consistently into these simulators?
Around this time Arpad and I visited EDA vendors to explain what we were doing and recruit their support for our new model format. I’ve always said it was like “putting a match on dynamite” because generalized SI simulation was just waiting to happen. Edge rates were exceeding route lengths and simulators were ready, but lack of vendor models was prohibiting everything from moving forward. EDA vendors received us enthusiastically, and soon we had “Intend to Support IBIS” statements from nine companies.
The need for a text-based machine-readable format for our “sheets” was obvious, so we recruited the EDA vendors to join us at “IBIS Open Forum” teleconferences where we quickly resolved the 1.0 IBIS Specification in only 4 meetings. As the groundswell of support grew we captured media attention, and Chuck Small at EDN pointed out to me that an “IBIS” is also a bird. I guess you don’t learn that living on the West Coast. In the same time frame the Open Forum originated BIRDs (Buffer Issue Resolution Documents), the “Golden Parser” concept, communication “bulletin boards” (later, email reflectors), and a means to measurably demonstrate “IBIS Capability”.
Figure 2: The IBIS Bird Continues to Soar
Intel provided significant support for IBIS. Wanting to demonstrate an open stance, encourage other IC vendors to join in, and ensure collaboration, we dropped the lower-case “i” for “Intel” in “iBIS”, changing it to “I/O”. And now that we had a “Spec” we changed “Sheet” to “Specification”. So in a short amount of time we morphed from “iBIS = intel Buffer information Sheet” to “IBIS=I/O Buffer Information Specification”. Watching IBIS continue to transform itself over the years to handle many tasks beyond its original scope, I’ve often felt the name should change again from “I/O Buffer Information Specification” to “Interface Between ICs and Systems”. We’ll see, maybe someday.
On to Maturity
If I was the “father of IBIS”, I certainly didn’t do a very good job of helping it grow up. While our division was tasked with supporting customers designing in Pentium chipsets - and modeling and simulating the same - it was a bit of overachieving to simultaneously develop the standard that would describe those models. And so at DAC 1993 – less than 2 months after starting the IBIS Open Forum – I passed leadership of IBIS to a division that had the charter to develop tools and standards, and into the capable hands of Will Hobbs. Will was experienced in these things and, along with others in the IBIS Open Forum, fashioned IBIS into the ANSI/EIA Standard it is today. Will’s division awarded Arpad and me for our IBIS accomplishments, while, comically, our division manager asked “What did we do?”. Ah, the world of SI; always needful, but never quite in the mainstream.
I am pleased that IBIS has maintained its cooperative, collaborative, and “open” stance amidst a wide range of competing companies. The SI Community is a fine collection of engineers, and IBIS gave us a place to interact with others who understand the issues we face. There have been many who have fanned the flame of IBIS, including significant ownership and oversight by Bob Ross, Michael Mirmak, and Mike LaBonte.
IBIS Gets Giga
One of IBIS’ biggest challenges was the Gigabit SerDes I/O. Integration has transformed the simple push-pull I/O into Digital Signal Processors that include complex equalization, clock recovery, and a variety of other functions. Gigabit signaling brought us not only this new style of SerDes I/O, but also a new kind of simulation. Traditional SPICE’s time-stepping could not produce a meaningful eye diagram and/or a reasonable prediction of Bit Error Ratio (BER). And so, as in the days of the original IBIS behavioral simulators, new simulators were written using frequency-domain techniques to quickly simulate millions of bits. Yet what kinds of models would work in these new simulators? …and who would lead the industry in standardizing these models?
Once again the IBIS Open Forum provided the framework for multiple companies to collaborate on a SerDes modeling solution, and formed the “Advanced Technology Modeling (ATM) Task Group”. The group settled on having component IBIS models call an external executable (an idea first proposed by Will Hobbs a decade earlier to handle GTL) and IBIS-AMI (Algorithmic Modeling Interface) was born. Thanks to leadership provided by SiSoft, Cadence, and others, AMI modeling was approved by IBIS in 2007 (BIRD 104); IBIS again solving the chicken-and-egg stalemate between models, simulators, and users. The ATM group continues to stay active developing solutions for new technologies such as PAM4 (BIRD 175, 2015), Back-channel Support (BIRD 147, 2017) Repeaters/Re-timers, and more.
So what is “IBIS”? You could say IBIS is models, technology, BIRDS, history, futures, committees, memberships, meetings, summits, people, and more. For me and many others, it is also memories. Now that the story is told it should be clear that “father of IBIS” is over-stated; I was simply sitting on the egg when it hatched. And then, thankfully, many others stepped in to teach it to fly. Nevertheless, hatching IBIS was a defining moment in my career and it is fun to recall deciding to use the pipe character for comments and debates about “Vcc Relative”. I’m thankful we deliberately made IBIS both human- and machine-readable, as I still regularly hack models to adjust their behaviors.
At this point in history IBIS models import correctly and “just work”, enabling various types of SI simulation over a wide range of frequencies. Indeed, IBIS has proven to be solid technology propelled by the wings of collaboration, and almost 30 years later IBIS is still going strong. Thanks to the on-going work of the Open Forum, IBIS continues to stay relevant throughout the many changes of the electronics era. And now the IBIS 7.0 Specification enables auto-configured models of complex die and package interconnects (BIRD 189) – capability that required almost 5 years to resolve. Indeed, the committee has a long history of rising to meet new challenges. [Bravo IBIS] – keep soaring!