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' DesignWare USB Solutions. Previously, he was the Director of Product Marketing for Physical (FPGA-based) Prototyping and has held various product marketing, technical marketing manager and application consultant positions at Synopsys. He holds a Bachelor Degree in Electronic and Computer Engineering from the University of Brighton, England.

Archive for the 'FPGA-Based Prototyping' Category

Innovation Increases Design Visibility and Boosts Performance of FPGA-based Prototypes

Posted by Michael Posner on 29th April 2016

I just noticed (late) that the latest release of HAPS ProtoCompiler, 2016.03 is available. The new release can be found under SolvNet here. (A SolvNet ID and a valid HAPS ProtoCompiler license will be needed for download.)

The new release includes capabilities which reduce the time to first prototype even more than we do today, greater design visibility with new and automated debug features, automated performance boosting methods and many more like support for UPF 2.1 as blogged about a while back.

The two capabilities which caught my eye were the new HAPS Global State Visibility and the performance improving HAPS Timing Aware System Route.

HAPS Global State Visibibility

HAPS Global State Visibility, HAPS GSV, delivers a method to capture all register values in a non-intrusive fashion, meaning no instrumentation needed. This is an on-demand design visibility capability which is incredibly valuable to help debug issues immediately. Even better, you are not debugging complex FPGA specific register names, the HAPS ProtoCompiler flow maps the data back into the original RTL golden source namespace. So cool.

HAPS Timing Aware System Route

One of the other capabilities which impressed me (well done R&D), is the enhanced HAPS timing aware system route. The HAPS system route phase automatically selects the optimal multiplexing (HSTDM) ratios based on the over design and specific path’s slack. In most cases this new level of automation is delivering ~10% increase in the HAPS prototypes performance.

Look out for a new blog starting soon: https://blogs.synopsys.com/hittingthemark/

To SUBSCRIBE use the Subscribe link in the left hand navigation bar.

Posted in ASIC Verification, Bug Hunting, Debug, FPGA-Based Prototyping, HAPS-70, HAPS-80, Man Hours Savings, Performance Optimization, Real Time Prototyping, Tips and Traps, UltraScale | Comments Off

It’s not too late to attend SNUG Silicon valley

Posted by Michael Posner on 28th March 2016

Hey, it’s not too late to attend SNUG Silicon Valley: http://www.synopsys.com/Community/SNUG/Silicon%20Valley/pages/default.aspx


Prototyping topics:

  • Techniques Used to Partition a Complex-SoC into Multi-HAPS-70 System
  • FPGA Debug: Improving Debug Turnaround Time in High Speed Designs
  • Accelerate Your Prototyping Productivity Leveraging HAPS Integrated Prototyping Solution
  • Adapt, Port, and Integrate Quickly – Prototyping the Right Way
  • Address TTM by Prototyping and Validating SoC Design Using HAPS-70 System
  • Reduce Overall TAT and Increase System Performance of Prototype Using ProtoCompiler

Many of these are user presentations so not to be missed.

More details here: http://www.synopsys.com/Community/SNUG/Silicon%20Valley/Documents/snug-sv-2016-schedule3.pdf

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, Bug Hunting, Daughter Boards, Debug, DWC IP Prototyping Kits, Early Software Development, FPGA-Based Prototyping, FPMM Methods, Getting Started, HAPS-80, HW/SW Integration, In-System Software Validation, IP Validation, Man Hours Savings, Performance Optimization, Project management, Real Time Prototyping, Support, System Validation, Technical, Tips and Traps, UltraScale, Use Modes | 1 Comment »

Addressing the Dark Fibre of FPGA-Based Prototyping, Lighting the Dark FPGA’s

Posted by Michael Posner on 16th October 2015

The term “Dark Fibre (Fiber) refers to the additional lines/capacity of optical connections a carrier would install when they laid a new pipeline. These unlit optical connections were built in assuming the need for additional capacity in the future. The thinking was that it’s cheaper to do it all at once vs. adding lines/pipelines later. The problem is that this extra capacity is going to waste and while the main carrier was not using it, someone else could have.

