HOME    COMMUNITY    BLOGS & FORUMS    Breaking The Three Laws
Breaking The Three Laws
  • About

    Breaking the Three Laws is dedicated to discussing technically challenging ASIC prototyping problems and sharing solutions.
  • About the Author

    Michael (Mick) Posner joined Synopsys in 1994 and is currently Director of Product Marketing for Synopsys' FPGA-Based Prototyping Solutions. Previously, he has held various product marketing, application consultant and technical marketing manager positions at Synopsys. He holds a Bachelor Degree in Electronic and Computer Engineering from the University of Brighton, England.

Archive for the 'ASIC Verification' Category

The Prototyping Rub from SNUG San Jose

Posted by Michael Posner on 27th March 2014


It was the Synopsys Users Group, SNUG in San Jose this week and on top of the Synopsys announcement on ICC 2.0 with the Powar (I know this is a typo but I enjoy saying the word like this, you try it Powarrrrrr) of 10x there was a whole track dedicated to FPGA-Based prototyping. Knowing that the whole world does not revolve around California I thought I would provide you with an overview of the days FPGA-base prototyping sessions. As a reminder if you have an active Synopsys SolvNet account you can download the session presentations and papers shortly after the event ends

The day started with : Automating SoC RTL to Operational Prototype – Synopsys R&D Presentation

This session delivered technical information on new Synopsys prototyping software that increases the level of automation and streamlines RTL to operational HAPS FPGA-based prototyping including ultrafast partitioning. I personally think this session might have been a little too technical (is there such a thing) as it jumped into how the software solved the problems but seemed to skip the explanation of the problem itself. Now for experienced prototypers they immediately saw the benefits being delivered but I think some of the more in-experienced prototypers were in over their heads. Even with this in mind I highly recommend this presentation. Using this software the user can see up to a 50% reduction in time to prototype, achieve on average 2X or more performance improvement in system performance and get greater debug visibility.

Next up: Achieving Maximum System Performance on Multi-FPGA designs using HAPS-70 System – SanDisk use of HAPS-70 for an enterprise SSD SoC

Two words, killer presentation. I love seeing real users present their experience with FPGA-based prototyping systems. This presentation included the various steps that SanDisk used to bring up the HAPS-70 FPGA-based prototype of their enterprise SSD design and then optimize it for the highest system performance possible within the limitation of the SoC design constraints. It was very interesting and I recommend the presentation as it includes lots of great real world information on what it takes to create a full SoC FPGA-based prototype. The picture above was snuck off without anyone noticing (until now) pictures/videos within the sessions is prohibited. (whoops)

Final presentation of the day was: Putting IP and Subsystem Prototyping on the Fast Track – Synopsys Mick Posner (yes that’s me) and Antonio Costa from the DesignWare IP R&D team.

I came prepared with giveaway’s to bribe the audience for good feedback, we will have to wait and see if that worked. I introduced HAPS-DX for complex IP and Subsystem prototyping and tried to explain the various validation use modes and best practices for IP prototyping to streamline hand-off to the SoC team streamlining their prototyping efforts. I then handed over to Antonio who provided details on how the DesignWare IP R&D utilize the many generations of HAPS systems to validate the IP. I think the bits that resonated the best with the audience was Antonio’s explanation of the validation scenarios that could only be reached using FPGA-based prototyping. Antonio also introduced the IP R&D teams use of HAPS Deep Trace Debug to capture seconds of debug visibility enabling long protocol scenarios to be successfully debugged.

I highly recommend that you download these SNUG presentations on FPGA-based prototyping from SolvNet.

Progress on my latest garage project has been slowed by business travel and sickness. But I have made some progress and am happy to say that basic functionally has been validated.

If you can’t recognize what it is from this picture then let me tell you that it’s a custom designed remote control tracked vehicle with full suspension tracks. I designed the track runner system and this picture is of revision 2.0. It’s not perfect but it does the job and I can see a 3.0 revision to get better articulation. When finished I’ll take a little video if it in action, it’s a lot of fun. Here is a preview of the vehicle in action: https://www.youtube.com/watch?v=yF4uRSzL5qQ 

Some has asked me where I find time to do projects like this, the answer is I don’t find time but I manage to fit in a little here and there at the expense of other things like family time, house projects, eating…. I’m going to slow down on the project as family time, house projects and eating should really take priority.

Posted in ASIC Verification, Bug Hunting, Debug, Early Software Development, FPGA-Based Prototyping, HW/SW Integration, In-System Software Validation, IP Validation, Mick's Projects, System Validation, Use Modes | No Comments »

Prototyping wearables and the Internet of Things (IoT)

Posted by Michael Posner on 16th March 2014

Is this the future of wearable technology?

LOL, no…. well maybe…..

