USB Challenge? Sheer Breadth – Q&A with Chuck Trefts, Ellisys
New USB use cases keep popping up, but here’s why protocol test and analysis tools are keeping up.
Editor’s Note: “We are often the first tools in the labs,” Chuck Trefts told EECatalog, referring to the protocol test and analysis company Ellisys where he is Director of Operations. Trefts explained that as a small-to-medium sized firm, Ellisys has a history of being nimble enough to react to changes affecting compliance and interoperability quickly. Edited excerpts of our conversation follow:
EECatalog: How are Ellisys solutions applicable to USB and other technologies which are part of the computing device interconnect world?
Chuck Trefts (CT): We create and sell protocol analyzers, generators, and compliance testers for Bluetooth, USB, and WiFi. On the USB side, the folks buying our products are those making the silicon and those turning silicon into products. They debug and test with our tools to help assure product interoperability and compliance to standards, which are generally put out by the USB-IF. When it comes to USB, we tend to be early and we tend to be aggressive on the design. We are often the first tools in the labs of the companies that are creating these products, and therefore we have to be very comprehensive.
EECatalog: Likely that ability to get tools into the labs early has been helpful.
CT: Yes, for example USB Power Delivery technology was originally done with a frequency shift key (FSK) approach over standard USB connectors. However, just a year or so into the working group definition of that technology, a pretty radical shift was made to move to a Type-C connector and Manchester encoding, which essentially set back all of the test equipment vendors in the space by a year-and-a-half to two years.
Ellisys, though, was able to adapt our Power Delivery solution extremely quickly, to be able to support this Manchester (BMC) encoding and the Type-C connector in a matter of weeks. For the better part of a year and more we were the only protocol tools supplier out there for developers making USB Power Delivery and Type-C products. You generally just don’t attempt this type of development without these types of tools—so being there that early and being able to adapt to the change from FSK to BMC and Type-C accelerated this market. Had we not been that early and that ready with those tools, we would probably have seen a delayed industry roll-out or at least a fairly rocky roll-out with Type-C and Power Delivery products, which are pretty pervasive at this point.
Our design was inherently flexible from a software perspective, and we were able to quickly create some physical adaptations, to meet the technology change.
EECatalog: Were you able to take advantage of any kind of warning that the shift from FSK was going to take place?
CT: No, the change was not telegraphed to us. We found out pretty much as soon as the USB working group members did, but as I said, three quarters of the way through the development USB-IF changed the connector approach and the way that the communication is encoded—these were fundamental changes. These changes caused some other vendors to go back to the drawing board. We, on the other hand, adapted quickly and were able to allow that technology to continue its development unimpeded, without any pause for test equipment reasons.
EECatalog: What allowed Ellisys to react quickly?
CT: Being led by an engineer—our CEO is an engineer— helps, plus we are engineer-heavy in terms of staff composition. Our size is such that we can be nimble. We were able to gather our resources to very quickly redesign our external interfaces and our FPGA and our firmware to adapt to the changes.
EECatalog: What makes a protocol test system technologically advanced?
CT: First it’s helpful to know that the lines are blurring a little bit between physical layer test and between protocol test for USB Type-C and Power Delivery, which are electrical standards for the most part.
EECatalog: Why are the lines blurring?
CT: Partly because the technology is getting better with respect to the tools. We want to go down the stack a little more toward the physical layer, and we have always done this to a degree, but Type-C, for example, is in large part an electrical standard. Power Delivery, which uses Type-C, is part electrical and part protocol, so we can’t just build a protocol analyzer and ignore the electrical—they are too intertwined.
With USB 3.x and USB 2.0, it was mostly a protocol task for us. Protocol-oriented tools for these standards didn’t generally go too far down into the physical layer, but by its nature, USB Power Delivery especially is essentially a hybrid technology; it supplies power and voltage—and to do this, it uses a fairly complex protocol with precise timing requirements between the protocol and electrical pieces.
All protocol tools do start with a phy layer, and the phy layer for a technologically advanced tool must be high quality and purpose-built for the task at hand. Test equipment grade so to speak. Not re-purposed standard phy for example, which can be easier to design, but limiting when used in test tools.
Test equipment grade is always the better approach. For example, having user controls that allow the analyzers to accommodate often imperfect early phy spins by making receive and transmit parameters adjustable, or amplitude controls—and the same for exercisers. Being able to control a variety of transmit parameters is ideal when testing receivers.
Beyond the phy layer, protocol testers must be able to easily crunch large amounts of data in real time and present it in formats that are customizable, to suit the user’s preferences and task requirements. There can be no one-size-fits-all approach. There are a wide variety of users and a wide variety of applications. It has to be intuitive so that it does not take too long to learn, and it has to be robust and well tested so that engineers can spend their time fighting their own issues and not fighting the tools. It is the hardware and software combination, when done right, that will make a system technologically advanced.
EECatalog: What applications do you see as needing to rely even more on reliable protocol analysis, traffic generation, and compliance testing than in the past?
CT: The Type-C connector opens the door for such a wide variety of usage models that were not previously possible—like phones charging phones; common chargers for laptops and tablets; power and data that switch directions programmatically to meet the needs of an application. These new usage models have great potential but also an increased risk of interoperability issues. With many new and innovative products hitting the markets, it’s imperative that product developers have the opportunity to quickly identify and fix interoperability issues before the products are in the hands of consumers, so in the end, we want a good user experience. We want the consumer to be able to use products from any manufacturer and connect seamlessly with products from any other manufacturers, so comprehensive protocol tools—tools which cover the protocol analysis, traffic generation, and compliance testing trio—will play hand-in-hand with compliance and interoperability testing as defined by USB-IF.
USB Type-C and USB Power Delivery are creating so many new product types and so many new products that the sheer breadth is a challenge in and of itself because the testing has to be designed to cover all bases. Things are not as monolithic or topologically simplistic as we saw with USB 2.0 and especially with USB 3.x.
EECatalog: “Smaller, thinner, lighter” is certainly a trend, but what others should our readers be aware of, and how is Ellisys anticipating and preparing to respond to trends that affect developers working with USB technologies?
CT: Comprehensiveness. Thinner, lighter, sure—we have done that, we led the way in our space actually. Our tools have gotten to the point where what once fit in a breadbox can go into your shirt pocket pretty easily, with room to spare. Type-C opens up so many new possibilities—providing a common interconnect for a wide variety of communications protocols.
Newer tools are moving toward broader support for technologies that use Type-C, all under a single platform. USB Power Delivery, operated over Type-C, manages alternate modes, including Display Port, HDMI, Thunderbolt, and sideband communications like Display Port Aux mode. And all of these need to be supported, not to mention the electricals that go along with Type-C and USB Power Delivery. Support for common protocols like UART, SWD, I2C, and SPI is also needed as development labs often use these in the early design phases. You can throw in logic capture, and you’ve got a lot to consider when making tools selections. And of course, USB 2.0 and 3.x communications as well. The trick of course is to support each of these technologies at a high level, with the same standards of quality you’d expect on a stand-alone tool that focuses on just one thing.