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 'Project management' Category

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 | No Comments »

Fight Club: Automated vs. Hand Crafted Pin Multiplexing

Posted by Michael Posner on 27th February 2015

HAPS HT3 connectors and cables

This week a prototyping engineer challenged me that “his” customized and hand crafted pin multiplexing capability was “better” than the HAPS High Speed Time-Domain Multiplexing, HSTDM. My response, “Faster, maybe, better NO”. This blog explains why the HAPS HSTDM capability will beat out a custom coded multiplexing capability hands down every time.

First let’s list of the positives and negatives of a custom coded pin multiplexing capability


  • It’s tailored to the exact design requirements
  • It’s tuned for a specific set of FPGA pins and inter-FPGA connections to push performance to the limits


  • It’s hand crafted meaning effort to develop
  • It has to be manually inserted into the design
  • It breaks if the design requirements change
  • It’s tuned so will need to be customized to different FPGA pins and inter-FPGA connections
  • Might be unreliable leading to mystery ghost bugs to chase down

I am sure the list of negatives is longer but I would bet that you already get the idea. While it’s possible to craft a pin-multiplexing block that eeks out every possible drip of performance the overhead of insertion, modification to different design and hardware requirements and testing makes it inferior to the HAPS HSTDM capability.


HAPS HSTDM was designed to deliver an automated, cycle accurate, highest performance, reliable, modular and scalable pin multiplexing solution for the HAPS systems. Automated insertion through ProtoCompiler ensures that the usage is as unobtrusive as possible. HAPS HSTDM is tested to run on every qualified IO pin across the HAPS-70 system. It will reliably run on any HAPS platform, we can claim this as the HAPS hardware itself is performance tested as part of the production manufacturing tests ensuring that all systems and interconnects meet the minimum required performance for HSTDM operation. It supports multiple ratios meeting the need of many different design requirements. It is very high performance using the latest differential signaling and training techniques with built in error detection. Just looking at this list it’s clear that HAPS HSTDM has many advantages over custom.

But wait, there is more…. I would challenge that using the flexible capabilities of the HAPS hardware interconnect combined with the HAPS HSTDM capabilities that the overall HAPS prototype will run at a higher system performance. I’ve talked about this capabilities a couple of times. The HAPS systems do not have any dedicated PCB traces between FPGA’s. All interconnect is done via intelligent cabling. This method enables the HAPS hardware to be customized to better match the DUT’s interconnect needs. This means you can create more interconnect density where the DUT needs it. More dense interconnect can help reduce the overall pin multiplexing ratio required resulting in higher performance system operation. Remember your prototype is only as fast as the slowest link.

HAPS Flexible Interconnect for increased performance with HSTDM

This HAPS flexible interconnect combined with the HAPS HSTDM automated and deployed by ProtoCompiler is a very powerful solution and this is why I claim that it’s “better” than a hand crafted scheme.

More HAPS and HSTDM results

Do you agree?

Posted in ASIC Verification, Bug Hunting, Daughter Boards, Debug, Project management, Support, Use Modes | No Comments »

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

Posted by Michael Posner on 13th February 2015

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

Why did the chicken cross the road?

This question almost sounds like a joke doesn’t it. In reality this is a question I am asked to answer all the time and it’s not easy as ASIC designs don’t map the same to FPGA as they do to ASIC process technologies. In the ASIC design flow ASIC gates are represented as two input NAND gate equivalent and this is the base date point which should be used in the calculation as to how the design will map to FPGA. 

For multiple generations of HAPS systems Synopsys has used the following  tried, true and field proven calculation as to ASIC gate equivalent capacity of the Xilinx FPGA families.

The basis of the calculation is that you can map the equivalent of six two input NAND gates per Look Up Table, LUT per Logic Cell, LC.

1* LUT = 6 Two input NAND Gate equivalent (go try it!)

With this knowledge its easy to calculate the total capacity of the FPGA in ASIC NAND Gate equivalent as you then multiply the LC count per FPGA by 6.