There are lots of questions on if wearables will bring the end of the Smartphone, I personally think these two technologies will co-exist. I like the idea of wearing my technology but there are many people that don’t thus there should be a place for both technologies for a while yet. Of course for anyone who travels a lot like me they will know that the airport security creates a new issue not previously encountered. I use a fitbit which is a small step tracker and I wear this on my trouser (pant) pocket. It pretty much lives in this spot and I’ve almost put it through the washing machine when I’ve forgotten to take it off. The problem is that this little device has become a part of my life and when going through airport security I’ve also forgotten to take it off which leads to an extra search pat down. A simple solution to this would be for me to remember to take it off but it would be nice if these devices are security certified of something like that.

When it comes to prototyping these deeply embedded SoC designs you will find out that while the form factor is small and simple the SoC designs are not. These designs are multi-million ASIC gates so when they are prototyped using FPGA’s the challenges of handling non-FPGA code, multi-FPGA partitioning and prototype assembly must be overcome. I visited a load of customers last week while traveling internationally and the common theme at the meetings was discussion around how to enable complex FPGA-based prototyping without the need for in-depth specific expertise. The first place to start is to put a methodology in place to define a flow supporting FPGA-based prototyping making a part of the larger SoC project. The FPGA-based Prototyping Methodology Manual, FPMM, is the perfect place to start in defining what is needed as part of this flow.  

I had the pleasure of traveling with Rene Richter, one of the co-authors of the FPMM. In the picture above you can see him explaining the basis of multi-FPGA partitioning and how to utilize pin multiplexing. His expertise helped a lot of customers last week but he was the first to say that everything he explained was already documented in the FPMM.

This week’s call to action, download the FPMM if you have not already done so………… and read it.

I was thinking that it might be time to work on the 2nd revision, updating the FPMM with information on how FPGA-based prototyping has evolved over the last couple of years, what do you think? What do you think has changed in FPGA-based prototyping which should be documented?

Posted in ASIC Verification, FPGA-Based Prototyping, FPMM Methods, Getting Started, Technical, Tips and Traps | No Comments »

Super UltraOcta cores with ARM CPU and Imagination GPU’s boosted with FPGA-Based Prototypes

Posted by Michael Posner on 28th February 2014

Recently All Winner announced that their new UltraOcta A80 Mobile application processor utilizing the Imagination PowerVR 6230 64-core GPU would be coming to mobile devices very soon. (I call this the Super UltraOcta just for the effect)


Maybe not many people know this but All Winner utilized HAPS-70, the Xilinx Virtex-7 2000T based systems as part of the development and validation cycle for the A80 Octa SoC


The All Winner SoC features eight ARM(R) processor cores in a big.LITTLE(tm) processing configuration as well as the Imagination PowerVR GPU core. With both CPU and GPU you end up with a lot of hardware/software interaction which we know requires extensive validation to ensure that both the hardware and software are bug free. The high performance of the HAPS FPGA-based prototype enabled a huge volume of tests to be run which are needed to flush out those hard to find bugs.  

All Winner’s eight core-based SoC demanded a high performance validation solution to speed validation of their this SoC design. HAPS FPGA-based prototypes are the proven and essential methodology to perform large SoC validation tasks. HAPS delivered the performance needed to validate Allwinner’s A80 Octa SoC. The complexity of Allwinner’s SoC increased both cost and schedule risks due to the need to verify real-world scenarios early in the development cycle. HAPS mitigated those challenges as a cost effective solution that achieved the performance required to validate Allwinner’s SoC, while reducing ASIC design time and cutting months off their development schedule

I went looking on the WWW for a block diagram of this chip but as it’s so new I could not find anything, what I did find on the following link was an different multi-media design from MediaTek http://www.engadget.com/2013/07/29/mediatek-mt8135-biglittle-mp-powervr-series6-g6200/

I’m sure the All Winner and MediaTek designs are different in various ways but we can use this block diagram (on the linked page) to talk about the main componets. You have the ARM CPU and Imagination GPU but you can see all the other standard interfaces such as MIPI, DDR3, LPDDR, USB and a whole bunch of sensor interfaces. The strength of FPGA-based prototyping as mentioned above is perfromance and real world IO. Mobile multi-media designs like this are a perfect fit for FPGA-based prototyping due to the real world interface testing need as well as the challenge to validate the CPU to GPU connectivity. CPUs can be abstrated and run at incredible high performance as virtualized models but GPUs are not a goot fit for abstraction like this. GPUs require full cycle accuracy which is why FPGA-based prototyping is perfect fit for modeling them.

One problem of modeling GPUs on FPGA-based prototypes is the fact that the GPU is typically far bigger than a single FPGA (Hey, that’s one of the Breaking the Three Law’s for FPGA-Based Prototyping). This is where the HAPS Multi-FPGA systems step in and help solve the problem. First the HAPS software tools are used to partition the GPU design across multiple FPGA’s. Belows block diagram is an abstracted diagram of a typical GPU partition. Note the 1000’s of signals between FPGA’s. FPGA’s don’t have this many physical pins so the HAPS High Speed Time Domain multiplexing needs to be used to package up the signals and send them between FPGA’s using a high speed 1Gb/s link.

