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 'Getting Started' Category

Prototyping wearables and the Internet of Things (IoT)

Posted by Michael Posner on 16th March 2014

Is this the future of wearable technology?

LOL, no…. well maybe…..

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

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

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

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

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

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

FPGA-Based Prototyping Best of the Best

Posted by Michael Posner on 10th January 2014

As it’s my first blog of 2014 (Happy New year and all that) I wanted to reflect back on 2013 and what better way to do that than review the best of the best of my blog postings from 2013. So drum roll please… here is my short list of cracking blog posts from 2013 in chronological order. This is not a list of all the blogs (but it did turn out to be a big list) just the ones that I personally think have the most valuable FPGA-based prototyping information.

Also, check out my new Blog Bio Photo –> 007 Style !!

How IO Interconnect Flexibility and Signal Mux Ratios Affect System Performance

One of the “Breaking The Three Laws” is that your SoC partitioned blocks typically have more signals than physical IO’s on the FPGA. Technically this is not one of the three laws but it should have been and as I own this blog I can make one more up. Welcome to the Breaking The Four [...]

Direct Route or Take the Bus?

Last week’s blog was on direct interconnect density and the effect it has on pin mux ratios. The example focused on using HSTDM but one of the readers correctly pointed out that interconnect density effects any pin muxing scheme, not only HSTDM. The rule of thumb is the greater the density of interconnect routes the [...]

UFC: Cables Vs. PCB Traces

UFC: Cables Vs. PCB Traces With the new HAPS-70 all cable based interconnect architecture we often get asked about overall raw performance of the cables vs. PCB traces. Below is the data on the raw cable and new HapsTrak 3 connector performance. This in itself shows that the cable and connector architecture are cable of running [...]

Jim Hogan falls prey to HAPS cloak of invisibility

I used to own a Ford F350 truck and it was huge with the long wheel base, full bed, extended crew cab measuring a length of about 25 feet (8 meters). The problem was that it came installed with a cloak of invisibility. I didn’t know it had a cloak of invisibility when I purchased [...]

EDACafe Video’s and the best dressed presenter

While at DAC, EDACafe video interviewed me discussing the HAPS-70 FPGA-based prototyping solutions. You can find the video here: http://www10.edacafe.com/video/Synopsys-Mick-Posner-Director-Product-Marketing/40055/media.html I liked the interview style and the whole interview was shot in one take, no breaks and was completed in less than 5 minutes. I think you will find the video informative so please watch [...]

Complex SoC Prototyping using Xilinx Virtex-7 based HAPS-70 Systems

At the recent SNUG UK Paul Robertson from Broadcom presented a paper on their use of FPGA-Based Prototyping for their current generation of SoC’s. For those with Synopsys SolvNet access the paper can be found by following this link: http://www.synopsys.com/Community/SNUG/UK/Pages/Abstracts.aspx?loc=UK&locy=2013#C1 Based on participant votes Paul was awarded with the prestigious “Best of SNUG” award. Congratulations [...]

Understanding IP and IP to SoC Prototyping

I’m presenting at the quarterly GSA Intellectual Property (IP) Working Group Meeting this morning and while reviewing my slides I thought I would blog on a couple of aspects of IP (RTL blocks) and IP to SoC Prototyping. I’ve blogged on this topic before but it was ages ago and even I’ve forgotten what I spoke [...]

Do you use a hammer to put in a screw?

This week I was asked to compare the Synopsys HAPS systems to FPGA vendor evaluation boards. I only have good things to say about the FPGA vendor evaluation boards but when comparing these evaluation boards to HAPS for serious FPGA-Based Prototyping I just said, “That’s like using a hammer to put in a screw”. A [...]

Designing an Electrochemical Cell

A couple of folks complained that my last blogs have been a bit long and boring. (Boring! Me?) So I would like to start this week and apologize to all my 5th Grade readers, I’ll try harder in the future to use smaller words and more pictures. The good news is that this week is [...]

Accelerating Prototyping Hardware Assembly

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 [...]

Xilinx FPGA’s for FPGA-Based Prototyping

If we look at the FPMM survey respondent data it’s clear to see that the favored FPGA device for FPGA-based prototyping is Xilinx devices This week Xilinx announced the Virtex® UltraScale™ VU440 3D IC. http://press.xilinx.com/2013-12-10-Xilinx-Doubles-Industrys-Highest-Capacity-Device-to-4-4M-Logic-Cells-Delivering-Density-Advantage-that-is-a-Full-Generation-Ahead This is the device that Xilinx wants the future generation of FPGA-based prototyping hardware to make use of. Rather than [...]

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