The Xilinx Virtex-5 series biggest capacity device was listed as 330K LC’s, so 330K times 6 = 1,980,000 two input ASIC NAND gate equivalents (~2 million)

So for the other Xilinx large devices used for Prototyping you get the following.

  • Xilinx Virtex-6 = 760K LC’s = 4,560,000  two input ASIC NAND gate equivalents, (~4.5 million)
  • Xilinx Virtex-7 = 2000K LC’s = 12,000,000 two input ASIC NAND gate equivalents, (~12 million)
  • Xilinx UltraScale = 4400K LC’s = 26,400,000 two input ASIC NAND gate equivalents (~26.4 million)

Synopsys has shipped over 5000 HAPS units across 400 customers and with 1000’s of designs being validated using HAPS we are confident with this method to correctly set the expectations as to how many FPGA’s are needed to model the design under test. Of course you can only use this as a guideline as we all know ASIC RTL is typically FPGA hostile so you rarely get optimized mapping. Your ASIC RTL source code contains non-FPGA type resources, mux’s, adders, subtractors which don’t map nicely to FPGA resources and you have designs with intensive datapath and heavy interconnect stressing FPGA routing resources. The Synopsys defined estimation calculation has helped 100’s of customers quickly estimate the number of FPGA’s they need for their projects.

The only true way of more accurately estimating the number of FPGA’s your SoC prototype will need is by executing FPGA area estimation within a prototyping tool such as ProtoCompiler. Even running your design through the FPGA vendor tools will help you get an idea of the number of FPGA’s needed.

Simple right…… If only……. There is no standardization in the FPGA-based prototyping commercial market or across FPGA vendors so the poor prototyper is faced with multiple capacity claims for the same FPGA device!!!! A simple web search will quickly confirm this, other vendors ASIC gate equivalent capacity claims can be very different from the Synopsys calculation. This has led to some quite funny (now that I look back on it) conversations with customer. One such conversation is summarized by the quote

I have to buy two HAPS-70 systems to get the same capacity of the <other vendors> one board 

I did actually laugh out loud… The hardware has the same FPGA’s !!!!!! Your SoC design does not magically shrink to fit into less FPGA’s. If your tool run estimations shows that you need four FPGA’s that’s what you need, forget the vendors claimed capacity per FPGA. Don’t be fooled by wild capacity claims, do your own area estimation based on your SoC prototyping project.

It should be noted that the software tool flow used to support your prototyping effort can make a difference in the FPGA utilization. For example ProtoCompiler has a Time to First Prototype, TTFP mode which is designed to get you onto hardware fast and as part of this can be configured to use more available FPGA capacity to reduce synthesis and P&R times. ProtoCompiler also has a performance and area optimization mode where the tool will use unique techniques to pack more logic into each FPGA. This TTFP mode is typically used at the start of a project, optimized mode when you deploy HAPS in volume to software developers.

Of course, prototypers, one way for you to neutralize the vendor capacity claims is just to compare the number of FPGAs, apples to apples.

One final point, the way Xilinx “counts” gates and markets seems to be a much more sophisticated calculation which I *think* includes much more than the raw LUT NAND gate equivalent. I reached out to my Xilinx contacts and asked them to clarify, I’ll post a blog on the results if they give me permission to. (Hey maybe I can twist their arms and get them to guest blog!!!) I think their calc includes memory, hardened IP blocks and other logic but I’m just speculating.

Do you count FPGA capacity in another way? If yes drop me a note or comment and share.

Click the links to the left and below to subscribe and get blog updates as soon as I post them

Posted in Man Hours Savings, Milestones, Project management | 2 Comments »

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 »

Solving the ASIC Prototype Partition Problem

Posted by Michael Posner on 8th August 2014

A couple of weeks back I posted a humorous list of the quotes I use in my day to day life, one of which is “Hope is not a strategy”

