USB 3.0 PHY Verification: how to manage AMS IP verification?

Very interesting question from Zahrein in this thread: “how to manage an embedded USB 3.0 PHY Verification”? To clearly position the problem, Zahrein need to run the RTL verification of a complete SoC integrating an USB 3.0 function, that is the Controller (digital) and the PHY (Analog Mixed Signal) embedded in the SoC. The question, as asked by Zahrein, is “inside the USB3 block, we will have a lot of Mixed signals and hence the AMS verification is needed but as a USB3 block connect to the core or IP’s, do we need AMS verification. I believe the Full chip RTL validation would cover it as the Data_In and Data_out is in digital waveform”.

In fact the answer is “No”, you don’t need to run AMS verification at this stage (RTL of the complete SoC), but, immediately comes a condition: as far as the PHY-specific Mixed Signal verification has been done already, and this should be part of the PHY development methodology. The next question quickly comes: is the PHY developed internally, or has it been sourced from an IP vendor? If the latest is true, the solution is not far away.

According with Navraj Nandra, Director for AMS IP at Synopsys: “after integration of the PHY into the ASIC, USB3.0 functional (logical) verification must be done at a “system level” including at a minimum, the PHY, the link-layer controller (host/device, etc.), and any VIPs. For functional verification, Synopsys ships a verilog simulation model in which the digital-logic portion of the PHY is represented by flattened GTECH netlists, and the analog portions of the PHY are represented by behavioral verilog. This verilog model can then be dropped into a simulation bench in which the other elements (e.g. link-layer controller, VIPs, etc..) are instantiated, and functional scenarios can be simulated.”

In other word, the customer doesn’t need to run AMS verification, the PHY is represented by behavioral Verilog model, and you can run a complete “digital-only” verification.

Now, if the PHY has been internally developed, the above methodology can be applied, at the condition that the PHY development team has run PHY-specific Mixed Signal verification, and generated RTL simulation model (digital-logic portion of the PHY represented by flattened netlists, and the analog portions of the PHY are represented by behavioral RTL).

In the “make versus buy” problematic, it shows that the internal PHY development team should behave exactly as an IP vendor, offering the same level of service. As a side remark (here I remember the time where I was doing SoC integration, including AMS and digital functions being provided by different design team within the company) such a “service” can be more difficult to obtain when you are an internal customer than when you are paying a license fee to an IP vendor…

Let’s imagine now that we are doing engineering in the real life (the place governed by the laws of Physics, as well as Murphy’s laws). The above described methodology has been deployed, you have run RTL simulation, and you feel that a scenario is not working quite as expected, and narrows it down to the PHY level. If the PHY has been sourced to Synopsys, Navraj’s suggestion is that the customer:

(a) captures VCD waveforms for this scenario just at the top-level of the PHY,
(b) Open a Synopsys Solvnet case for this, and upload the waveforms on the Solvnet case.

As part of Synopsys customer support, they’ll review it and determine what the problem is.

If the PHY has been internally sourced, there is certainly a similar solution, involving the PHY development team and AMS verification, but the important point here is that the SoC integrator doing RTL verification at the chip level (or below) should not be involved in AMS-level verification.

Hope this answer to Zahrein’s question…

Any comment from the design community is welcomed, as well as mentioning any other approach working for such a scenario!

Eric Esteve from IPNEST – Table of Content for “USB 3.0 IP Forecast 2011-2015” available here