(There is no difference in meaning between the word fiber and fibre. Fiber is the preferred spelling in American English, and fibre is preferred in all the other main varieties of English and as I am originally from the UK I’m ignoring spell check and using the fibre spelling)

We are seeing more and more users move their FPGA-based prototype hardware off their desks and into a shared resource location. HAPS with ProtoCompiler fully supports this emerging use model. The flexible Synopsys solution can be tailored (highest performance) to individual prototyping projects needs or configured in a more generic fashion for greater flexibility when there are many different teams accessing the system.

HAPS-80 with ProtoCompiler supports IP, Block, Subsystem and SoC level prototyping

Typically customers are building these installations using a standard form factor building block, the HAPS-70 S48 or the HAPS-80 S104. Thanks to the HAPS with ProtoCompiler modularity and scalability it’s easy to chain these to support SoC designs of not up to 1.6 Billion ASIC gates.

The HAPS-80 S104, 104 Million ASIC Gate, 4-FPGA form factor, modular and scalable prototyping system

The problem is that prototyped designs don’t always use up all of the FPGA’s available and you end up with Dark FPGA’s. Dark FPGA’s is capacity that is going to waste within the large array of resources, just like Dark Fibre. But let there be LIGHT,  enter HAPS with ProtoCompiler Multi-Design Mode

HAPS-80 with ProtoCompiler Multi-Design Mode

HAPS with ProtoCompiler Multi-Design Mode allows you to use up this extra capacity by sharing the HAPS Prototyping resources across multiple users and multiple designs. In the example below there are three users exercising four design utilizing a total of seven FPGA’s. The designs range from smaller IP or block level prototypes to larger subsystem or SoC level prototypes. No Dark FPGA’s. ProtoCompiler for HAPS manages most of the complexity to create these portable prototyping images in addition to the user following a documented methodology and best practices.

HAPS-80 with ProtoCompiler Multi-Design Mode Example. No Dark FPGA's

The HAPS systems were designed for desktop usage as well as rack mount as seen in the setup below.

HAPS-80's installed into a server rack. Hey, nice rack!

If you like this or other posts, send this URL to your friends and tell them to Subscribe.

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 FPGA-Based Prototyping, HAPS-80, Man Hours Savings, Milestones, Project management, Tips and Traps, UltraScale, Use Modes | Comments Off

Overcoming the three phases of prototype bring-up

Posted by Michael Posner on 25th September 2015

The three phases of prototype bring up

Over the next couple of weeks I’ll blog with more details on the key capabilities of the newly available HAPS-80 with ProtoCompiler integrated solution.

  • ProtoCompiler, exclusive for HAPS systems, automates design flow and partitioning to reduce time to first prototype on average to less than two weeks and subsequent iterations to hours
  • Built-in debug capabilities are automatically inserted for greater debugging efficiency and visibility, enabling the capture of thousands of RTL signals per/FPGA
  • HAPS-80 FPGA-based prototyping system with ProtoCompiler delivers up to 100 MHz multi-FPGA performance and new automated high-speed pin-multiplexing
  • HAPS-80 enterprise configurations support up to 1.6 billion ASIC gates based on the Xilinx Virtex UltraScale VU440 FPGA and enable remote usage and multi-design mode for concurrent design execution

Today’s focus is on the design flow and time to first prototype operation being reduced to on average less than two weeks. Based on the FPGA-based Prototype Methodology Manual survey results this is still seen as the number #1 challenge to prototypers.

Challenges of FPGA-based prototyping users

Addressing time to first prototype means addressing the three phases of prototyping, making the design FPGA friendly, bring-up and debug and finally performance optimization. The first phase, make the design FPGA friendly, is all about automation. One of the three laws of prototyping is that ASIC code is FPGA hostile, there is no way around that so the more that can be done to automate the process the more seamless the flow becomes.

Phase 1, Make design FPGA ready

This is exactly what ProtoCompiler for HAPS delivers, automation throughout the flow to hardware. Automation including gated clocks conversion, clock replication, memory translation, partitioning and pin multiplexing insertion all the way through to guided place and route. The complete flow can be scripted for repeatability. This is the key capability in reducing the time to first prototype to on average less than two weeks. At this point you have FPGA bit files ready to test on the HAPS systems