I’ve talked about streamlining IP to SoC prototyping and the use modes that prototypers use for IP validation. This week Synopsys announced the new HAPS Developer eXpress (HAPS-DX) prototyping system. This new HAPS-DX system is perfect for complex IP and subsystem prototyping and ties in nicely with the flow that I have been blogging about [...]


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

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

Posted by Michael Posner on 20th December 2013

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Happy Holidays

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

Invaders from Space: My RTL is an Alien!

Posted by Michael Posner on 4th October 2013

Hot on the heels of last week’s blog on the common mistakes first time prototypers make, Synopsys published a white paper titled “My RTL is an Alien!”.


You might mistakenly think that I *plan* my blog posts as this white paper goes into detail on ways to accelerate the bring up of FPGA-based prototypes. This is a perfect continuation of the topic of ease of use. Of course for those of you that know me I didn’t plan and it was a nice surprise.

Anyone who reads this blog (and those that don’t, don’t know what they are missing) know that FPGA-based prototyping is gaining popularity because it provides an economical way to functionally validate an ASIC design by creating a prototype that runs close to “at speed.” FPGA-based prototypes deliver the best platform for pre-silicon early system software development because of this high execution performance. However we also all know that FPGA architectures include resources, building blocks, power circuitry, and clocks that are fundamentally different from those of an ASIC. With over 70% of today’s ASICs and systems-on-chips (SoCs) being prototyped in an FPGA, designers are looking for ways to ease the creation of FPGA-based prototypes directly from the ASIC design source files.

This new paper focuses on how to create an automated process that converts ASIC design source files into a working FPGA-based prototypes. The techniques described will allow you to maintain one “golden” set of files that will work in both your ASIC and FPGA-based design environment so that, with each new revision of your ASIC RTL, you will be able to quickly create a revised FPGA-based prototype.

As I posted a couple of weeks back I’ve been traveling around on business but between that I have managed to get to the race track: http://www.youtube.com/watch?v=Ple1KCmxYs8. This video shows me against a dedicated track car called the Radical. This car and driver was the only person faster than me and I don’t mind getting whipped by superior technology and skills.

This week’s prize spam

I looked up the word entropy and the following are the definitions

Definition of entropy (n)

en·tro·py [ éntrəpee ]   

  1. measure of disorder: a measure of the disorder that exists in a system
  2. measure of unavailable energy: a measure of the energy in a system or process that is unavailable to do work.
  3. measure of efficiency: a measure of the random errors noise occurring in the transmission of signals, and from this a measure of the efficiency of transmission systems

Which definition do you think applies to my blog?

Posted in ASIC Verification, FPGA-Based Prototyping, Getting Started, Humor, Technical, Tips and Traps | 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

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

Hybrid for RTL Block Validation and Infomercials

Posted by Michael Posner on 9th August 2013

In my final installment on RTL Block Validation we are going to talk about the Hybrid Prototyping usage case.

The Hybrid use case is rapidly emerging as the differentiated way to validate RTL as it enables the block to be validated in the context of a lager system without the need for RTL of the system.

This usage case is the evolution of the PCIe connected use mode. The PCIe connected use mode forces the software developer to create software that is specific to the host machines OS, Windows OS for example which is common when the PCIe is plugged into a Windows based PC. The problem is that the final RTL block is usually integrated into an embedded CPU based system which utilizes one of the embedded cores such as ARM, ARC, MIPS and so on. The software created using the Hybrid prototyping use mode can be made to match the expected final target processor and OS.

The value of the Hybrid use mode is that the RTL block can be validated and stressed in the context of a realistic representation of the final system it’s going to be deployed in. You can do this without the need to have RTL for a real system, cool huh.