The HAPS-70 flexible interconnect architecture (Blog on this capability) is utilized to create an interconnect that has increased density where needed to help reduce the overall mux ratio. (Lower mux ratio, higher the system performance) Between this capability and the HAPS HSTDM the resulting platform is optimized and high performance. A GPU partition like the above on HAPS can run in the range of up to 15 MHz which is amazing.

How fast are you running your GPU cores?

Off subject, last week my son was asked to draw a picture of one of their parents hobbies. Finn decided to draw a picture of me and my race car hobby, one of the drawings is below.

I’m not sure where he got the idea that my car racing included using a fire extinguisher to put out engine fires ;) Click the idea link to see a short video of just one case which might have lead him to think this.

Posted in ASIC Verification, Bug Hunting, Early Software Development, In-System Software Validation, System Validation | Comments Off


Posted by Michael Posner on 22nd February 2014

I’ve been traveling in Europe popping into see various FPGA-based prototypers. It’s been a good week of lively discussion covering all aspects of prototyping from mapping RTL to prototype, to higher debug visibility and Hybrid Prototyping. At a number of these visits we discussed IP validation using the PCIe connected use model. I’ve discussed this use mode a number of times, in summary an IP block is placed in the FPGA-Based Prototype and then a PCIe end point core is used to memory map the IP across to a host machine. Typically the IP has a standard SoC bus interface such as AMBA so a bridge from AMBA to a PCIe core is used.  

The PCIe connected mode is delivered as part of the HAPS-DX complex IP and subsystem prototyping system. A automated insertion solution is delivered as part of the HAPS-DX prototyping software tools flow. The users can select the PCIe connected use mode and the software tools will insert a PCIe end point into the prototype. Hey presto, it’s easy to deploy the PCIe connected mode. Now while HAPS-DX meets the need for many IP’s I spoke to a number of customers who’s IP blocks were far, far larger than the capacity of the HAPS-DX, 4 Million ASIC gates. The good news is that the PCIe connected mode can be used with any of the HAPS-70 series as well. On the HAPS-70 systems the multi-gigabyte (MGB) connectors are used with a cable based connection to a host machine. With the HAPS-70 capacity scaling to 288 Million ASIC Gates (more on this in a later blog) you have plenty of space for even the biggest IP blocks.

The great thing about the PCIe connected mode is that the IP can be stressed tested in a similar fashion to simulation unit testing, the difference is of course the performance of the FPGA-based prototype enables far more testing to be achieved. This is perfect for the IP developers and the software engineers as they have a high performance realistic model to work against.

Don’t forget that at some point the IP needs to be integrated into the SoC so that the IP can be validated in the context of the SoC infrastructure.

For all the Irish and American Irish readers, the Guinness is better in Ireland, YUM

Posted in ASIC Verification, Debug, Early Software Development, IP Validation, Use Modes | Comments Off

How To: Enable Early Software Development, Find Critical Bugs and Save Up To 6 Staff Months of Effort

Posted by Michael Posner on 25th January 2014

Enabling early software development, finding critical bugs while saving up to 6 staff months of effort sounds like the holy grail of the design and validation. The funny thing is that it’s not a mythical creature, this is the reality of FPGA-based prototyping, specifically HAPS FPGA-based prototyping solution.

Synopsys surveyed it’s HAPS customers (Using a 3rd party called TechValidate) and asked them to describe the value they get from using HAPS. The results in my opinion were pretty overwhelmingly positive. Here is a snippet of the results.

HAPS enables early software development

HAPS helped discover critical bugs

HAPS saves up to 6 months of development effort

All the other results can be found here:


These results show why so many companies utilize HAPS. I’m feeling lonely, please comment on the value you get from HAPS so that I have something to blog about next week

Posted in ASIC Verification, Bug Hunting, Debug, Early Software Development, In-System Software Validation, Man Hours Savings | Comments Off

Tear down of the new HAPS-DX FPGA-based prototyping system

Posted by Michael Posner on 20th December 2013

I’ve talked about streamlining IP to SoC prototyping and the use modes that prototypers use for IP validation. This week Synopsys announced the new HAPS Developer eXpress (HAPS-DX) prototyping system. This new HAPS-DX system is perfect for complex IP and subsystem prototyping and ties in nicely with the flow that I have been blogging about for streamlining IP to SoC. Similar to what I did last week with the Xilinx press release I thought I would do a tear down and cut to the chase and detail how HAPS-DX will benefit you.

Oh just so you know, this is a super long blog as I’m going to be on vacation over Christmas and New Year and won’t be blogging for a couple of weeks. With this blog being so long it will take you until 2014 to read. Please, please, please take the time to read it over hot coco and biscuits.

