Precise Integration
Integration begins with the PHY deliverable package. There is some detective work here, as our specialists determine what all was included to aid in the integration process. The needed pieces must be located and digested. These include any datasheet or integration guide documentation, as well as finding the top level of the RTL in the deliverable. These are some questions we might investigate with:
- If the Verilog is encrypted, do we have a port list or instantiation model to reference somewhere?
- Which toolset has encrypted the files?
- Are the provided files true RTL or a verification model?
- Are other IP included to interface with external handshaking signals such as AUX/HPD or is that assumed to be handled by Trilinear?
In the ideal case, an example test script (or at least a build script) has also been included. This is extremely valuable as our specialists learn how to make a project around the PHY deliverable, and how to include the necessary pieces of that process in the Trilinear DisplayPort compatibility testing ecosystem. Once we have the PHY running we can begin the process of learning the PHY’s timing requirements. From there, we can tailor our tests to ensure the PHY is running within its own unique set of constraints. Older and certain reprogrammable technologies will take longer to obtain PLL lock or achieve tight clock domain recovery. Many newer PHYs accomplish these same tasks in microseconds. Going a step beyond understanding these timing constraints to adapt the tests that check and enforce these requirements ensures the most robust design possible built around your specific PHY.
Part of that robustness also comes from the minimalist approach to designing the “glue layer” of new logic adapting the foundry’s high-speed SERDES IP block into the architecture of the Trilinear link-layer RTL and test environment. The most critical path here is the data path. We must trust the high-speed serial side will be routed correctly on the chip; the only thing we can do on this side of the PHY is to not touch it. But if we don’t correctly communicate with the parallel data side of the block, the rest of the design will be a certain failure. Wide timing margins and correct clock association are critical here. Just assuming a rising clock edge will capture data could be a very costly mistake!, and we haven’t even gotten to the data signals yet. Most commonly the width of the parallel interface needs to be adapted.The Trilinear Link Layer utilizes a 40-bit wide parallel data interface in order to ensure the slowest possible clock frequency in the digital video processing logic. Simply put, it is easier to build large chips around slower clocks. However most PHY SERDES IP interfaces at 10 or 20 bits of parallel data for reduced gate count and die size. To bridge this gap, we adapt the data interface presented by the SERDES IP block by using a “gearbox” adapter module that is developed and maintained just like our link RTL. Even though this code may be new to your project, we rely on tried and trusted IP as much as possible during the integration process.
Our integration of the supplied PHY IP block is intended to provide the highest level of robustness in the final DisplayPort solution in your product, but we also want to ensure your project can be tested and exercised as your chip manufacturer intended as well. We will provide multiple options for I/O buffering of important signals in the PHY interface. We will examine multiple possible reference clock options (if the PHY IP allows for this). We will provide customer access to all ports of the IP block that are not actively used for DisplayPort support so as not to interfere with access to test ports or other features of a mixed IP block that will support other interfaces alongside DisplayPort, such as Ethernet or USB. Our end goal is to provide you with a Fully developed solution ready for production deployment with extremely high confidence and minimal risk.
A Test for Every Obstacle
Not only do we connect the PHY to our link for you, but we also verify and regression test to ensure the DisplayPort integration will work to Trilinear standards. Trilinear has spent years developing its own custom DisplayPort compliance test suite for receive, transmit, and transceiver implementations of DisplayPort. A small fleet of blade servers is waiting to put your PHY integration through its paces. In-house experts maintain and constantly expand upon Trilinear’s test environment, cutting the path forward in DisplayPort feature support and riding the industry wave toward broader adoption of the 2.0 standard revision and beyond. Extensive regression testing libraries also ensure proper adherence to established and globally-utilized standards such as DisplayPort 1.4. Trilinear has all the versions covered so you won’t have to worry about it.
Quality Time, Quality Outcomes
Most PHY technologies have a defined set of steps to follow upon device bring-up or during other common operations like changing interface link rate or lane count. Exactly what those steps are, how much time they will take, or how they are to be accomplished can vary substantially from core to core. Trilinear takes the time and effort to learn each core it is given to ensure successful integration. This is one of many reasons we have been chosen several times to work with PHY vendors as they plan upcoming revisions to their own IP.
Through the required combination of port-level signal control and internal PHY IP configuration writes & reads, Trilinear specialists create high-level control procedures written clearly enough to read as pseudo-code by you and your technical staff. Trust us, you’ll need an initialization and link-rate set routines. We’ll figure them out and give them to you in our emulated firmware tasks. PLL programming values for common reference clock values? We’ll give you those too.
Along with all our source code.
Because it’s that good, we can be that confident.