Synopsys’ Virtualizer (http://www.synopsys.com/Systems/VirtualPrototyping/Pages/Virtualizer.aspx) has a large library of processor models and even a set of pre-made, ready to go reference systems called Virtual Design Kits, VDK’s(http://www.synopsys.com/Systems/VirtualPrototyping/Virtualizer-Development/Pages/default.aspx). You can use these directly or to jump start your own VDK development which is great so you don’t have to be a SystemC expert. The link between the Virtual and FPGA is made via a physical connection and transactors which convert the high level SystemC Transaction Level Modeling (TLM) commands to physical pin toggling over in the FPGA.

The transactors are really the smarts behind Hybrid Prototyping. Both Virtual and FPGA-based prototyping technologies are established and accepted prototyping technologies. Bringing these two technologies together enables the pre-RTL value of the virtual prototype to be linked to the real-RTL values of FPGA-based prototyping.

Synopsys provides a solution for Hybrid prototyping providing a seamless solution from one provider making it easy to adopt the Hybrid prototyping use case. Here is a nice video introducing Hybrid: http://www.synopsys.com/Systems/FPGABasedPrototyping/Pages/hybrid-prototyping.aspx

 Wow, I’m starting to sound like an Infomercial. I’m pretty sure that if I hadn’t joined Synopsys that I would have ended up doing late night TV commercials. I love how “if you call within the next 10 minutes” that you always seem to get double the order for the exact same price (+S&H). Is that really a deal or are you just paying too much in the first place. I met Billy Mays (RIP), a popular star of the American infomercials, once and questioned him on if anyone buys the trash that is featured in these commercials. He said that the items they chose to develop and promote have worldwide appeal making the TAM every household in the world. That’s a huge TAM. While “YOU” might not need an item, someone, somewhere does and when your TAM is every household in the world you end up selling this “trash” in large volumes. Here is a tribute to Billy Mays: http://www.youtube.com/watch?v=Gb9vOp7wCqQ

Let me know if you have ever purchased anything based on an infomercial, especially if you bought two for the price of one because you called within the 10 minutes.

Posted in ASIC Verification, FPGA-Based Prototyping, Getting Started, Humor, Technical, Tips and Traps | Comments Off

PCIe Connected Prototyping & The Loop Concept

Posted by Michael Posner on 2nd August 2013

This week we are going to talk about the PCIe connected prototype for RTL block and IP validation and again discuss the benefits of using the loop concept.

The PCIe connected prototyping use case is used to meet the need for an effective and high performance method to validate the RTL design under test against software without the need to model a whole SoC. The design under test is connected to a PCIe core, such as the DesignWare PCIe End Point to create a physical link from the FPGA-based prototype to a host machine. Typically a thin glue logic layer is used to bridge from the PCIe core bus to the DUT bus. The physical link is in the form of a connection from the FPGA-based prototype such as the PCIe MGB kit for HAPS that includes a host plug in card. The PCIe core is visible on the hosts PCIe bus and acts as a transparent interface with mapping to the DUT’s registers and data bus.

With a PCIe connected prototype up and running you can write custom software to exercise the DUT and even run standard software drivers such as you have for USB and SATA which are native to the hosts OS. The huge advantage of the PCIe connected prototype is the PCIe link also has high bandwidth so the DUT can be performance stress tested. Here is an example of the PCIe connected prototype in action utilized in the DesignWare USB 3.0 video: http://www.youtube.com/watch?v=MTGBz–4tVY I like this example as not only does it show software running on the host controlling the DUT and high performance data streaming but it features my friend Eric J

So great you have a standalone validation platform but what about integration into the SoC level prototype????? That’s where the Loop Concept comes in.

The Loop Concept is an elegant and very simple idea that breaks out the DUT from the logic supporting the DUT validation. In our case above we have applied the loop concept to the PCIe connected prototype but it could be just as easily applied to the standalone or in fact any type of RTL block and IP validation prototype. The loop is a set of cables bringing the connection between the DUT and the support logic to the connectors of the prototype and “looping” them back in again. An example could be that you are exposing the DUT’s bus interface to the outside world. Of course to create the loop you may need many IO’s so careful choice of a hardware platform that exposes as many IO’s as possible, such as the HAPS-70 systems, is needed.

When it comes to integrating the DUT into the SoC prototype the loop concept provides two benefits. The loop forces a clean break between the DUT and the support logic infrastructure so it’s easy to identify the RTL needed for the SoC integration. The other use case is that the loop of cables can be unhooked from the support logic and connected directly into the SoC prototyping platform. To be successful with this type of hardware to hardware reuse you need to be using the same hardware series for both the RTL block and SoC level prototypes. Our example illustrates the small HAPS-70 S12 for the RTL block level prototype and the larger HAPS-70 S48 for the SoC level prototype. All HAPS systems support chaining for clock synchronization and configuration. Planning is needed upfront to ensure that the clock and reset schemes are compatible between the DUT and the SoC. The value is in a high level of reuse, accelerated integration of the DUT into the SoC meaning you can become more productive earlier in the design cycle. I love the loop concept, so simple but so powerful.

If you are using the loop concept post me a comment and let me know. If you want more information on how to implement the loop concept post me a comment and I’ll help you setup a reference model.

As you might remember I was at the track a couple of weeks back and for the very first time I actually purchased some pictures from the photographer which attended.

If you look closely in this picture you can see the rear wheel of my car lifted of the ground. I’m not going slow by the way… I’ll be adjusting the rebound setting of my rear suspension so that it can react faster.

I just love this pic, makes my little yellow school bus grocery getter look pretty mean :)