The second phase if the bring-up and debug of the platform.

Phase 2, HW bring up and debug

In a perfect world the prototype would function out of the box, which is the case some of the time, but unfortunately not all of the time. In this phase the prototype engineer wants to check the system is configured correctly and rapidly debug. HAPS-80 with ProtoCompiler enables both. The HAPS built-in system check capability ensures that interconnect and daughter boards are correctly installed, match the design description and meet the required performance. Debug can be rapidly inserted not requiring a re-compile speeding up the design bring-up debug process. We highly recommend an incremental bring-up strategy of individual blocks then subsystem and finally SoC. ProtoCompiler supports an IP to SoC flow enabling this bring up strategy as lower level blocks can be integrated into the larger context of the design with reuse of the constraints developed at the block level.

At this point the HAPS-based prototype can be handed off to the target teams for continued bring up testing and early software development. The 3rd phase, performance optimization is also typically a fast iteration but the more focus this stage is given the better the results can be.

Phase 3, Performance Optimization

ProtoCompiler is designed to get to a result as fast as possible with out of the box high performance. If you have a little extra time to spare this performance can be optimized. In ProtoCompiler this is simply a change of configuration from TTFP (Time to First Prototype) mode to performance optimized mode. In the optimization and tuning mode the compilation optimization is enabled, synthesis target is highest performance, different partition goals and so on. While the turn-around time from RTL to bit file is increased the typical result is the highest performance.

So as you can see, HAPS-80 with ProtoCompiler successfully addresses the time to first prototype achieving on average less than two weeks to operation. Next week, built-in debug

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

Last week I spent the weekend in Shanghai. To pass some of the time I visited the Shanghai Science and Technology Museum I really enjoyed it.

What an amazing looking museum.

Shanghai Science and Technology Museum

While I visited all exhibit halls I enjoyed the world of robots the most

World of Robots at the Shanghai Science and Technology Museum

This hall had some great exhibits with dancing robots, archery against a robot and much more. I really liked the little robot pictured below who put on a hip hop dance show and then more classic Chinese dancing.

The little robot that could

There was even a robot who would solve a rubix cube. You mess it up, it solved it in typically less than 1 minute.

Rubix Cude Solving robot

Posted in FPGA-Based Prototyping, FPMM Methods, Getting Started, HAPS-80, Man Hours Savings, Performance Optimization, UltraScale | Comments Off

Intel’s FPGA-Based Prototyping presentations from SNUG Israel

Posted by Michael Posner on 27th June 2015

Recently at  SNUG in Israel I was lucky enough to attend two presentations created and delivered by Intel teams on their use of FPGA-based prototyping. The first: “Methodology and Best Practices deployed by Intel for FPGA-based prototyping” discussed various technics they employ to streamline the creation of an FPGA-based prototype. It’s like a mini methodology guide so I highly recommend you review the material.


Intel presentation from SNUG Israel on FPGA-based Prototyping of SoC's

The second paper titles  “Large Scale IP Prototyping” is a great example of multi-FPGA designs using Synopsys’ HAPS/ProtoCompiler solution and specifically the HAPS High Speed Time Domain Multiplexing to pass ~25K signals between FPGA’s. The material presents Intel’s usage and results and again I recommend downloading and reviewing the material.


Intel presentation on Large IP Prototyping using HAPS and ProtoCompiler

Oh, you need to have a Synopsys SolvNet ID to download….. Oh#2, I just noticed the proceedings are not posted yet. I am reliably informed that they will be posted shortly.

Many of you know that I travel internationally on business on a regular basis and have asked how I cope with the constant time changes. I employ two simply methods to manage jet lag, #1 No alcohol while traveling at all. This helps when you are only getting 3-5 hours of sleep and #2 Coffee

Best jet lag #2 Coffeeeeee

Luckily while in the UK they serve up vats/buckets of coffee that require two handles to hold the weight. This is a six shot “eye opener”

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, Debug, Early Software Development, FPGA-Based Prototyping, FPMM Methods, Getting Started, HW/SW Integration, In-System Software Validation, IP Validation, Man Hours Savings, Milestones, Performance Optimization, Project management, System Validation, Technical, Tips and Traps, Use Modes | Comments Off