HAPS-DX is targeted at complex IP and subsystem prototyping and its 4 million ASIC gate capacity is perfect for this usage. I know this as Synopsys is the #1 Interface IP provider with DesignWare IP and all these IP’s will fit nicely inside of HAPS-DX. I expect we will see more use of HAPS-DX with DesignWare IP in the future… Using a smaller FPGA with a more basic board form factor means that the price point of HAPS-DX is in line with the expectations of the teams doing complex IP and subsystem prototyping. Complex IP and block design teams are usually more cost sensitive than the wealthy SoC team. Our customers love the HAPS prototyping capabilities but some others think the price of HAPS puts it out of their reach and they have to make do with inferior solutions. Enter HAPS-DX, yay, HAPS premium prototyping capabilities at a price point that satisfies everyone. Contact your local and friendly Synopsys sales person for specific pricing.

A platform like HAPS-DX is essential as more and more IP blocks will be making up the full SoC. To accelerate the time to market of the SoC you need to accelerate all parts of the design and validation tasks starting at the IP level. If you can accelerate the early tasks you can start other SoC activities earlier such as SoC integration and early software development.

Below are the highlights from the press release, which I’ll use these as the main tear down points from this point on.


  1. HAPS Developer eXpress (HAPS-DX) supports up to four million ASIC gates and easily integrates with HAPS-70 systems to enable seamless software development, hardware/software integration and system validation from IP to complete SoCs
  2. HAPS-DX includes optimized software for FPGA synthesis, debug and clock optimization supporting fast prototyping modes to accelerate time-to-first prototype
  3. Superior debug capabilities are built in with HAPS Deep Trace Debug, which can store seconds of signal trace data, and supports Synopsys Verdi, which delivers superior debug visualization
  4. Pre-validated DesignWare IP and access to a broad portfolio of HAPS daughter boards and FPGA Mezzanine Cards (FMCs) enable the quick assembly of prototypes
  5. Included Synopsys Universal Multi-Resource Bus (UMRBus) interface enables hybrid prototyping by providing a seamless connection between HAPS and Synopsys Virtualizer-based virtual prototypes for pre-RTL software development

I numbered the points so it’s easier to refer back to them in the blog. Starting where you would expect me to start, with #1,this point is all about enabling a seamless flow from IP to SoC prototyping. The HAPS-DX is targeted at complex IP and subsystem prototyping but that IP or subsystem usually ends up in an SoC and the last thing you want to do is to repeat the prototyping effort at the SoC level for those same blocks. HAPS-DX was developed with the streamlining of IP to SoC prototyping in mind. HAPS-DX provides reusable hardware and a software flow that is interoperable within a greater SoC project.

As pictured above the HAPS-DX was designed with reuse in mind. The HAPS-DX can be used directly as a daughter board connected to the larger HAPS-70 systems. This means that if IP prototyping is done right the same setup can be quickly incorporated into the SoC level prototype. This translates to reduced effort for the SoC team as the IP team did most of the work for them. The hardware needs to be able to support this usage and a methodology of planning for IP to SoC prototyping needs to be deployed. See here for my previous blog on IP to SoC prototyping. You can use the HAPS High-Speed Time-Domain Multiplexing between HAPS-DX and the HAPS-70 meaning that you are not limited to physical pin connectivity. HAPS HSTDM enables many signals to be packaged up and sent across the high performance link. Value summary: Start software development earlier from SoC prototype being operational earlier.

#2 is going to be a HUGE benefit to the complex IP/Subsystem prototyping teams as well as the SoC teams in the future. Along with HAPS-DX you get prototyping specific software customized for HAPS-DX at extra charge, which is an immediate cost benefit that I know everyone will like. More importantly this software specifically addresses the needs of the ASIC IP and subsystem prototypers, which are a little different than that of pure FPGA synthesis users. As talked about in this blog, the needs of prototypers are different than the needs of a designer targeting an FPGA as part of their final product. This new HAPS software is specifically architected to address the challenges of time to operational prototype, performance, debug and productivity. With this new software you should be able to get the HAPS system up and running faster meaning you get a gain of time to market and as mentioned earlier you can start the SoC integration tasks earlier.

This new HAPS software incorporates the core unique Synopsys technologies along with a new set of capabilities specifically addressing prototyping challenges. At the start of the prototyping project the prototyping engineer is not so worried about squeezing the optimum performance out of the FPGA. They really want to get to a functional prototype as quickly as possible so they have something to hand off to keep the software developers or validation team happy. Once they have handed off that image they can work on optimizing the prototype. The HAPS-DX software delivers on both with capabilities customized for time to first operational prototype and a path to high performance.

