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

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

Accelerating Prototyping Hardware Assembly

Posted by Michael Posner on 23rd November 2013

This week I wanted to focus on a discussion around prototyping hardware assembly.

Prototype hardware assembly is the process to tailor FPGA-prototyping hardware to meet the needs of the project. The first type of prototype assembly would be to build a custom platform directly matching the projects requirements. The building of prototyping hardware is the alternative to buying an off-the-shelf solution. The advantage of building the hardware is that you can tailor it to exactly meet the projects requirements. The disadvantage is this process is time consuming due to the long development timeline and bring-up debug process. I’ve also run into many customers who got burnt at the last minute when marketing made a last minute spec change which the custom platform does not support. Whoops, back to square one to do a frantic redesign which typically results in project delays

This is why off-the-shelf prototyping hardware is so popular. Off-the-shelf prototyping hardware, like HAPS, offers the stability of a pre-designed and validated platform but has the disadvantage of requiring the user to tailor the platform to meet the project’s needs. Some hardware vendors offers interfaces such as Ethernet directly on the prototyping board. The problem with fixed interfaces is that if the project needs them great, if the project does not then the hardware is just wasting IO resources which could be used for other purposes. HAPS is a generic reusable platform which you tailor to meet the needs of the project. There are lots of off-the-shelf daughter boards for this purpose such as DDR3, SRAM, PCIe, Ethernet, SATA, Flash, Lab. However it’s impossible for Synopsys to design and build all types of daughter boards to meet every projects need (but we try hard to). While in Japan last week I visited the Embedded Technology (ET) show in Yokahama and met with a company called Gigafirm. Gigafirm (http://www.gigafirm.com/)  has designed a set of HAPS daughter boards supporting the HAPS-70 series of products delivering daughter board support for V-by-One and embedded DisplayPort (eDP)

Above you can see Gigafirms daughter boards installed on a HAPS-70 S24 platform, the HAPS system with two Virtex-7 2000T devices. V-by-One and eDP are used for image and video designs of which there are many design starts at Japanese based customers.The V-By-One Hapstrak 3 (HT3) daughter board enables the THine (http://www3.thine.co.jp)

V-By-One evaluation boards to be connected directly the HAPS platform and supports both RX and TX capabilities.

The eDP daughter boards are designed for the HAPS Multi-Gigabit (MGB) connector interface. These high speed daughter boards enable both RX and TX eDP capabilities on the HAPS-70 systems.

I was very impressed with the quality of the Gigafirm deliverables. Gigafrm is helping customers accelerate prototype assembly by providing off-the-shelf high quality daughter boards enabling the HAPS systems to be tailored to meet the designs validation needs.

While at ET in Japan I also say the Fujitsu evaluation and development platform showcase connection to the HAPS-70

The Fujitsu development platform enables customers to evaluate the Fujitsu products and jump starts their software development tasks. The Fujitsu platform interfaces to the HAPS system via a transparent PCIe interface. The connection to HAPS enables customers to extend the platform with the capacity to model their own design blocks and validate them operating against the Fujitsu subsystem.

The Fujitsu evaluation platform is called the Phoenix. What a great name IMO.

It’s great to see the eco-system that has built up around the HAPS FPGA-based prototyping solution.

Finally, thanks to everyone who sent me a note about my allergic reaction that I suffered last week. The good news is that since that time I have only suffered a single smaller reaction which resulted in a fat lip and swollen cheek. I have not pin-pointed what is triggering the reaction but by the process of elimination I am narrowing down the suspect foods.

Posted in Debug, FPGA-Based Prototyping, In-System Software Validation, Project management | Comments Off

Do you have what it takes to be a prototyping super hero?

Posted by Michael Posner on 30th September 2013

I was recently talking to a customer who found that deploying FPGA-based prototyping was a challenge. This was a customer who had only every done simulation for verification purposes. Their last chip incorporated dual embedded processors and unfortunately they had to re-spin the silicon due to a hardware bug that they found only when running the real software. This bug was devastating, the cost was huge as it included the physical costs of the re-spin but worst was the revenue hit from being late to market. This company knew it had to adopt FPGA-Based Prototyping to enable early software development, HW/SW integration and System Validation all PRE-SILICON. The goal was to run the actual software against the hardware and identify HW/SW bugs before code freeze and tape-out.

The process to bring up a prototype was not smooth, they made a couple of key mistakes which I will share with you in an effort to help you avoid these in the future.

#1 – ASIC Code is not FPGA friendly
This is #1 rule from the FPGA-based Prototyping methodology Manual. Their code was full of ASIC specific instances that challenged the initial bring up. One of the problems was that the customer *thought* they could use the FPGA vendor tools for the synthesis. While the FPGA vendors tools seem attractive as they are close to free they do not offer any in-depth prototyping capabilities such as gated clock conversion, DesignWare support and ASIC block conversion. The customer is now looking at utilizing the Synopsys prototyping software tools that provide these capabilities in addition to offering many automated multi-FPGA prototyping capabilities.

#2 Wasted time developing in-house FPGA Boards
The customer thought that as they can design multi-million ASIC gate SoC’s of course they can design a PCB with a couple of FPGA’s on it. Sadly this choice delayed the start of the prototyping project as developing a PCB like this and managing clocking, configuration and debug is not as easy as it seems. The customer spun the PCB twice before getting a platform which provided basic function. After all this the platform stilled lacked specific debug capabilities which limited the customers productivity. The customer will not make this mistake again and is looking to deploy a commercially available FPGA-based prototyping system such as HAPS for their next project.

#3 Tried to bring up the whole SoC prototype at once
Classic mistake. The funny thing is that within simulation the customer brings up individual design blocks and only when each has past it’s hello world and basic functionality tests does it get integrated into a larger SoC verification environment. This is exactly the same as what you should be doing for FPGA-based prototyping. Bring up individual blocks and only when they are operational do you instantiate them into the SoC level. This way you are not debugging multiple issues at once that everybody knows is a very time consuming process.

The customer made other mistakes but the above ones were the worst offenders. In general the customer lacked FPGA expertise and could have really benefited from expert assistance. This is exactly where Synopsys can help, we offer expert services, expert support and expert local application experts.

The one thing that this customer stated that I 100% agree with was that it will be easier the 2nd time around. Exactly, they have built up internal expertise and plan on utilizing available products to improve the flow and the designers productivity. What the customer wishes they had done was to involve Synopsys from the start and utilized our services team to provide FPGA-based prototyping assistance at the start of the project. This would have jump started their effort. By using the Synopsys prototyping software and HAPS system the customer would not have wasted valuable time in creating a flow and designing and debugging hardware. The bonus to using the Synopsys tools and hardware is that the customer could have leveraged the extensive support infrastructure of Synopsys FPGA R&D and CAE experts as well as the globally located Application Consultant experts. Synopsys, the home of the Prototyping Super hero’s :)

Don’t make the same mistake as this customer!

Did your company have a similar experience, let me know about it.

Below is my favorite spam message of the week. Spammers, work out what the blog is talking about before bothering to spam it. Hot tubs, come on, that has nothing to do with FPGA-based prototypes. And nobody wants a “used” hot tub, that’s just gross….

Posted in ASIC Verification, Debug, FPGA-Based Prototyping, FPMM Methods, Getting Started, In-System Software Validation, Project management, Technical, Tips and Traps | Comments Off

Hitting Your Milestones

Posted by Michael Posner on 21st August 2013

This week I had to explain why FPGA-based prototyping is used. (I had to remind myself that not everyone lives and breathes FPGA-based prototyping day in day out like I do) The explanation was for an exec so I had to ensure the explanation was clean and sharp. I simply said “FPGA-based prototyping helps you meet your milestones, both for hardware development and the software development”. This caught their attention so I expanded the answer with

FPGA-based prototyping enables:-

  • Early software development. Parallel development. Don’t wait for silicon to come back, start software development against an accurate and high speed model of your SoC. (Hit your software milestones)
  • Hardware/Software integration. This is going to flush out both HW and SW bugs which could have resulted in a product limitation or worse a silicon re-spin. (Hit your integration milestones)
  • System Validation. Validate that the whole product meets the users needed. Test interfaces for compliance and interoperability with off-the-shelf hardware, demonstrate the design to your customers early. (Hit your system product milestones)

Great they said, we will take 1000…….. The value of FPGA-based prototyping is clear and it’s why over 70% of SoCs are prototyped.

Even with all this prototyping going on the #1 reason for re-spins is still hardware functional issues based on SNUG survey data. This says to me that not all of the design is being prototyped and bugs are going undetected. This has been the case as until recently FPGA capacity limited how much could be modeled. With products like the HAPS-70 supporting 144 Million ASIC gates finally you can model more of the SoC including multi-cores and big blocks such as GPUs. Model more of the SoC means you can validate more of the capabilities, more HW/SW coverage and lower risk.

To date customers have deployed over 350 HAPS-70 units, that’s many happy customers who we are helping to meet their milestones.

How has FPGA-based prototyping helped you?

Posted in FPGA-Based Prototyping, Milestones, Project management | Comments Off

The Value of Support and the Demise of USB

Posted by Michael Posner on 16th August 2013

Including USB in this week’s blog title was designed to be catchy and an effort to grab a couple of Eric Huang’s USB Blog’s bazillion readers. It’s not really the demise of USB but more of the demise of a single USB stick. I tend to destroy pens and papers by playing with them while I work, this week I found myself destroying a perfectly good USB stick.

Sorry Eric, I am sure you are crying into your soy latte after seeing what I did to this poor defenseless USB stick.

When evaluating an FPGA-based prototyping solution or even when an in house built board is being considered the one thing I see missed all the time is support! It’s hard to place a value on support as until you need it you don’t know how much it’s worth. Over the years I see “lack of support” come up as the main reason why a project slipped. When these companies go back and look at their original evaluation criteria it suddenly becomes obvious that they didn’t consider support whoops.

Support should be one of the main evaluation criteria as only a fool would think that a project will go smoothly. It’s one of the simple rules of life, like death and taxes, something at some point will go wrong. When something does go wrong you and the project is not going to be judged based on that problem (because everyone knows problems are going to come up) you are judged on how successfully you solved it. This is why support is so important as it’s the key to successful and speedy resolution to a problem regardless of its source.

If you are considering building an on house board you must consider the post build support. This includes not only the hardware side of the support but the software tool flow support which will be needed to target the board. The cost of an in house built board seems so attractive until you fail to get it to work and the whole idea of doing early software development goes out the window. Same goes for the cheap alternatives on the market today. Who do you turn to if you have a problem? These smaller providers sometimes offer support, some send you the schematic of their boards so you can fix it yourself, some have a dedicated person (1). But does a schematic really solve your problem and what if that support person is helping someone else or is on vacation and cannot support you. Fast resolution to your problem could be the difference between a project success and a project failure. Synopsys has over 250 people backing our FPGA-based prototyping products meaning not only can you rely on our technical expertise to solve your problem but also local time zone support.

What value to you put on support? Post me a comment and let me know how you rate the value of support.

Off subject my neighbor cut down a hardwood tree last week as the trunk had split and it was looking to fall over onto the house. I asked him to leave a couple of longer trunks so that I could make both of us some rustic looking benches. I must admit they turned out very well, the picture shows one finished and the other in process.

All cuts made with a 16” gas (petrol) powered chainsaw. (Chansaws make a huge mess by the way) I then planed off the tops with an electric planer. The benches weigh a lot but are amazingly comfortable.

Posted in FPGA-Based Prototyping, Getting Started, Project management, Tips and Traps | Comments Off