Success Prototyping with UltraScale VU440 devices

Posted by Michael Posner on 3rd April 2015

UltraScale based HAPS system operation in Synopsys lab

It’s been a while since Xilinx shipped the first UltraScale VU440 engineering sample devices to Synopsys so I thought it time to deliver a short update on development progress. It might be hard to see in the above but that is a picture of one of the new development HAPS systems for the UltraScale VU440 devices. I say hard to see not only as the picture quality is low but also because we have the system completely configured with intelligent interconnect as part of our stringent characterization and functional validation process.

Each module is individually tested, see picture below as an example, this is the controller module in standalone test. The controller module hosts the HAPS supervisor which controls the system and manages advanced capabilities such as the Universal Multi-Resource Bus, UMRBus for short. Once all individual modules are signed-off they are assembled and the system is validated.

New HAPS Control module in standalone test jig

So far both the Xilinx VU440 devices and the new systems are functioning well. Xilinx has posted an errata on the engineering sample VU440 devices but these issues do not preclude the devices from being useful for system development or actual usage as part of a production prototyping project. All IO’s are operational as well as the transceiver GTH links. We have been filling the devices with high speed toggle designs as part of the performance and power characterization and smaller IP designs for other test purposes so we have not compared the utilization between V7 and UltraScale devices yet. We still predict that the UltraScale VU440 devices will deliver ~26 Million ASIC gate capacity, about 2.2X increase over the V7 2000T devices.

As a teaser for future blogs, the new integrated solution is expected to deliver

  • Highest performance w/superior partitioning & new time domain pin-multiplexing schemes
  • Always available debug with deep trace storage
  • Fastest time-to-first-prototype with HAPS aware prototyping software
  • Rapid Turn-around Time from RTL to Bit file with incremental flows
  • Native integration for regression farm & remote accessibility
  • Both HW and SW tool flow is Modular & scalable to over 24 FPGA’s (Over 600 Million ASIC Gate capacity)
  • Hybrid Prototyping ready

Preserves existing HAPS investment

  • Interoperable with HAPS-70 & HAPS-DX, (mix and match HAPS V7-based systems with UltraScale systems) same form factor, I/O voltages, HT3 connectors, daughter boards, cables

In the coming months I’ll post more information on these new and unique capabilities.

HAPS Integrated solution

Posted in Admin and General, ASIC Verification, Bug Hunting, Daughter Boards, Debug, DWC IP Prototyping Kits, Early Software Development, FPGA-Based Prototyping, HW/SW Integration, Hybrid Prototyping, In-System Software Validation, IP Validation, Man Hours Savings, Milestones, Project management, Real Time Prototyping, System Validation, UltraScale, Use Modes | Comments Off

Automated Timing Biased Partitioning

Posted by Michael Posner on 20th March 2015

I spent a lot of time this week talking about timing biased automated partitioning which is the ability of the ProtoCompiler partition engine to generate a partition and pin multiplexing implementation with the goal of maximizing performance of the final prototype implementation. As it’s getting close to Easter I thought it was fitting to discuss ProtoCompiler’s Multi-Hop optimization algorithm. (Easter, Easter bunny, hop, you see what I did there?)

Firstly what is a Hop you ask? In the image below you can see the ASIC design example with combinatorial logic between two register points

ASIC Design with logic clouds between register points

It’s possible during partitioning for FPGA-based prototyping that these two registers end up in different FPGA’s as seen in the image below.

Example of a single "Hop" between FPGAs on a physical prototype

This is what is known as a single hop. The design has been split up with the starting and ending register points in separate FPGA’s. However, without timing biased capabilities it’s possible that a partition is created that spans multiple FPGA’s. An example of this Multi-Hop is represented in the image below

Example of what a multi-hop is

In our example above FPGA B has basically become a feed through FPGA and while this helps a partition engine get to a partition solution it has a dramatic effect on the overall performance of a prototype platform. To explain the timing impact lets go back to our original ASIC design and review the timing between the register points

