BLOGS & FORUMS
Breaking The Three Laws
|Breaking The Three Laws|
Archive for the 'ASIC Verification' Category
Posted by Michael Posner on 13th December 2014
Warning: Technical Content!
I read an online article this week which flagged an issue with FPGA-based prototyping, clock conversion. Clock conversion is one of the most important aspects to successful prototyping and this week’s blog is dedicated to sharing information enabling you to be successful. Specifically I will cover automated Gated Clock Conversion, GCC, as the user realizes the highest benefits. With automated gated clock conversion you don’t need to maintain a separate RTL code branch for prototyping, you use the golden RTL source. Clock conversion done right ensures the prototype runs at the highest performance functionally equivalent to the source. If you look at the data from the Channel Media survey that Synopsys had conducted you see that for large FPGA-based prototyping, clock conversion is a major challenge.
Hold on, I forgot to cover why clock conversion is needed for FPGA-based prototyping. It’s one of the three laws, ASIC are not the same as FPGA’s, specifically in this case FPGA’s do not have the same clock resources like ASIC’s do. ASIC designs often use clock gating to reduce dynamic power and have complex clock logic to generate numerous internal clocks. In the ASIC flow, users do Clock Tree Synthesis to balance all the clock paths between the sources and destinations and avoid clock skews between them. The problem is the number of ASIC clocks in the design typically exceed the number of global clock lines available in the FPGAs. There are a limited number of dedicated global clock lines in FPGA devices and Global clock lines cannot accommodate clock generating and gating logic. Thus GCC is needed to convert these ASIC clock structures to FPGA comparable structures. You could do this manually but that’s time consuming and error prone.
In Emulation oversampling type techniques are used to solve this problem, this is where all clocks are resolved to one synchronous clock source and all clocks are driven from derivatives of this clock. The benefit of this technique is that the conversion is fast and practically any type of clock tree structure can be handled. The main two disadvantages are #1 you tank performance as the system frequency is dictated by the slowest clock. #2 the design loses some fidelity as all clocks are synchronous to each other which may not reflect the true asynchronous clock behavior hiding issues in clock domain crossing circuits. Techniques similar to this such as the HAPS Clock Optimization in ProtoCompiler (I think I’ll blog about HAPS Clock Optimization in the future but for today I’ll focus on Gated Clock Conversion) which map clocks to HAPS hardware resources, are getting popular in FPGA-based prototyping as they can help reduce the time to first prototype enabling a prototype to be handed off to the software teams quickly. It will not have the high performance expected by the software engineers but it’s available quickly, handles almost any ASIC clock structures and this gives the prototype engineers a little breathing space to complete the high performance version.
Gated Clock Conversion, GCC, converts ASIC clock structures to FPGA friendly structures mapped to FPGA clock resources. GCC also needs to handle timing violations due to clock skew created because of clock gating logic. These violations are introduced on paths where the source and destination flops are driven by different clocks. Data from the source may reach the destination quicker/later than the clock resulting in hold/setup time violations in many paths. GCC has to ensure that there is no clock skew between two synchronous clock domains. The GCC capabilities of ProtoCompiler directly addresses both these conversion challenges in a fully automated fashion. ProtoCompiler maps to FPGA resources and moves the generated clock and gated clock logic from the clock pin of the sequential elements to the enable pins. This includes supporting implementation of these structures across block boundaries and across multiple FPGAs as part of partitioning.
Tool support of automated gated clock conversion is not a milestone it’s a journey as ASIC coding styles are continually evolving and the tools need to keep pace. ProtoCompiler has an extensive portfolio of supported structures including, but not limited to, Generated Clock, Gated Clock, Integrated Clock Gating Cells, Complex Sequential Cells, Instantiated Cells, Mixed Async Controls, Data Latches and MUX / XOR structures. With the correct clock constraints ProtoCompiler should automatically identify these gated clock structures and convert them to FPGA friendly structures. Below is an example of generated clock identification and the result of the automatic conversion.
In summary clock conversion is essential to successful prototyping. The ProtoCompiler Clock Conversion capabilities moves the generated clock and gated clock logic from the clock pin of the sequential elements to the enable pins, allowing sequential elements to be tied directly to the source clock, removing skew issues and reducing the number of clock sources in the design making it FPGA-based prototype friendly. Automated Gated Clock Conversion is just one of the many capabilities that ProtoCompiler delivers and is essential for prototypers.
Don’t forget that the FPGA-based Prototyping Methodology Manual, FPMM, has a section to help understand clock conversion and other ASIC design structure handling. Last week I had the pleasure to hang out with Rene Richter, one of the authors of the FPMM. Rene signed a book copy for me, this copy could be yours if you comment and answer the following question
How many HAPS systems has Synopsys shipped and to how many customers?
Answer the question by comment and if you get the answer right I will contact you to get your shipping addresss.
If you like this or other previous posts, send this URL to your friends and tell them to Subscribe to this Blog.
To SUBSCRIBE use the Subscribe link in the left hand navigation bar.
Another option to subscribe is as follows:
• Go into Outlook
• Right click on “RSS Feeds”
• Click on “Add a new RSS Feed”
• Paste in the following “http://feeds.feedburner.com/synopsysoc/breaking”
• Click on “Accept” or “Yes” or whatever the dialogue box says.
Posted in ASIC Verification, FPGA-Based Prototyping, Man Hours Savings, Technical, Tips and Traps | No Comments »
Posted by Michael Posner on 5th December 2014
During a customer meeting last week I found myself explaining many different topic’s all of which I have blogged about over the last couple of months. I suddenly realized that while I blog every week that many of you might not get time to read them every week and miss important information. Below is a list of what I think are the impactful blogs from the last couple of months, just in case you missed them.
The Top 3 Myths of Prototyping – BUSTED. This was a particularly popular blog as it highlights the state of FPGA-based prototyping addressing capacity, time to first prototype operation and debug.
Solving the ASIC Prototype Partition Problem. Discusses a Synopsys whitepaper on partitioning of an SoC/ASIC to FPGA-based prototype using ProtoCompiler. ProtoCompiler generates a partition solution in minutes, (under 10 minutes in most cases).
Abstract Partition Flow Advantage. Sort of goes hand in hand with the solving partition problems blog. This blog focuses on how to use an abstract partition flow to create the highest performance and optimal hardware interconnect and software partition for a given SoC/ASIC.
The Secret Ninja-Fu for Higher Performance Prototype Operation. It’s no secret how to achieve the highest performance prototype, you need an integrated solution and the ability to tailor the hardware inter-FPGA interconnect to the needs of the SoC/ASIC being modeled. Dedicated “fixed” traces just don’t cut it, they restrict the platforms flexibility and introduce interconnect bottlenecks.
3 Phase Approach to Successful Prototyping. Pretty much the bible of successful prototyping. Follow these three commandments will lead to successful prototyping.
Going vertical for all the right reasons. Blog on developing and the advantages of vertical daughter boards. One of our customers read this post and then went on to develop a stack of custom vertical daughter boards for their specific needs. I’m happy that my blog helped this customer to be successful.
Anyway, this should be enough to keep you busy for a week.
Posted in ASIC Verification, Bug Hunting, Daughter Boards, Debug, HW/SW Integration, IP Validation, Man Hours Savings, Use Modes | 1 Comment »
Posted by Michael Posner on 7th November 2014
Dear Dr. Lauro Rizzatti,
I enjoyed reading one of your recent articles http://electronicdesign.com/eda/hardware-emulation-weapon-mass-verification but was dismayed that you were still quoting limitations from the early years of FPGA-based prototyping. I recommend you refresh your knowledge and read my recent blog on the top myths of FPGA-based prototyping busted. http://blogs.synopsys.com/breakingthethreelaws/2014/09/top-3-myths-of-fpga-based-prototyping-busted/
I’m looking forward to future articles integrating the latest information.
Just in case you don’t take the time to read Dr. Lauro’s article the three points of out of date information were on capacity supported, time to first prototype operation and debug.
Quote “Even in the largest configurations, they address designs with about 100 million gates.”
– New Data Point, Synopsys HAPS supports 288 Million ASIC gates
Quote “ Conversely, very long setup time to map a design into a proto board and rather limited design visibility are its two main drawbacks.”
– New Data Point, Synopsys HAPS and ProtoCompiler software accelerated time to first prototype and delivers high visibility debug.
When you correct these mistakes the radar graph in the article changes quite a lot.
Just in case you missed my blog on the top myths here is a direct link to it again: http://blogs.synopsys.com/breakingthethreelaws/2014/09/top-3-myths-of-fpga-based-prototyping-busted/
Posted in ASIC Verification, Debug, Man Hours Savings | No Comments »
Posted by Michael Posner on 24th October 2014
This week’s blog is a bit of a mashup (Yes that is a real word, a mashup, in development, is something that uses content from more than one source to create a single new offering) as I am pulling together two topics to create one. The #1 usage case of prototyping is for early software development. You can do this very early, pre-RTL using Virtual Prototypes, later in the design cycle with FPGA-based Prototypes but it’s the bit in the middle that this week’s blog examines.
The bit in the middle is typically unit level or IP validation with the goal of early software development before the rest of the subsystem is available. The DesignWare IP Prototyping Kits : http://www.synopsys.com/IP/ip-accelerated/Pages/ip-prototyping-kits.aspx were designed to address the need for immediate productivity and early software development for DesignWare IP’s. The kit includes the actual DesignWare IP modeled on HAPS-DX and an ARC based Software Development Platform
The question which has been raised a couple of times is what if you are not using an ARC processor in your end SoC? At this point I usually start probing a little more as to what type of software is being developed, if its physical layer and processor specific then yes the ARC software development platform is not going to work for you. If it’s higher layer software then typically the software engineer does not care as it’s layers above and abstracted from the physical execution machine. But what do you do in the case where you need physical layer and processor specific software development?
Lets use the example that you want to enable early software development on an ARM-based system representation and you still want to validate your design under test modeled on a FPGA-based prototype. The problem is that your SoC engineers have not complete the subsystem design and/or you don’t have access to the RTL to put the processor subsystem on the FPGA-based prototype along with your DUT.
One solution would be to do similar to what Synopsys did with the DesignWare IP Kits and that is connect the FPGA-based prototyping platform to a physical daughter board containing an ARM-based subsystem. One of the possible ways to do this is to use an off-the-shelf Xilinx Zynq based daughter board. The Zynq device includes a Dual Cortex-A9 MPCore processor subsystem and provides the ability to connect this to the FPGA-based prototyping platform via an AXI tunnel across typically FMC connectors. This is true for the HAPS series where you have the ability to connect the Zynq based board to HAPS via FMC cables.
Great right? Hummm…. Seems too good to be true…… Yes, you are right, this use mode is a trade-off. While you can execute ARM-based code against your prototype you are not running the software against YOUR ARM-based subsystem. You are stuck with the processor configuration hard-coded into the Zynq device which you know will never match your SoC subsystem. Also, in the case of the Zynq it’s the 32bit processors not the 64bit versions. There is a better way to enable early software development using a processor subsystem which is a better match to your SoC’s subsystem, it’s the Hybrid Prototyping approach.
I’ve blogged about this before, one such case was Zoro’s use of Hybrid Prototype for early software development for USB 3.0 : http://blogs.synopsys.com/breakingthethreelaws/2014/06/zoro-delivers-hybrid-prototype-for-early-software-development/
The advantage of using a Hybrid Prototype rather than a fixed hardware daughter board is that the virtual processor based subsystem can be tailored to more specifically match the SoC subsystem design. New to virtual prototyping? Don’t worry, Synopsys provides ARM Virtual Development Kits (VDK’s) : http://www.synopsys.com/Systems/VirtualPrototyping/Virtualizer-Development/Pages/vdk-family-arm.aspx to jump start your development. These VDK’s can be used at the starting point for your customization to match your SoC’s need. This full virtual environment is expanded to a Hybrid Prototype with the use of the off-the-shelf transactors which are a bridge between the TLM virtual and the RTL hardware systems. You are not sacrificing performance either as the Synopsys Hybrid Prototyping solution enables asynchronous operation between the Virtualizer and HAPS ensuring that the software env executes at speed as well as the hardware env which is typically required to keep real world interfaces alive.
What a mashup !!! It’s clear to me that Hybrid Prototyping is a far better solution to enable early software development as you can customize the processor subsystem to more precisely match the SoC. This way the software code created and executed on the prototype is a closer or direct match to the software which will run on the SoC.
Posted in ASIC Verification, Daughter Boards, DWC IP Prototyping Kits, Early Software Development, Hybrid Prototyping, IP Validation | 1 Comment »
Posted by Michael Posner on 3rd October 2014
We have just uploaded a stack of product videos. Below is a list of the latest three. (I think they are sexy!!)
• Prototyping Imagination’s PowerVR Series 6XT dual-cluster 64-core GPU with Synopsys HAPS and ProtoCompiler
A video showing the multi-FPGA system used to model IMG’s GPU. The system has real-time video out for visual inspection of the images
• Speed IP/RTL Block Bring-up and SoC Validation with HAPS-DX
A video explaining the methodology, flow and capabilities which enable a block to be prototyped and debugged on HAPS-DX and seamlessly integrated into an SoC prototype on HAPS-70
• Synopsys ProtoCompiler for RTL Debug with HAPS Systems
A video showing the new ProtoCompiler debug capabilities including multi-FPGA with deep trace
They can all be found (plus more) here: http://www.synopsys.com/Systems/FPGABasedPrototyping/Pages/Videos.aspx (Sexy right?)
A couple of weeks ago I blogged about my 20 years at Synopsys. Well this week one of the Synopsys sales people was nice enough in their own time to create a depiction of what I look like now vs. 20 years ago. Below you can see the then and now depiction.
THANKS, Mr. Synopsys sales person…. You know who you are…. I know where you sit
To set the record straight below is a picture I snapped off this week after a haircut.
No supermodel for sure but I still got my hair…
Posted in ASIC Verification, Bug Hunting, Debug, DWC IP Prototyping Kits, Early Software Development, Humor, IP Validation, Man Hours Savings | 1 Comment »
Posted by Michael Posner on 13th September 2014
This week I’ve spent most of my time busting the top three myths of FPGA-Based Prototyping, specifically in respect to the HAPS solution based. The top 3 are:-
- Capacity limited to less than 100 Million ASIC Gates
- It takes months to get prototype working
- Limited debug visibility
These myths are cast backs from the dark ages of FPGA-based prototyping, also known as BMWS, Before Mick Worked at Synopsys, which was a very long time ago, refer to this blog for details http://blogs.synopsys.com/breakingthethreelaws/2014/09/how-to-shaped-the-eda-landscape-and-the-world-we-live-in/
Lets take the first myth: Capacity limited to less than 100 Million ASIC Gates. The HAPS-70 series of FPGA-based prototyping hardware is based on the Xilinx Virtex-7 2000T FPGA’s. Synopsys rates each of these as 12 million ASIC gates, which is a conservative measure coming from years of experience in synthesizing ASIC RTL to FPGA. When the HAPS-70 series was launched back in 2012 Synopsys supported the automated and seamless integration of up to 12 FPGA’s which is equivalent to 144 Million ASIC Gates…. Myth BUSTED !!!! The unique HAPS architecture with its intelligent flexible interconnect architecture (rather than fixed PCB traces), combined with the HAPS proprietary high speed time domain multiplexing, enables the multi-FPGA system to be tailored to the SoC design under test achieving the highest of performance.
But wait…. There’s more….
At the same time that Synopsys launched ProtoCompiler, automated prototyping software for HAPS, we also launched support for up to 288 Million ASIC gates, 24 FPGA’s in a system. ProtoCompiler delivers the design flow managing the large SoC Prototyping project and a HAPS daughter board called the HAPS External Clock Distribution Board, HAPS-ECDB, manages the seamless clocking, reset, configuration and synchronizing across systems. So not only is the myth of capacity limited to 100 Million ASIC gates BUSTED, it’s obliterated. To add credibility to this we even have customers utilizing such systems.
Now for the second myth: It takes months to get prototype working. This problem has been solved with integration between prototyping hardware and software. Even before ProtoCompiler was launched Synopsys delivered Certify automating the flow from ASIC RTL to FPGA-based prototype. To be honest what Certify lacked was a robust partition engine and in-depth integration with the hardware. ProtoCompiler was built with full integration and knowledge of the HAPS hardware target and a partition engine which can leverage the HAPS architecture flexibility. The result is that the time to first prototype (TTFP) can be reduced to as little as a week from first RTL drop…. Myth BUSTED !!!
The great thing is that due to the close integration of ProtoCompiler with HAPS you don’t trade off performance either so the end model still delivers on the #1 requirement of prototyping which is performance.
Time to bust myth 3: Limited debug visibility. First we need to get one thing straight, in FPGA-based prototyping there are hardware limitations as to how much debug data can be stored. While it’s technically possible to get simulator like visibility in HAPS the tracing logic and size of the memory storage needed would make it cost ineffective. But debug visibility is not limited. Take the HAPS-DX, it has built-in HAPS Deep Trace Debug. HAPS Deep Trace Debug is an integrated capability of ProtoCompiler DX combined with the HAPS-DX hardware. You have the capability to do simulator like debug of the design under test. How much debug visibility do you get… well an example is that you can trace 128 signals with a capture rate of 100 MHz hardware speed and you would get 5 seconds of debug data. Or you could trace more signals for a shorter period… I say Myth Busted !!!
But guess what… there is more…..
As seen above, Synopsys also delivers a multi-FPGA solution as part of ProtoCompiler which does not require memory on the HAPS system itself or usage of the Hapstrak connectors. Again this capability is enabled by the tight integration between the ProtoCompiler software and the HAPS hardware systems.
- Capacity limited to less than 100 Million ASIC Gates – BUSTED !!! Synopsys delivers 288 Million ASIC gate support
- It takes months to get prototype working – BUSTED !!! ProtoCompiler & HAPS delivers TTFP in as little as 1 week
- Limited debug visibility – BUSTED !!! ProtoCompiler & HAPS delivers deep trace debug
Are there any more FPGA-based prototyping myths you would like me to bust? Drop me a comment and I’ll work on them
Posted in ASIC Verification, Bug Hunting, Daughter Boards, Debug, HW/SW Integration, Man Hours Savings | Comments Off
Posted by Michael Posner on 14th August 2014
A while back I talked about the various prototype to host connectivity modes facilitating IP and SoC validation including Hybrid Prototyping. The use of the Synopsys Universal Multi-Resource Bus, UMRBus for short, is key to deploying these use modes. Synopsys introduced the UMRBus along with the HAPS-60 systems and it’s popularity has grown ever since. The UMRBus provides an easy to use infrastructure for any user of the HAPS systems to configure, monitor and expend the capabilities of the HAPS system.
Synopsys provides the high level UMRBus API and the hardware interface modules along with the HAPS systems. These are the same building blocks that the Hybrid transactors are built on top of and which are delivered as part of ProtoCompiler. Multiple UMRBus connection modes are supported depending on the goal of the usage such as simple remote access and configuration to full blown high performance data streaming and Hybrid Prototyping. The follow is a list of the various connectivity modes and the expected performance. You can use these to pick the best connectivity solution to match your prototyping needs.
Typically the USB connection mode is used when all you want to do is remotely configure and debug the prototype.
The UMRBus pod enables a seamless interface into the HAPS system with direct visibility into any FPGA in the HAPS chain.
This is a very high performance UMRBus mode for the HAPS-DX making it perfect for IP validation where lots of data need to be streamed on and off of the prototype. Using this mode over 400 MB/s streaming data bandwidth can be achieved
The UMRBus over PCIe MGB connection is similar to the PCIe paddle board version for the HAPS-DX and works for the HAPS-70 via a flexible cable setup. This connection method can also be used on the HAPS-DX and delivers similar performance of over 400MB/s.
We provide example designs showing how each of the UMRBus connection modes can be used as well as integration with the prototyping software tools including the new ProtoCompiler and ProtoCompiler DX. This makes any of the modes super quick to deploy.
So as you can see, lots of options to connect HAPS to a Host for advanced prototyping.
(I’m off on vacation for two weeks, so sorry, I doubt that I’ll blog during that time.)
Posted in ASIC Verification, Daughter Boards, Hybrid Prototyping, IP Validation, Use Modes | 1 Comment »
Posted by Michael Posner on 24th July 2014
If you didn’t know the above picture is of the greater roadrunner (Geococcyx californianus). Trust me I didn’t just make up the Latin name. The Latin name means “Californian earth-cuckoo”. This blog is about how to achieve the fastest time to operational prototype, accelerating ASIC and SoC verification, speeding validation and the road runner was first image that popped into my mind when I wanted to articulate fast. There has been a lot of talk about Time To First Prototype, TTFP, recently so I thought I would blog a how to on achieving accelerated TTFP. I thought I’d raise the bar and deliver a how to on both achieving this AND get the highest operational performance out of the FPGA-based prototype.
If you have found yourself reading this blog you are looking for the magic solution but I am afraid I have to burst your bubble, there is no black magic solving this problem.
It’s better, all you need is a fully integrated FPGA-based prototyping solution. Yep, that simple, blog done, thank you :) (What? You want to know why an integrated solution solves all your problems!) To answer this we need to quickly review the challenges to FPGA-based prototyping. The below picture describes the challenges to prototyping, based on a recent survey that Synopsys ran. It also includes on the left the solutions to these individual challenges.
Click on the images to view the whole picture. I made them large so they were easy to read.
Do you spot the common theme? The challenges cannot be solved with hardware or software alone, it’s the combination that solves the problem. An example is performance, I’ve blogged about this is the past that it’s the combination of hardware interconnect flexibility and the ability to deploy a high speed time domain, differential signaling, solution that is the key to achieving the highest performance. In this case the software has to have intimate knowledge of the hardware, it’s electrical and SI characteristics to be able to correctly implement the high speed time domain IP in the multi-FPGA prototype design. At the same time ALL hardware must meet a minimum level of performance across all interconnections to ensure that when the prototype design image is deployed across many systems it always runs reliably.
Debug is another good example. To deliver the highest debug visibility you need both a software flow that enables instrumentation of the RTL, graphical display AND hardware capabilities to store the physical data. The result of integration reduces your need for expertise as the solution has the expertise. Same for partitioning across multiple FPGA’s, as the software is hardware aware and the hardware can be tailored to the software recommended best interconnect topology the result is optimal.
Lucky for you, Synopsys delivers a fully integrated solution of ProtoCompiler plus HAPS so you don’t have to wait. And… if you call now, not in 5 minutes but now, I’ll personally visit your site to say hello.
While ProtoCompiler was only recently launched its delivering some fantastic customer results, see below, accelerating time to first prototype and delivering the highest performance. This was a customer design, 48 Million ASIC gates, four Xilinx Virtex-7 FPGAs. ProtoCompiler is fully integrated with HAPS leveraging its strengths. HAPS interconnect can be tailored based on the ProtoCompiler recommendations and ProtoCompiler understands the HAPS architecture and resources such as clocks and resets. ProtoCompiler is built around a stable code base of Synopsys’ mature and unique compilation and synthesis engines delivering the highest QoR for out-of-the-box results.
A fully integrated solution delivers not only accelerated time to first prototype and highest performance but also reduces your effort as it’s doing the hard work for you. Just don’t tell your boss otherwise he will give you more work.
Posted in ASIC Verification, Early Software Development, HW/SW Integration, Man Hours Savings, System Validation | 2 Comments »
Posted by Michael Posner on 16th May 2014
Achieving first pass silicon success is always the goal of the project. While a company may plan for a second chip spin they really want first pass silicon success enabling reduced cost and earlier time to market. I ran across this video featuring Peraso and Eric from the DesignWare USB team, http://youtu.be/DyNyZP8Ysj4 . Now while Peraso do not claim first pass success bringing up a chip in the lab in 24 hours is amazing. Peraso used HAPS FPGA-based prototypes for system validation enabling them to test their software with their RTL implementation before they taped out. As you can tell from the video, Peraso were very, very happy with the fact that they had the silicon up and running in such a short period.
While we are on the subject of videos, here is another featuring the DesignWare HDMI IP and the HAPS-60 series systems. http://youtu.be/Ao-JeWz9g0A
These examples show the power of HAPS for reducing project risk, achieving first pass silicon success and exhibit high performance enabling the validation of very high speed real world interface.
Honestly I’m a little tired this week so I’m going to keep this blog short. A couple of weeks ago I did get the chance to take out one of the best off-road vehicles on the market. While I am used to far more horse power, this one horse power proved sufficient for the activity and we climbed some terrain that not many other modes of transport could reach. Unlike my other hobbies this trek was very relaxing. In addition I did not burn any fossil fuels in the process.
Do you want to meet me in person? Are you going to DAC? If the answer is yes to both drop me a comment and let me know and I’ll be happy to meet.
Posted in ASIC Verification, Early Software Development, HW/SW Integration, In-System Software Validation, IP Validation, Mick's Projects, Milestones, Project management, Real Time Prototyping, System Validation | Comments Off
Posted by Michael Posner on 2nd May 2014
This week I was asked to clarify what the PCIe Gen3 protocol speed is, to confirm, PCIe Gen3 speed is 8Gb/s per lane. PCIe Gen 1 is 2.5Gb/s and PCIe Gen2 is 5Gb/s. Yes I know I’m usually seen as the prototyping guy, (Or Mick “I’m not dead yet” Posner thanks to my pneumonia) but I also happen to double up as a protocol expert. One of the key advantages of FPGA-Based prototyping is the ability to model real world interfaces at speed so to be a prototyping expert you basically have to be a protocol expert as well. The above eye diagram (click image to view full size) is measured on the HAPS-70 (-2) speed grade systems running one of the many DesignWare PCIe Gen3 controller validation tests for interoperability and compliance testing. That is a good looking wide open eye!
I sneaked into the lab and snapped off this picture. (Click on image to view full size)
The little HAPS-70 S12 (-2) speed grade system is perched on top and that large black cable sticking out is the PCIe Gen3 capable cable connection. The cable plugs into a PCIe Gen3 host adapter board that in turn plugs into the host machine. In this specific setup I was told that we have the DesignWare PCIe Gen3 End Point controller modeled in a x4 lane configuration. Yes that’s x4 lanes of PCIe Gen3 so x4 lanes of 8Gb/s. I’m going to try and have the R&D engineer do a little video for me of the system in action as it was very impressive.
Oh, when using the Xilinx built in transceivers (Rocket IO) as the physical link the (-2) speed grade systems are required to model PCIe Gen3. The (-1) Xilinx Virtex-7 2000T devices only support up to 6.6 Gb/s while the (-2) support up to 10.3125 Gb/s thus supporting PCIe Gen3 speeds. Looking for PCIe Gen3 expert advice, go check out the Express Yourself blog
Off topic, spring has sprung in Oregon !! Yay, it was here for a whole 4 days and now we are expecting rain again. This is fine, this is what you expect and grow to love when living in Oregon. The mix of sun and rain makes everything really green, just look at how beautiful this little baby fern is. This is growing in my yard along with a huge amount of moss which is also typical across Oregon.
Click on image to view full size
Posted in ASIC Verification, FPGA-Based Prototyping, IP Validation, System Validation, Technical, Use Modes | Comments Off
| © 2014 Synopsys, Inc. All Rights Reserved.