What’s not mentioned here directly is that the new software is very ASIC flow like rather than FPGA like. We see a trend that companies no longer have specific “FPGA experts” for prototyping; they use the same validation engineers that are used to working with Design Compiler synthesis scripts and VCS simulators. The HAPS-DX software provides a more ASIC like design flow with bottom up design flow, TCL scripting and multi-processing for improved productivity. FPGA-based prototyping software tools have grown up. Value summary: Start IP validation and software development earlier from earlier prototype availability

#3 is all about debug and the bottom line is that with HAPS-DX you are going to get greater debug visibility, which means you should be able to track down the source of the bug faster and productivity should go up. Debug is a hot topic with respect to FPGA-based prototyping and while there have been point tool solutions trying to solve the problem in the past, the HAPS-DX was designed with the need of debug built right in.

When debugging you want greater visibility and the capability to store more trace data. In a simulator you have almost infinite trace data storage, but in hardware you are limited to the physical storage medium. HAPS-DX delivers software that automates the insertion of debug instrumentation providing a simulator like experience in addition to integrated HAPS Deep Trace Debug built right onto the hardware. This is not a new concept for HAPS, I’ve blogged about these capabilities before, here and here. What is new is that HAPS-DX has it all built-in to both the physical hardware and the included software flow. Now you can quickly add debug capabilities into your prototype right from the get go of the project rather than adding it later when someone is beating on your door for more visibility to find the root cause of a bug.

Here you can see the DDR3 memory directly built into (and supplied with) HAPS-DX. I spoke to the engineer who spearheaded the HAPS Deep Trace Debug capabilities and asked him for an example of the benefit to users. He’s an engineer and answered me in engineering terms. His answer was “Think 128 signals captured at 100 MHz, you have the capability to store 5 seconds of trace data on the 8GB DDR3”. 5 seconds of trace data !!!!! That’s huge in the world of at speed debug. Add to that the fact you can write out FSDB which is the native waveform database for the Verdi debug tool. Verdi is used extensively in the ASIC debug space and now you can use the same capabilities with your HAPS-DX prototype. If you have access to Siloti you can also use the visibility expansion capabilities and get close to 100% visibility of select modules. Value summary: Higher productivity from ability to find and fix bugs faster

#4 is all about easing prototype assembly which I blogged about recently as well (you would almost think I planned all these blogs). I’m won’t comment on the DesignWare IP support, as mentioned above I’ll save that for a future blog. What is important to you is that HAPS-DX supports both the validation modes that you use and enables a huge range of hardware daughter boards so you can tailor the system to your specific project needs. HAPS-DX supports the traditional standalone mode, PCIe connected and the emerging hybrid prototyping use modes. I expect that hybrid is going to be a popular use mode for HAPS-DX as you can immerse the IP in a virtual representation of the SoC without having the actual RTL.

The alternative to buying HAPS-DX would be building a specific FPGA board that meets your project’s needs; it’s the age old make vs. buy. Most engineers think that designing a single FPGA platform is easy, and for an experienced designer it might be. The board can be designed with the needed interfaces built right onto it keeping it cheap to deploy. However, I know many teams that have designed great FPGA boards but still got burnt during the active project. The issue is marketing. Yep, the marketing team comes in with a late change request, the latest example I heard was a shift from USB 2.0 to USB 3.0, and unfortunately the hardware didn’t support the new requirement. The team had to scramble, redesign the boards and the project slipped 3-6 months. Yuck. HAPS-DX’s advantage is that it supports both HapsTrak 3, the same connector standard used with HAPS-70, as well as providing an FMC interface module.

With HT3 you get to pull from the large portfolio of available Synopsys daughter boards and others from 3rd party vendors that provide specialized daughter boards for HAPS systems such as Gigafirm, who I visited while I was in Japan and highlighted in this blog. In addition, the FMC interface module enables you to utilize the HUGE range of FMC style daughter boards available. There are literally 100’s (no joke I counted) of available FMC daughter boards available enabling AD/DA, serial connectivity, imaging processing and many, many more. Basically you get to tailor HAPS-DX the way you like it. It doesn’t get easier than that and even that pesky marketing team can come in and change the requirements on you at the last minute or worse mid project and all it not lost. Simply reconfigure HAPS-DX with a new daughter board expanding its usage to the new requirement. And if that was not enough, when the next project comes along you can reuse HAPS-DX assembled with a new set of daughter boards meeting the requirements of the new project. Value summary: Easy prototype assembly reduces effort and greater reuse increases return on investment