Timing delay of this logic in ASIC implementation

In our made up example the combinatorial logic has a timing impact of about 10ns. However in our FPGA partition where you have the critical path split up over multiple FPGA’s timing becomes much more significant. The reason for this is that you typically have to apply pin multiplexing between FPGA’s as you have more signals than you have physical pins (One of the three ASIC Prototyping three laws which are the grounding facts driving this blog) Now if you review the timing impact with a typical pin multiplexing scheme inserted you suddenly see the impact of a Multi-Hop

Tming impact of multi-hops and pin multiplexing

But not to worry if you are using ProtoCompiler as the partition engine is not only fast but it’s timing biased and includes a Multi-Hop optimization algorithm.

When Multi-Hop optimization is enabled ProtoCompiler partition engine will:

  • Focus on reducing the number of multi-hops, with a goal of zero
  • If multi-hops are needed to complete the partition the focus turns to reducing the path length of the multi-hop
  • Avoids pin-multiplexing on multi-hop path
  • If pin-multiplexing is needed the focus turns to using the lowest pin-multiplexing ratio on the multi-hop path
  • Selects pin-multiplexing ratio based on timing slack

Knowing that eliminating multi-hops would lead to higher prototype performance you might think that by default the partition engine should not allow any multi-hops. However multi-hops do play a vital role sometimes in enabling an automated partition solution to be found.

ProtoCompiler’s timing biased multi-hop optimization is making a huge impact on the resulting HAPS prototyping performance. Across a suite of over 40 ASIC designs ProtoCompilers timing biased optimizations improved the clock period by an average of 50ns. HUGE improvement in resulting performance. Across this suite of designs, ProtoCompiler reduced the number of nets that are included in multi-hop paths of length two or greater by up to 80%. For most designs in the suite, the number of paths of length three or greater was reduced to ZERO. Also, for most designs in the suite, the pin multiplexing ratio of the multi-hop path nets required to get feasible automated partition was reduced to one (i.e. no pin-multiplexing required). Fantastic. Not only is ProtoCompiler’s partition engine super-fast running in minutes for multi-million ASIC gate design but the out of the box results are phenomenal.

I’m out on vacation for a week (yes even I need time off once in a while) so no blog next week.

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

Want it all? Capacity, TTFP, Performance, Debug and More

Posted by Michael Posner on 16th March 2015

Possibly inspired my one of my blogs, Troy Scott, wrote a new whitepaper to help dispel the myths of physical FPGA-based prototyping. TTFP = Time To First Prototype

New Whitepaper, Busting the Myths Prototyping

I highly recommend this whitepaper as unlike my blogs, which I write mostly on the fly, this whitepaper obviously had a lot of thought put into it.

That’s it for the blog this week. I was traveling in the UK last week so I am a little jet lagged. While there I picked up a little UK history


It’s a ceramic poppy from the Tower of London remembers exhibit. It’s an amazing piece of history and I feel honored to be able to buy one.

I received another honor, this time from the hotel I stayed at

Mick is Mr Bacon

Yes, I am still known as Mr Bacon. This has a little to do with the fact that I love bacon and more so because I always seem to wear a T-Shirt that says BACON on the front of it.

I also had some fun with the rental car while trying to find parking one day. Below you can see my parking spot halfway up a hillside.

Mick gets crazy with parking spots

I’m not sure if you can see it or not but the back wheel is floating in the air. Fun, fun, fun.

Posted in FPGA-Based Prototyping, FPMM Methods, Humor, Milestones, Project management, Technical, Tips and Traps | Comments Off

Part Deux: How many ASIC Gates does it take to fill an FPGA?

Posted by Michael Posner on 20th February 2015

Last week’s blog How many ASIC Gates does it take to fill an FPGA? definitely stirred the pot. Part Deux (two?) goes back to basics filling in some gaps and follows up with data supplied by my good friends over at Xilinx.