Well as it turns out this caused quite a fluster as apparently hope is a strategy, well sort of. Here is a link to a Harvard Business Review Article – Hope as a Strategy, well sort of.


The premise is that when hope is based on real-world experience, knowledge and tangible and intangible data, it results in trust, which is necessary to implementing any strategy. What do you think about that? Is the word hope being used to explain the standard  practice of planning and factoring in the calculated risk assessment? If yes, this is going to totally revolutionize my life.

To ensure we have a little FPGA-based prototyping content this week I highly recommend the new Synopsys white paper on Solving the ASIC Prototype Partition Problem with Synopsys ProtoCompiler

ProtoCompiler whitepaper explaining how the challenge of multi-FPGA ASIC prototyping is solved automatically

The white paper describes the challenges of ASIC prototyping when the design has to be split up over multiple FPGA’s and how the new ProtoCompiler tool solves these challenges automatically. It’s a highly technical paper with in-depth data on how to rapidly partition an ASIC design ready for high performance prototyping. The ProtoCompiler tool can partition process a design in lass than 5 minutes and highlights bottlenecks which will limit the prototyping performance and pointers on how to resolve to deliver the maximum optimization.

Posted in Humor, Man Hours Savings, Project management, System Validation, Use Modes | 1 Comment »

Going vertical for all the right reasons

Posted by Michael Posner on 17th July 2014


By far my favorite aircraft growing up was the Harrier jump jet. Back in those days it was the only jet aircraft with vertical takeoff and landing (VTOL) capabilities. I dreamed of flying one and even owning my one. Actually I still dream of owning one. I like the idea of a helicopter as you can vertically takeoff and land meaning you have a wide range of landing zones. The problem with a helicopter is that it’s very slow in comparison to a plane so it would take you ages to get any real distance. Hence the Harrier was a perfect option for me, vertical takeoff and landing and jet speed in the air, it’s the best of both worlds.

In the land of FPGA-based prototyping there is a lot of horizontal and not much vertical, especially when it comes to daughter boards. Traditional daughter boards are flat or horizontally mounted to the system such as the HAPS DDR3 daughter board pictured below.  


There is nothing wrong with a daughter board like this, in fact the above daughter board has exceptional SI characteristics and operates at very high performance. However we found that some customers ran into challenges when it came to building custom daughter boards specifically tailored to their needs. Here is a summary of some of the issues they ran into.

  • Customers daughter board was quite big but it only required a couple of IO’s interfacing to the system.  Often the daughter board covered up more connectors or blocked airflow and fans just because the daughter board PCB had to be large to accommodate the custom logic
  • The daughter board required a big connector, but again only required a couple of IO’s. The size of the connector forced the size of the daughter board PCB to again cover things.
  • Once in a while the customer actually wanted to get access to both sides of the daughter board. Sometimes this was to connect to both sides, other times to probe. They would build a long daughter board expanding out of the system to do this. It was typically mechanically unsound.

Enter the Synopsys R&D Boffins! They could have ignored this little gripe with daughter boards, lets face it, the issue is annoying but not the end of the world. But that’s not good enough for the Synopsys! So drum roll please……. for the worldwide announcement of the availability of the VERTICAL HAPS daughter board. Yes, vertical….


The new vertical daughter board addresses the issues laid out above.

  • For daughter boards that use relatively few IOs, say up to 50 (HT3 connector IO count) but require more PCB real estate than a typical LAB board, building in a vertical way is excellent. Look at the picture, the board form factor is huge yet it only plugs into and utilizes one HT3 connector. It does not block any other connectors or airflow.
  • Same for the problem of the big connector, a vertical board enables a HUGE connector to be used if wanted.
  • Oh my, you can even access both sides of the daughter board, perfect for additional PCB access and probing.


The HAPS HT3 spec is being updated to define the new HT3 vertical daughter board and will be available to all existing HAPS-70 customers. Synopsys validated the form factor and usage and now shares it with any HAPS-70 customer that wants it.