Finally, #5 is all about the more advanced use modes. The HAPS Universal Multi-Resource Bus, UMRBus, is the gateway to connecting the HAPS prototype to host machines. The UMRBus capability is built directly into the HAPS-DX meaning no add-on cost and comes with a set of example designs easing the setup of the prototype. As mentioned above, the hybrid use mode is getting more and more popular especially for IP validation. While it was once fine to validate a block outside of the context of an SoC, the CPU and software have become essential as part of the validation of the IP or subsystem. You actually need to validate the real software against the IP to know that it operates correctly. Enter the PCIe connected modes and hybrid prototyping. These operation modes enable software to be run on a host and executed on the real hardware representation of HAPS-DX. In the hybrid mode you model the system in a virtual prototype such as Virtualizer and then communicate to the HAPS-DX via the UMRBus. Synopsys already provides a library of transactors which act as the translation between the SystemC environment and the signal and pin toggling needed in real hardware. You immerse the IP in a realistic representation of the real SoC ensuring that when the IP is integrated into the larger SoC you already have high confidence that it’s fully operational. Value summary: Greater productivity from rapid deployment of advanced use modes

Oh boy, this blog is huge……. please, please, please take the time to read it. Of course if you are reading this then you have made it to the bottom, congratulations.

So summing up, with HAPS-DX you get a flow from IP to SoC, prototyping software that accelerates the time to first operational prototype, built in debug for greater debug visibility, fast prototyping assembly with HT3 and FMC daughter boards and the support for all expected prototype use modes. Actually the press release bullets nailed the benefits. I still think my tear down of the points will help explain better how each of these benefits affects you more directly.

  • HAPS-DX increases your productivity, making your manager happy
  • HAPS-DX reduces your effort, making you happy
  • HAPS-DX reduces your risk, making everyone happy

Happy Holidays

Posted in ASIC Verification, Debug, FPGA-Based Prototyping, Getting Started, Technical | Comments Off

Xilinx FPGA’s for FPGA-Based Prototyping

Posted by Michael Posner on 14th December 2013

If we look at the FPMM survey respondent data it’s clear to see that the favored FPGA device for FPGA-based prototyping is Xilinx devices

This week Xilinx announced the Virtex® UltraScale™ VU440 3D IC.


This is the device that Xilinx wants the future generation of FPGA-based prototyping hardware to make use of. Rather than spending too much time picking apart the announcement I’m going to try and summarize it in my own words. Then I’m going to share my blog with friends over at Xilinx and request that they expand on my points and add anything that I missed in a guest blog.

In my humble opinion the key capabilities specific to FPAG-based prototypers are:-

  • Capacity
  • Routing resources
  • Clocking structure

 So starting with capacity, the VU440 is a whopper of a large FPGA, Xilinx claims 50 Million equivalent ASIC gates. I think this claim is a bit of a whopper, as in I personally do not think that you could map a 50 Million ASIC gate design into this device. Each FPGA vendor counts ASIC gate equivalent slightly differently so it’s very hard to compare ASIC technology gates to FPGA equivalent ASIC gates. For example Synopsys uses the Xilinx Virtex-7 2000T in its HAPS-70 series and we publicize 12 Million ASIC gate capacity per FPGA. This calculation of ASIC gates has come from the 10+ years of experience in FPGA-based prototyping. We claimed 2 million ASIC gate capacity of the Virtex-5 330, 4.5 million ASIC gates for the Virtex-6 760 and as stated above, 12 million ASIC gates for the Virtex-7 2000T. Our customers don’t complain that their ASIC RTL does not fit into our systems so we feel confident that our calculation of ASIC gate equivalent is pretty spot on.

Regardless of the ASIC gate counting differences the VU440 is over double the size of the 2000T meaning that we expect it to provide over 25 Million ASIC gate capacity per FPGA. This is great for FPGA-based prototypers as by the time this device is available the designs being prototyped will need this capacity increase. During the transition from V5 to V6 and V6 to V7 we saw no consolidation of systems, as in for example a customer using a dual FPGA system did not move to a single FPGA system with the new FPGA which had double the capacity, they moved to the dual FPGA system with the new FPGA. Some customers even moved to larger systems such as from the 4 to the 8 FPGA system. This tells me that the size of the designs was scaling at a faster rate than the FPGA technology. I expect this to be true in the future to.

Routing resources is very important to FPGA-based prototyping as the code that is being thrown at these devices is ASIC RTL and not specifically “tuned” for FPGA. The requirement of translating ASIC RTL to FPGA is driving the need for prototyping specific software tools that are geared towards solving this ASIC to FPGA translation with reduced turn-around. While FPGA implementers who’s final product utilizes the FPGA device prototypers mostly don’t care what the device is they want to get a model up and running fast so they can quickly enable their software developers. Look at the FPMM survey responses below, mapping ASIC RTL to FPGA is still the #1 challenge by a long way. I’m going to blog about this need more in the future.

Staying on track with routing Xilinx states that the new VU440 has a greater number of passive interposer interconnect (features 5x more inter-die bandwidth). This is a 3D device so it has multiple Super Logic Regions (SLR’s) which connect to each other via this passive interconnect. With more interconnect the users should see faster fitting times, (FPGA Place & Route) from the higher number of possible solutions available. This increased interconnect should also result in greater utilization (Xilinx claiming up to 90%) which means you can stuff more into the device.