So first for clarification, apparently not everyone who reads my blog understands what a Xilinx Logic Cell, LC, is or what a Look Up Table, LUT, is. I was going to create a nice set of slides explaining but thanks again to Xilinx, here is one they prepared earlier.  It should be noted that Xilinx provided me with written permission to re-use these as part of my blog. The full (PUBLIC) Xilinx presentation can be found here: http://www.xilinx.com/training/downloads/what-is-the-difference-between-an-fpga-and-an-asic.pptx

The Xilinx Logic Cell basics, a cell including combinatorial logic, arithmetic logic and a register. Your RTL source code is “mapped” into these Logic Cells.

XIlinx Logic Cell

A Logic Cell is the basic building block within the Xilinx devices and there is a *lot* of these per device, 4.4 Million in the new Xilinx Virtex UltraScale VU440. Yes that’s right, they are very, very, very small.

Part of the Logic Cell is a Look Up Table which is used to implement combinatorial logic.

Xilinx LUT

My contact over at Xilinx also provided me the Xilinx used standard calculation of equivalent ASIC gates of the Xilinx devices.

–//– From Xilinx

Here are the basic principles that we’ve tried to stick to when generating ASIC gate count numbers:

  • –       6 to 24 gates per LUT (depending on the number of inputs used)
  • –       RAM bits are equivalent
  • –       Up to 100 ASIC gates per I/O;
  • –       7 gates per register

So for the VU440 here’s how this shakes down:


LUTs :

  • Minimum    6 x 2,532,960 LUTs = 15,197,760
  • Maximum 24 x 2,532,960 LUTs =  60, 791, 040 ASIC gates

IOs :  100 x 1456 = 145600 ASIC gates

Registers : 7 x 5.065,920 = 35,461,440 ASIC gates

So by this math we could have claimed anywhere from 50,804,800 to 96,398,080 ASIC gate equivalent in the VU440.

–//– End From Xilinx

So great, this passes what I call the basic “Stupid” test, as in there is sound logic and defendable data behind the calculation. It also highlights the large variance in “gate counts” which is significantly influenced by the number of inputs used as part of the look up table calculation. It’s exactly as I stated in last week’s blog, the conversion from ASIC gates to FPGA ASIC gate equivalent is design specific. Some designs will map well, some not so much.

In the material that Xilinx supplied I also spotted this slide which reinforces this point.

ASIC to FPGA mapping considerations

Specifically for Prototypers, the conclusion is very important. The Prototypers goal is to NOT modify the golden RTL source for prototyping otherwise you will not be validating a true representation of the design. Yes, some modifications are needed such as RAM’s, gated clock conversion but these can be verified as identical and are an acceptable trade-off. Outside of this the RTL is not customized for FPGA meaning that many of the dedicated resources cannot be directly mapped to. This leads to inefficient mapping of the RTL code to FPGA and is why a “fudge” factor is required in the ASIC gate equivalent calculations. The restriction is typically the Look Up Tables for combinatorial logic mapping, you run out of those before anything else. (not all the time but most of the time). By being conservative in the ASIC gate count capacity claims the vendor can ensure that expectations are met for a majority of designs

Posted in ASIC Verification, FPGA-Based Prototyping, Man Hours Savings, Milestones, Use Modes | Comments Off

Why Do You Prototype? If You Don’t Know I Can Tell You

Posted by Michael Posner on 30th January 2015

I was forwarded this user quote and I thought I would share as it was so heartwarming for me

The design came up on HAPS in less than two weeks and we found a rather serious bug early in testing.  This is the bug that would have cost the company dearly if it wasn’t found until later in the development cycle.

It’s short and sweet and communicates the HUGE value that FPGA-Based Prototyping delivers.  This note reminded me that a while back I did an internal analysis of the value of HAPS FPGA-based prototyping in respect to the various use modes. The use modes I examined was Functional Verification, HW/SW Integration, Firmware Development, System Validation and Software Development. First I created a baseline score for HAPS in respect to various user requirements. This list stays consistent across all use modes.

  • Early Availability
  • Initial Design Setup
  • Iteration Turnaround Time
  • Execution Speed
  • Capacity
  • Deployment (Ease of/Cost of)
  • Accuracy
  • HW Debug Visibility
  • SW Debug Visibility
  • IO