So now we can all go vertical. Ease of use, functionally with performance, it’s like the Harrier jump jet of FPGA-based prototyping daughter boards. Someone once made fun of the upper frame on the HAPS-70 systems, now who’s laughing……

Posted in Daughter Boards, Project management | 1 Comment »

First Pass Silicon Success with design up and running in 24 hours!

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

The price of support

Posted by Michael Posner on 9th May 2014

One of the unquantifiable values of a company’s offering is it’s support. Support is very important all the time but more so for a hardware such as FPGA-based prototyping products. You may need support on how to use the platform, on using the software, on using the capabilities or support for debugging and resolving a hardware issue. It’s hard to put a value (price) on support as you don’t really value it until you need it.  I had a personal experience this week which in my eyes speaks to the value of support.

For my birthday last year I was purchased a very nice business style backpack from a company called Everki, it’s the VERSA model. This backpack replaced a high quality backpack that I had used for over 10 years. Based on this you can see that I expect a quality product to last a long if it’s treated well. Well within a year my new backpack had an issue

You can see that the zipped material itself seems to have failed and is coming unstitched. I contacted the company and after confirmation that the backpack was indeed a real Everki backpack they assessed the problem and are going to fix/replace the item. WOW. I like to say that you don’t judge a company by a problem, everyone has problems, you judge a company by the way it resolves them. Everki, just like Synopsys, stands behind its products. This exhibits the value of support IMO. What if I had purchased a cheaper backpack and the same issue occurred? Would the other vendor supported me in the same way, I doubt it very much. Sometimes the saying “You get what you pay for” is very true. This is a premium backpack and along with the premium price I received premium support which makes the investment a smart one. It’s great peace on mind to know that my investment is protected and backed by great service and support from the company.

It would be very hard for me to put a price value on support as I think it’s priceless.

In the market space of FPGA-based prototyping I’ve been told horror stories about support. Examples like the vendor sending the hardware schematic with a note saying “Here you go, debug it yourself”, users unable to get support as the one support engineer at the vendor was on vacation as well as cases of hardware failure and the vendor responding, “buy another one then”.

Don’t fall into the trap of discounting the value of support. IMO it could be the single most important value a vendor provides. Do you have any good or bad support horror stories? I would love to hear about them.

Off topic, did you know that the pic snippet at the top of the blog comes from a marketing campaign that I ran many, many years ago announcing the availability of the Synopsys SmartModel (verification IP’s) ported to the Windows NT platform (yes that old). Below is a picture of the complete poster promotion (yes that’s me in the reflection)

As part of the promotion we mailed (snail mail, remember that) these posters along with a T-Shirt out to over 2000 customer contacts. The Synopsys marketing director at the time thought we were crazy and that the T-Shairt was one of the ugliest he had ever seen… but he still let us do it.

Well he was right, these were the ugliest T-Shirts even our customers had ever seen and the funny thing is that rather than throwing them away or using them to clean the car the customers took the time to send them back to Synopsys. Many of them arrived back with notes stating the fact that the T-Shirts were ugly. This was a huge success, customers took notice of the promotional material sent, can’t ask for more than that in marketing.

Also, look what turned up in my office

Someone read my blog and made their own Foldify creation. This creation was to celebrate 10 years of Synopsys acquiring Accelerant Networks. Nice job!

Posted in Man Hours Savings, Milestones, Project management, Support | Comments Off

Synopsys’ New ProtoCompiler Software Speeds Time to Prototype

Posted by Michael Posner on 28th April 2014


