Power Where It’s Needed: Q&A with Synopsys on USB Power Delivery 3.0
Support for the USB Power Delivery 3.0 standard has significance for next-generation consumer, automotive and industrial SoC design teams.
Last month Synopsys announced the industry’s first verification IP (VIP) and UVM source code test suite to support the USB Power Delivery 3.0 standard. Zongyao Wen, Manager, R&D for USB VIP at the company, spoke with EECatalog staff about the announcement.
EECatalog: How will Synopsys support of the USB Power Delivery 3.0 standard affect designers?
Zongyao Wen, Synopsys: Our support of USB Power Delivery 3.0 verification allows the industry to quickly start adoption of the new protocols. Many times for a design team to jump in and do the design, lacking a verification solution can delay their tape out and delivery, or they have to spend more time and costs on their side to develop an equivalent model or similar solution on the verification side.
EECatalog: What are some ways you see designers taking advantage of this idea that headsets, for example, can now negotiate for only the power they require?
Wen, Synopsys: USB Power Delivery 3.0 allows designers to fine tune power consumption to what the design needs, with the goal of reducing overall power use. Just as important, for power-hungry devices, it can allow the power to be used more efficiently, so power can be consumed where it’s needed and when it’s needed. That can result in benefits such as faster battery charging.
And a power delivery protocol allows standardization. A charger can be shared across different vendors for example. All the device providers can build their power supplies following the same spec, and that charger will provide close to maximum power to all the potential usages. It’s an advantage for the end user and also for the designer, as it allows him to safely design a device that draws required power.
EECatalog: How has “what must happen in order for design to happen efficiently” changed over the past five years?
Wen, Synopsys: Not just in the last five years, but starting even earlier, one factor is the sheer number of IP adoptions. Also, VIP has become more important. Another trend clearly starting to emerge is greater UVM [Universal Verification Methodology] architecture adoption.
It’ s good, from our point of view, that the industry has started standardizing on one methodology. It makes things more efficient because, especially as a VIP provider, we don’t have to spend time and energy working on multiple solutions for the same protocol. Instead, we can concentrate on, and optimize our solutions on, UVM, and I can see that across our product lines, not just for VIP, but also for simulator (VCS) and debugging tools (Verdi). UVM is garnering more support, both from the EDA tool provider point of view, and also from the customer-adoption point of view.
So VIP has been in use for a long time, and now UVM is pushing VIP into reuse in subsystems, into higher-level verification components within the verification environment. There is no longer just a single VIP for our customers.
EECatalog: What issues, either specific to SoC design, or from a wider-angle view, do you believe may not be getting their fair share of attention?
Wen, Synopsys: It’s key to reuse and to reduce duplicate efforts. Many times within the same company, teams are not able to reuse another project team’s work, which leads to a lot of duplicated effort, and, specifically as this concerns verification IP, if a company has teams working at the subsystem level or block level or C level, not being able to reuse another team’s verification or part of that verification environment, like a subsystem, means that the other team has to re-do some of the work.
And then there is driver development, or stimulus generation, and even if there is a VIP involved, and they can reuse the VIP, there are controlling blocks around it, there are monitors, and so on. And all of these have to be hooked up again. Add to that the time spent on bring up as well as on getting the environment stable again.
So it is not just the construction costs, but also the maintenance and debugging costs of building such environments. Improvements can be made to save time to market.
Wen, Synopsys: One thing we are doing is looking at the subsystem level, and no longer just at the VIP. VIP has traditionally focused on one particular protocol, one particular standard, whereas subsystems are getting out of that [approach]. We are looking at supporting things that require multiple protocols. One good example is USB Type C. [With USB Type C] the same connectors and the same set of wires can support USB and power delivery, but also, other protocols on top of it, such as some of the popular display-related ones, including DisplayPort.
With USB Type C, for the design to verify the types of interfaces supporting all these protocols, it is no longer just one VIP. There are separate VIPs supporting [the protocols], but in order to run them more efficiently, we need a subsystem, so the verification teams don’t have to connect all these different VIPs to the Type C interface on their own.
This [involves] taking on bigger chunks of the verification environment that the customer has to do and providing a bigger re-usable block. The current re-usable block is around VIP, but eventually as designs become more complex and more of these sub-areas have some common function, EDA companies and verification providers can start providing these additional features as a subsystem.
Today Synopsys has VIP test suites which are moving in this direction. Rather than focusing on a single protocol, a single VIP, think in terms of what other blocks within the verification environment can be isolated and then reused or acquired.
The focus has been on test plans, test cases, and how to get more test cases from a test suite. However, the goals of design efficiency over the long term, saving time and providing some stability, demands not just [considering] test cases, but also the test environment that goes with the test suite.
This is because the test suite environment is potentially a building block for more complex design. We’re moving toward a subsystem with multiple protocols toward the SoC level, which certainly will have a lot more protocols [Figure 1]. It is not just one or two anymore—it’s on the order of a dozen or so different protocols residing on the same chip. Reusing these subsystems from a test suite would allow an SoC-level environment, where subsystems are much more straightforward and more stable, because the subsystem would already have been verified, along with a protocol-focused environment. This in turn, makes migrating those to the system level much safer.