How the scoring works, 1 = Sub-Optimal, 10 = Excels. To score I created a set of definitions per requirement and using real data which compared the results to other technologies thus to objectively score. The scores are mapped into a radar chart. Here is the scoring baseline for HAPS. I should point out that its subjective but I tried to be as data driven as possible. If anything I might have been a little harsh on HAPS to be fair.

HAPS Value, baseline scoring in respect to capability strengths

At the same time and using the same list of requirements I scored the NEEDS of the use mode. For example the user needs for software development are pictured here. Note the dotted line.

Baseline requirements mapped into radar chart in respect to the needs of software development

The baseline needs were mapped for each of the desired use mode. Then it’s a simple case of overlaying the results of the baseline value score of HAPS against the use mode. It’s a multiplication of the value times the need. This way it clearly shows where there is synergy of a need and as strength.

Starting with Functional Verification

HAPS Values Mapped to the Functional Verification Use mode

Remember the dotted line represents the user needs within the use mode of functional verification and the solid line represents the relative strengths of HAPS. Within a radar chart it’s easy to see the matching requirements and HAPS strengths. It’s clear to see that while HAPS does bring value to functional verification it’s definitely not the best technology for the use case. Hey, we all knew this already. A simulator such as VCS or emulator such as ZeBu is a far better choice for functional verification as they deliver on the key needs of the use case such as early availability, debug visibility, capacity etc. But I also know that HAPS is used in this use mode as the performance enables a huge amount of tests to be run in a short amount of time flushing out those hard to find RTL bugs.

Now lets review the HW/SW Integration use mode

HAPS Values mapped into the HW/SW use mode

Immediately it’s clear that the value of HAPS FPGA-based prototyping is far better matched to the requirements for HW/SW Integration. HW/SW Integration is typically the point at which FPGA-based prototyping is deployed in development. As more and more RTL blocks are coming together and the volume of software has become significant then the additional performance that HAPS FPGA-based prototyping delivers is needed to execute in a reasonable timeframe.

Now onto Firmware Development

HAPS Values mapped against the needs for firmware development

FPGA-based prototyping enables the use of real physical interfaces using the real interface blocks such as DesignWare IP. This means that the hardware aware firmware development is a key use case for HAPS FPGA-Based prototyping and this is represented in how well the values match the use case needs. The real physical IO, actual RTL blocks combined with the high performance operation make HAPS FPGA-based prototypes one of the best firmware development platforms next to the real silicon. Actually I would be bold enough to say better than the real silicon as once you have silicon its too late to fix RTL bugs!

System Validation

HAPS Values mapped against the needs of system validation use mode

For the same reasons as firmware development it’s clear to see that HAPS FPGA-Based prototyping is the best technology to address the needs of System Validation use mode. In System validation you will be running lots of software against the hardware, doing interoperability and compliance testing against real hardware. No other technology enables you to do this, PRE-SILICON

Finally the software development use mode

HAPS Values mapped against the needs of software development

This is the traditional and most well know use mode for FPGA-based prototyping. Again the HAPS values map very well against the needs and requirements of Software Development. Really the only area in question is capacity. I thought it would be interesting to add the benefits of Hybrid Prototyping into the scoring for this particular use model.

HAPS Hybrid Prototyping mapped against the needs of Software development

Hybrid Prototyping, the combination of HAPS FPGA-based and Virtualizer Virtual Prototyping makes for a powerful platform for software development. Hybrid Prototyping combines the accuracy, performance and real world IO of HAPS with the capacity and differentiated debug capabilities of Virtualizer. I can tell you that a number of customers have adopted Hybrid Prototyping to improve their early software development activities. A number of these have been able to accelerate their software development and validation to a point where the software run on the real silicon on day one! Hey bonus, the green radar chart line looks like a fish, do you see it?

Anyway, there you go, the value of HAPS across multiple use modes. Is this consistent with your scoring of FPGA-based prototyping in respect to your project usage?

Posted in ASIC Verification, FPGA-Based Prototyping, HW/SW Integration, Hybrid Prototyping, In-System Software Validation, IP Validation, Milestones, Project management, Real Time Prototyping, System Validation, Use Modes | 2 Comments »