Synopsys just announced ProtoCompiler which is automation and debug software for HAPS FPGA-Based Prototyping Systems. ProtoCompiler is the result of years of R&D effort to generate a tool that addresses prototypers challenges today and built on top of an architecture which can support the needs of prototypers long into the future. ProtoCompiler focuses on the needs of prototypers specifically addressing the need for accelerated bring up as well as providing capabilities which result in higher system performance as compared to existing solutions. In this blog I’ll discuss some of the technical details behind the main tool highlights. Below are the detailed highlihts.

  • Integrated HAPS hardware and ProtoCompiler software accelerate time to prototype bring-up and improves prototype performance
  • Automated partitioning across multiple FPGAs decreases runtime from hours to minutes for up to 250 million ASIC gate designs
  • Enables efficient implementation of proprietary pin multiplexing for 2x faster prototype performance
  • Captures seconds of trace data with gigabytes of storage capacity for superior debug visibility

(Read to the end of the blog if you also want an update on Mick’s Projects)

Highlight: Integrated HAPS hardware and ProtoCompiler software accelerate time to first prototype bring-up and improves prototype performance

As noted above the goal of ProtoCompiler is to accelerate the bring up of a prototype as well as providing a path to the fastest possible operating performance. ProtoCompiler is unique as it combines hardware/software expertise with intimate knowledge to deliver superior results. Think of it as delivering a HAPS hardware expert packaged up into a format that anyone using the tool can access. ProtoCompiler has deep technical knowledge of the HAPS hardware including configuration, clocking structures, interconnect architecture, pin multiplexing expertise and more. ProtoCompiler is not only a hardware expert, it’s also a software expert. ProtoCompiler is built on top of a state of the art Synopsys proprietary prototyping database that means RTL is effectively processed and incremental and multi-processing techniques can be deployed with ease.

All this results in blazingly fast processing speeds. As an example ProtoCompiler’s area estimation, essential for automated partitioning, can processed 36 Million ASIC gates in less than 4 hours as compared to 22 hours in existing solutions. Now that’s fast!. Thanks to the new data model and incremental modes all subsequent compiles are even quicker.

Highlight: Automated partitioning across multiple FPGAs decreases runtime from hours to minutes for up to 250 million ASIC gate designs

So there are actually two announcements packaged up in this highlight. Starting in reverse ProtoCompiler supports 250 Million ASIC gate and larger designs. Humm, this sounds a little suspect as when HAPS-70 was launched it only supported 144 Million ASIC gates, what does ProtoCompiler know that we don’t? Luckily I know, HAPS-70 can now be scaled to support 288 Million ASIC gates, 2x the capacity. HAPS-70 now supports chaining of any six systems so if you chain six HAPS-70 S48’s you get a total of 288 Million ASIC gates supported which is 24 Xilinx Virtex-7 2000T FPGA’s. All working in one synchronous system.

Any 3 HAPS systems can be chained via our standard control and data exchange cabling, when you go above 3 systems you utilize a synchronization module that manages the system synchronization. Managing clock skew, reset distribution and configuration is all handled automatically. ProtoCompiler understands the hardware capabilities thus making deployment of such a system a snap. No longer do your engineers have to worry about how to distribute clocking, we have done the hard work so you don’t have to. Other vendors “claim” scalability and modularity but if all they are delivering is boards then it’s nothing more than a wild claim. To deploy a scalable and modular system you need a complete solution of software and hardware. You can now prototype SoC designs you thought never possible

The first part of the highlight introduces the new partition technology deployed in ProtoCompiler. ASIC’s are bigger than a single FPGA so you need to quickly partition the design across multiple FPGA’s. Historically this has been a challenge but with ProtoCompiler that challenge has been overcome. The partition engine in ProtoCompiler requires minimal setup before you can apply it to your design. There are four simple steps to setup the partition engine #1 Create target system, basically which system(s) you are compiling to. #2 Establish basic constraints which are things like blocks of IO. #3 Define the design clocks. #4 Propose an interconnect structure. Actually #4 can either be defined telling the partition engine to use a set interconnect architecture or leave it open and let the tool do it. There are advantages of both. By letting the tool pick the needed architecture the resulting system should be higher performance as ProtoCompiler will maximize interconnect to reduce pin multiplexing ratio. In a previously deployed system you may have already set the interconnect and then want the tool to use the available resources so you don’t make any changes to the hardware in the field. ProtoCompiler has the flexibility to do both meeting the needs of new prototype creation and image re-spin after a new RTL code drop.