Next week I’ll discuss the Hybrid Prototyping use mode.

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

Standalone Validation & the Wow Factor of Turbo Antilag

Posted by Michael Posner on 24th July 2013

Continuing on my theme of RTL Block/IP validation I wanted to discuss the most popular and typically the most well understood usage mode, Standalone.

The characteristics of a setup with define usage as standalone is well….. it’s standalone…… In a typical standalone setup the DUT is being stimulated by real world input and it’s generating some type of real world output. A good example of a standalone prototyping setup is the DesignWare MIPI demo of CSI/DSI. (Video: http://www.synopsys.com/dw/ipdir.php?ds=mipi_csi2 ) The real world input is a MIP camera and the real world output is a MIPI compliant display. The design under test in this case is both the DesignWare CSI and DSI digital controllers implemented on the HAPS FPGA. The DesignWare DPHY is being validated as part of this setup as well as they are utilized to facilitate the physical electrical interface with the test chips mounted on HAPS daughter boards.

Within the standalone setup a processor may or may not be used depending on the DUT. In many cases a processor is implemented as part of the prototype that controls the configuration of the DUT. In the case of the above example I remember that a processor is used which executes a light software layer enabling software control of the IP’s dynamic configurations. The code is controlled and debugged via a simple JTAG connection.

The DUT is being immersed in real world stimuli identical to how it would be when utilized in a full SoC design. This is why it’s validation! you confirm that the DUT does what it’s supposed to do and that it meets user requirements. In the case of our example video in and video out, you see the results.

A requirement of a standalone prototype platform like this is that it has to be high performance to support the real world interfaces which typically have minimum clock frequencies.

The standalone setup can be used for HW validation in addition to HW/SW integration and or course as a platform for continued SW development. These usage modes make the standalone prototype highly useful across hardware, software and system design teams. This is why the standalone use mode is by far the most popular and well understood usage mode.

Next week I’ll discuss the PCIe connected modes and introduce the “Loop Concept” exciting right!

And for those of you who only read my blog for the “non” FPGA stuff here is a link to a video of me having a little fun at The Ridge Motorsports Park in my 450 WHP Subaru: http://www.youtube.com/watch?v=1Cn79GSTfXc (This was why last weeks blog update was on Thursday, I was doing this on the Friday) You will have to take my word on it that in fact it’s more fun to do than watch on video. Here is another video from a while back of me tuning what is known as the “Turbo Anti-lag” system on my Subaru: http://www.youtube.com/watch?v=Ppv3EMGlITY  

I don’t use the antilag system very much as it’s pretty hard on the engine components but when I do it certainly brings a smile to my face and shock and awe to onlookers. Fast n Furious yo….

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

Understanding IP and IP to SoC Prototyping

Posted by Michael Posner on 18th July 2013

I’m presenting at the quarterly GSA Intellectual Property (IP) Working Group Meeting this morning and while reviewing my slides I thought I would blog on a couple of aspects of IP (RTL blocks) and IP to SoC Prototyping. I’ve blogged on this topic before but it was ages ago and even I’ve forgotten what I spoke about.

The first is what I like to call the other three laws (not to be confused with the FPMM three laws, who can remember what they are?)

  • IP and SoC level prototypes require different capacity solutions
  • IP and SoC level prototypes require similar capabilities
  • IP prototypes need to be rapidly integrated into SoC level prototypes

 Simply put, RTL IP blocks maybe a small fraction of the whole SoC but when you FPGA-based prototype them the only requirement that changes is the capacity (ASIC Gates) of the solution you use.

Thinking about everything I want to write about I think this is going to turn into a blog series as it’s too much for one blog. Yay, that makes the next couple of weeks easy for me.

As mentioned, regardless of the size of the block being prototyped you still need high performance operation, you still need a flexible solution which can be tailored to your designs needs, you still need debug capabilities and an easy to use implemtation tool flow. You can of course get away with less but that just makes your validation and software development task harder and we all have it tough enough already so we strive for an easy life.

Lets start off with looking at the RTL Block/IP prototyping use modes. As usual FPGA-based prototyping of RTL blocks is not done the same way every time but I have been able to create three groupings to help explain how these blocks are typically handled. The three buckets are:- Standalone, PCIe connected and Hybrid.

What I am calling standalone is by far the most popular and easiest use mode to understand. The PCIe connected prototype is the second most popular use mode with the Hybrid prototype being the newest and emerging use mode.

Based on these buckets which use mode do you use for your RTL block/IP prototyping?

In the coming weeks I will explain each use mode in detail and provide tips on structuring the smaller prototyping design so that it can be easily integrated into the larger SoC level prototype.

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