Finally clocking, Xilinx is claiming “ASIC like” new clocking structures and clock routes that span SLR boundaries. This is really important to FPGA-based prototypers as the code that is being targeted to these devices is ASIC RTL so by nature is designed with ASIC style clock trees. With the new Xilinx architecture being closer to ASIC clocking the designs *should* translate better into the FPGA device. Don’t take my word for it, look at the FPMM survey responses below, translating ASIC clocks to FPGA is the #2 challenge identified. Xilinx’s ASIC like clocking will potentially ease the support for ASIC clocking structures and with the new higher number of available clocks even ASIC’s with thousands of clocks should be easier to target to this new FPGA.

This combined with the clocks that now span SLR boundaries means that higher performance should be achievable. Of course don’t forget that the overall system performance of an FPGA-based prototype is usually not dictated by the single FPGA performance but by the interconnect between the FPGA’s and the pin multiplexing (when you have more signals between FPGA’s than pins). This is why Synopsys offers HAPS High Speed Time-Domain Multiplexing, HAPS HSTDM, which packages up signals and transfers them between FPGA’s are Gigabit speeds. The use of HAPS HSTDM is almost transparent to the users when they use the Synopsys tools which automate the insertion of the HAPS HSTDM IP.

WOW, this blog got long…….

So to summarize the new Xilinx UltraScale VU440 FPGA looks like it will be very exciting for FPGA-Based Prototypers. I am also looking forward to seeing how Altera responds to this <insert evil grin here>.

What is your opinion of the new Xilinx device? Post a comment and let me know.

Now off topic, I finished the toy I have been making for my son, the Command Module. I think it turned out very well. It has plenty of switches, dials and interactive buttons to ensure that when mixed with a little imagination it can be turned into anything my son can think of. Here is a video of it in action: https://www.youtube.com/watch?v=SxyXtHnBkMQ 

Posted in ASIC Verification, FPGA-Based Prototyping, Mick's Projects | Comments Off

System Validation and Compliance Testing of PCIe Gen3

Posted by Michael Posner on 29th November 2013

While wandering though the DesignWare IP testing lab in our office I found this:-

It’s sort of hard to see but this is a HAPS-70 S12 platform connected to a LeCroy PCIe protocol and electrical compliance tester. The DesignWare PCIe controller core has been implemented in the FPGA and in this setup is using the FPGA devices transceivers for the electrical interface. The split between the DesignWare controller and the Xilinx transceivers is at the PIPE interface.

The pod sitting on top of the HAPS-70 is the Universal Multi-Resource Bus pod, which enables remote access, high speed configuration and dynamic debug capabilities.

I’m pretty sure the setup was being used for PCIe Gen 3 compliance testing in preparation for an upcoming PCIe SIG meeting.

The DesignWare PCIe core is designed for SoC usage and the testing on the HAPS platform provides a reference that the core has been hardware validated and compliance tested. This is of course without having to harden it in silicon so the HAPS setup is a far more flexible solution for the digital controllers. It was great to see the HAPS technology being used to benefit our own teams at Synopsys.

Short blog this week as I am currently digesting turkey from the USA thanksgiving and need to take a little nap.

Posted in ASIC Verification | Comments Off

Prototyping Cutting Edge Standards – 10G USB 3.1 Host and Device

Posted by Michael Posner on 8th November 2013

As we all know FPGA-based prototyping enables early software development, HW/SW integration and system validation but did you also know that HAPS FPGA-based prototyping is also designed to make Eric Huang, PMM for USB IP at Synopsys famous? I’ll be honest, when we designed the HAPS-70 systems we did not highlight this as part of the MRD which shows that sometimes capabilities evolve on their own.

The HAPS-70 is making Eric famous as it’s being used by his R&D team to validate and demonstrate the new 10G USB 3.1 standard. Eric recently published a video documenting the first platform to platform demonstration of 10G USB 3.1 and it’s powered by HAPS-70’s. (Eric-Hollywood-Huang we call him in the office now). There are some very pretty models in the video, HAPS-70 based prototyping models that is. The HAPS-70′s are the real star’s of this video :)

Eric and his R&D team have been working on 10G USB 3.1 for a while now and a couple of weeks back I cornered Eric in the lab to quiz him on the HAPS-70 usage. The HAPS-70 FPGA-base prototyping solution enabled this team to rapidly develop a validation platform and enabled this demonstration. I’ve mention this before but FPGA-based prototyping is the single best way to wow a customer with functionality implemented in hardware giving the demonstration high credibility.