ProtoCompiler partition engine is FAST, using the same example as above, 36 Million ASIC gates, ProtoCompiler was able to come to an automated solution is 4 minutes!!! WOW. ProtoCompiler provides a huge amount of information as to what it automatically did so that the engineer can quickly review the results and maybe provide ProtoCompiler more guidance to optimize the partition. For example after the first run you might want to lock down select parts of the design and then incrementally run the engine to push it to find a better solution for the rest of the design. As it runs so fast you can do multiple of these optimization iterations in a matter of hours. I’ve played with the tool as I was interested in this particular capability and have to say it’s amazing. I’ve tried the open method and let the tool find a solution for itself, in this mode ProtoCompiler pretty much finds a solution every time. I also played with challenging the tool for example locking the tool to use only 100 IO’s (two HT3 connectors) between FPGA’s. ProtoCompiler quickly finishes and told me that I was crazy and that the design could never be partitioned with my selected interconnect architecture.

Highlight: Enables efficient implementation of proprietary pin multiplexing for 2x faster prototype performance

OK, this is simple, this basically says that ProtoCompiler can automatically deploy the HAPS High Speed Time-Domain Multiplexing (HSTDM). HSTDM is developed and optimized on HAPS and ProtoCompiler packages up this expertize and automated the deployment. The partition engine will automatically select HSTDM and instance it into the prototype design. HSTDM delivers high performance pin multiplexing between multiple FPGA’s. The signals are packaged up, sent across a high performance link and unpacked at the other side. This all happens within one system clock and is completely transparent to the user. No manual intervention, no additional latency, and it’s stable and reliable as HSTDM is tested as part f the HAPS production testing and every system has to pass the minimum HSTDM performance tests. This ensures that when you deploy am image with HSTDM that it runs on every system the image is loaded on. No need to tailor the pin multiplexing implementation for each board like you have to do with other vendors.

Highlight: Captures seconds of trace data with gigabytes of storage capacity for superior debug visibility

ProtoCompiler expands the debug capabilities and grows the HAPS Deep Trace Debug capability which utilizes off-FPGA memory to store debug data. ProtoCompiler provides seamless multi-FPGA debug capabilities on top of a set of other debug capabilities tailored to delivering visibility at the right level of the debug cycle.

In debug one size does not fit all, you need to deploy the right level of debug visibility capability dependent on what you are trying to debug and the specific point you are in the project cycle. Sometimes you want very wide debug visibility with fast incremental turn-around. Later in the design cycle you typically want very, very deep debug windows. ProtoCompiler delivers both, fully automated through the flow, seamless and transparent to the users. And when I say deep, I mean deep, the example below is very typical of the debug window where you can easily capture seconds of debug data.

As usual my blogs got really long. I wrote it in the car while driving from Portland to Eugene. Amazing that I could type all of this and drive at the same time (LOL, only joking I was in the passenger seat)

Anyway, ProtoCompiler is the bees knees and I personally think it revolutionizes FPGA-based prototyping using HAPS. What do you think of ProtoCompiler?

If you have managed to get this far into my blog then congratulations. I’ve been taking it easy this week while I recover from the pneumonia that I came down with. In the evenings I finished off the two mini RC tracked vehicles I had been working on. The basis of both are simple kits which I then modified and added RC receivers and motor controllers to. While I am a grown adult I must admit they are fun to play with. The first is a basic platform RC tracked vehicle which I attached a Lego sheet to. Little did I know that this would be so popular with my son. He has been building towers and all types of structures on top of it.

Why drive your car to a car park when the car park can come to you. No joke that’s what my son said.

Mobile tire store

Bulldozer and sweeper