The Synopsys DesignWare USB R&D team (the stars behind the scenes) were able to prototype both the 10G USB 3.1 Host and 10G USB 3.1 Device using the HAPS-70 platforms. The flexibility and capabilities of the HAPS-70 enables the USB R&D to quickly customize the platforms to meet the designs needs. One of the key parts of the development was a way to connect the two separate platforms together using a standard USB cable while transmitting and receiving at the new higher 10G rates. For this the DesignWare USB R&D developed a custom HAPS Multi-GigaBit daughter boards, MGB for short.

HAPS has had an MGB interface implemented for a number of generations now and there are available off the shelf daughter boards for it such as PCIe, Ethernet and SATA. It’s a very well documented simple daughter board interface with reference designs and the DWC USB R&D team were able to develop this custom USB 3.1 MGB in about two weeks. Now that’s rapid prototyping.

In the 10G USB 3.1 demo you can see that the demonstration uses host machines to run the software that is executing on the USB 3.1 cores. The DesignWare USB 3.1 IP team use the PCIe connected IP validation mode. If you remember I blogged about this IP validation usage mode a couple of months back. The PCIe connection is also hosted via the MGB, this time using the off-the-shelf HAPS PCIe MGB. It can be seen in the picture below, it’s the thick cable sticking out of the HAPS-70 and then connected into the host via a host adapter card. This connection is an off-the-shelf offering for Synopsys so it’s easy to deploy in your designs as well.

I’m going to visit Eric next week and see if I can encroach on his stardom and get myself into one of his videos.

I can’t wait for 10G USB 3.1 to go mainstream. USB 2.0 was revolutionary at the time and USB 3.0 at 5Gb/s was a huge leap forward. Copying files which took minutes with USB 2.0 then took mere seconds with USB 3.0. But then the files got bigger and the copy times started to increase. Hey presto… along comes 10G USB 3.1 to the rescue, yay. Super fast copy, sweet.

Posted in ASIC Verification, FPGA-Based Prototyping, In-System Software Validation, Tips and Traps | Comments Off

Superior debug visualization and efficiency

Posted by Michael Posner on 26th October 2013

I noticed that Synopsys launched the new Verdi3 which provides the capability to debug both the hardware RTL code and the Software C code. Here is a video demo of the new capabilities: http://www.synopsys.com/Tools/Verification/debug/Pages/verdi-hw-sw-debug-video.aspx

Verdi3 addresses the need for a simultaneous view of both hardware and software languages enabling designers to efficiently and effectively advance their debug productivity. So call me a geek but I think this is way cool. I think it’s so cool as I see this as a key new technology which will really benefit designers doing FPGA-based prototyping. The reason I say this is that FPGA-based prototyping is when you are executing key software modules against the hardware aiding in hardware validation and hardware/software integration. Having combined hardware and software debug visibility is going to help you track down the source of the bug much faster.

This is one of the key challenges engineers talk to me about. FPGA-based prototyping gives you the ability to run software against the hardware but when you do run into an issue it can sometimes take a long time working out if the issue is a result of hardware or the software. I’ve seen this at interoperability plug fests where we have the DesignWare IP running on HAPS enabling the IP to be put through the full interoperability testing. Many of the DesignWare IP’s are a combination of the hardware RTL and a software driver. When we run into an issue we have to quickly work out if the error source is our RTL, our software or the component that we are testing interoperability against. Historically we have used a mix of FPGA-base prototyping hardware debug tools such as Synopsys’ Identify and off-the-shelf software debuggers. I am sure we will be looking at utilizing the new Verdi3 in the future.

While we are talking about Synopsys’ Identify did you know that it includes an interface for Verdi? Well it does, extending the great Identify at-speed FPGA-based debug capabilities to Verdi (and visa-versa)

From Verdi you can write out a list of points that you want to add debug visibility and Identify uses this to instrument the RTL. Verdi can be used to automatically create a list of “essential signals” for a block or module. This list of essential signals is the minimum set that Verdi needs to provide 100% debug visibility to the module. Verdi does not require you to log all points as it can re-build the logic state of the others as long as it has the details of the essential signals. This is an amazing feature when added to the FPGA-based prototype. Logging just the essential signals minimizes the FPGA logic utilized for instrumentation while at the same time providing 100% visibility for debug.

The FPGA-based prototype runs at hardware speeds and Identify captures the signal trace data. Once you are finished you then simply export the Verdi FSDB for post processing.

The integration between Verdi and Identify is just one of the many debug capabilities that the engineers have at their fingertips. When using HAPS as the hardware platform you can combine the use of the HAPS Deep Trace Debug with the Verdi support providing the capability to store a huge amount of signal trace data.

Wow, how did this happen, this blog got huge (its Saturday morning) Do you do FPGA-based prototyping? (yes because you read my blog) Do you have access to Verdi? If the answer is yes I would like to hear about your experience in combining the two enabling superior debug visualization and efficiency.

Only lame spam this week. Well all spam is lame but this week was really lame.

Posted in ASIC Verification, Debug, FPGA-Based Prototyping, Tips and Traps | Comments Off