At the same time I also built a kit that has a shovel that moves on the front. Again I modified it to be radio controlled, including the shovel. This vehicle is a HUGE hit with my son and he has been busy building towers, knocking them down, then tidying them up with the shovel.

There are a couple of video’s of these little things in action on my You Tube page: https://www.youtube.com/user/MrMickPosner (and a video of my chicken food winch system)

Posted in Admin and General, ASIC Verification, Bug Hunting, Debug, Early Software Development, FPGA-Based Prototyping, FPMM Methods, Getting Started, HW/SW Integration, In-System Software Validation, Man Hours Savings, Mick's Projects, Milestones, Project management, System Validation, Technical | Comments Off

Ice Cream with Raspberry Pi for Remote System Connectivity

Posted by Michael Posner on 15th February 2014

Engineering departments can no longer afford the luxury of all team members being located in the same office. The term global localization is used to describe how a team is split up over multiple geographies but must function as one unified entity. This is not only true for the personnel but also for the tools they use including FPGA-based prototyping hardware. While every software engineering in the world wishes for a high performance prototype directly on their desk typically logistically and financially this is not possible. FPGA-based prototyping systems must support this capability to ensure they can be accessed from anywhere around the world.

The HAPS series of FPGA-based prototyping systems support remote access via the HAPS Universal Multi-Resource Bus, or HAPS UMRBus for short.

The HAPS UMRBus enables the users to remotely access the HAPS system, configure it, monitor it and basically love it from a distance. The HAPS UMRBus enables much more than just remote access! The HAPS UMRBus enables data streaming to and from the system for test case stimuli or debug, advance use modes such as Hybrid Prototyping and transaction based validation and provides a generic API for user capability extensions. The HAPS UMRBus is able to deliver these additional capabilities because it’s a very high bandwidth, low latency connection from a host machine to the HAPS system.

The HAPS-70 series offers this high performance HAPS UMRBus and an integrated HAPS UMRBus over a lower performance USB 2.0 standard interface. The recommendation is that if you only needed remote connectivity for configuration and monitoring then use the HAPS UMRBus over USB 2.0 interface. If you needed high performance and low latency for Hybrid Prototyping and the other advanced capabilities then utilize the high performance HAPS UMRBus. Great right………………… Enter global localization…..

Our customers love that HAPS systems can be remotely accesses as it enables them to utilize the systems 24/7, 365 days a year (HAPS don’t even get Christmas off). However they like to lock them up along with their server hardware or in a data center. Some customers have dedicated hosts serving the HAPS which enables them to utilize the high performance, low latency HAP UMRBus and all the advanced capabilities. However, others just want to utilize the remote access via the HAPS UMRBus over USB 2.0 and while they have thousands upon thousands of Ethernet drops available they rarely have a host which they can plug the USB 2.0 cable into. So what are these users to do?

Enter the Raspberry Pi (see the blog title was not a typo but I bet the engineers already knew that)

To enable our customers to plug the HAPS system directly into an Ethernet hub one of our engineers came up with the great idea to utilize the off-the-shelf Raspberry Pi.

How it works: You buy a Raspberry Pi, USB cable, power supply and SD card, this is going to set you back around $50 (yep, not a typo, $50 and that’s usually a top of the range one). You then contact Synopsys HAPS support and we will provide you with a boot image to load on the SD card. The boot image is a standard Raspberry Pi OS with the HAPS remote access utilities, called HAPS Confpro, pre-installed. Next connect the USB cable between the Raspberry Pi and the HAPS-70 (or HAPS-DX) system. Finally connect the Raspberry Pi’s Ethernet connection into the Ethernet hub/switch and power it up. We recommend assigning a defined IP address to the Raspberry Pi so the HAPS system it’s connected to can be easily recognized. That’s it, you are ready to access the HAPS system remotely. I personally love this solution as it not only solves the problem but also lends itself for further capability expansion in the future. More on the expansion capabilities in a future blog….

What do you use the Raspberry Pi for?

Posted in Admin and General, Debug, Project management | Comments Off