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 'Tips and Traps' Category

The Secret Ninja-Fu for Higher Performance Prototype Operation

Posted by Michael Posner on 5th April 2014

Not many people know this but I am a FPGA-based prototyping Ninja-Fu master. What super power do I have you ask? I have the power to enable higher performance prototype operation and in this week’s blog I am sharing this ancient secret power with you. Wow, the start of this blog sounds like the bio from a really bad “B” movie, it definitely seemed funnier in my mind, then again everything seems funnier in my mind. There is actually some seriousness to this blog as I really am going to share the not so secret method to enable higher performance in your FPGA-based prototypes.

First, let’s study a typical SoC, this case it’s ~40-50 Million ASIC gates. I chose this design as it’s easier to explain but the principle for higher performance operation is even more important for larger more complex SoC’s. Our example SoC includes a CPU with tightly coupled GPU and DDR3-based memory subsystem, PCIe high performance interface, SRAM scratch pad storage, global bus, custom logic block (your SoC’s special sauce for instance) and a number of lower performance peripherals

When you model such an SoC in an FPGA-based prototype, even with the largest FPGA’s, you need to partition the design. Partition is to split up the design across multiple FPGA’s. The challenge is that the SoC design blocks have more signals than you have FPGA pins (Hey that’s one of the three laws of the breaking the three laws blog). We all know that when you partition such a design you need to insert pin multiplexing to manage the many signals over the limited FPGA pins. As I am writing this I suddenly realized I have shared the secret of higher performance prototyping before, here, anyway, this blog is way cooler so I’ll continue writing.

The challenge of partitioning this design is that due to the tightly coupled CPU/GPU you end up with many signals spanning out from a small number of design blocks. Lets assume the CPU and GPU are partitioned across two FPGA’s. If all you are prototyping is these two blocks then with the use of pin multiplexing you can connect the two blocks together. The challenge of this prototyping project is that you are also modeling the other design blocks as you want to validate the software and use that to validate your RTL design blocks. This means you end up with the SoC partitioned across four FPGA’s which forces even more connections between FPGA’s.

The picture above is a representation of the partition, the raw IO interconnect usage and the number of external IO’s required for daughter boards. Suddenly you see not only the sheer volume of interconnect needed but also the number of individual connectors required to create such an partition. Just look at FPGA 2, it’s packed with IO and daughter boards. You could try and partition the design in a different way but it’s sure to tank the performance as the GPU needs to be tightly coupled to the DDR3 memory and the CPU requires a tight link to the PCIe interface. If you sacrifice physical IO between FPGA 1 and FPGA 2 you will end up with very high pin mux ratios resulting in very low system performance.

If you were to try and model this SoC on a board with a fixed interconnect between FPGA’s or forced to use a board with great big IO connectors you would physically not be able to support SoC designs like this. With the fixed interconnect board, even if you could work out a partition, you will have to force fit your SoC interconnect topology across a fixed number of IO’s resulting in high mux ratio’s thus low performance. In addition it’s unlikely that the board would have the number of available external connector IO to support the SoC’s external interfaces for daughter boards. It’s similarly bad on a board with high pin count connectors.  Using our typical SoC as the example, if the FPGA-based prototyping board has FMC like connectors, ~150 IO’s per connector, you would need ten connectors to support the required interconnect and daughter boards for the tightly connected CPU/GPU. Whoops, I know of no board that has this many connectors. Again you would be forced to use very high pin multiplexing tanking the performance and making the platform worthless.

Now look at the HAPS-70 S48, the Synopsys four FPGA FPGA-based prototyping system. This type of typical SoC design is the reason why the HAPS-70 systems expose all the FPGA’s pins to HapsTrak 3 (HT3) connectors. HT3 granularity is 50 FPGA IO’s per connector and are bank matched to the Xilinx Virtex-7 2000T banks and Super Logic Regions (SLR’s). This granularity is the “not so secret” enabler for SoC prototyping and the key to higher performance operation.

Now you can see that not only do you have the connector granularity to tailor the interconnect to the requirements of the SoC design but you also have ample connectors to support the external IO daughter boards. You can create a very dense interconnect between FPGA 1 and FPGA 2 supporting the tightly coupled CPU/GPU and you don’t need pin multiplexing as you have the physical number of IO’s needed. At the same time you can support all the other interconnect requirements to the other FPGA’s and the required daughter boards.

Hold on, there’s more….

You have ample connectors to setup the prototype with the needed JTAG debugger daughter board connecting your software debugger to the CPU. You have ample connectors to add real time debug to the platform. Real time debug is when you extract signals from the design and route them to a debugger daughter board which you connect a logic analyzer to. Oh and you can also add on some HAPS Deep Trace Debug memory so you can capture seconds of debug visibility. So not only is the HAPS system higher performance but the hardware architecture is the enabler for prototyping typical SoC’s. If you are smart you will also understand that as the SoC grows in size and requires more FPGA partitions that the HAPS flexible interconnect architecture becomes even more important. Below you can see a picture of the HAPS-70 S96, eight FPGA system, deployed for SoC prototyping enabling earlier software development and system validation

Now you have the secret Ninja-Fu.

I’ve pretty much finished my large tracked vehicle project which I featured last week. I plan to add a controllable shovel and other attachments to the front but I got side tracked building a new project.

This is a very small shovel dozer, you can see how small it is as it’s sitting on top of my home-built tracked vehicle. (Or maybe my tracked vehicle is just very big). You this little shovel dozer come from a kit but rather than using the supplied hard wired connection I’m going to retro fit this model with some tiny radio controlled electronics. I have not built the RC control yet and with upcoming business travel I’m not sure when I am going to get a chance to. I’ll be sure to post an update when this latest project is finished.

Posted in Debug, Early Software Development, FPGA-Based Prototyping, HW/SW Integration, Mick's Projects, System Validation, Technical, Tips and Traps | No Comments »

Prototyping wearables and the Internet of Things (IoT)

Posted by Michael Posner on 16th March 2014

Is this the future of wearable technology?

LOL, no…. well maybe…..

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

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

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

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

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

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

Reducing Risk with Pre-Silicon Demonstrations

Posted by Michael Posner on 17th January 2014

This week’s blog is going to show you how FPGA-based prototyping delivers a whole new level of WOW factor to a new product introduction. Oh, and this also sends a message of reduced risk to the prospect customer. OK, so here we go, recently Synopsys announced the industry’s first USB Superspeed 3.1 10 Gb/s platform to platform, host to device, data transfer demonstration. Here is a link to the news release.

http://news.synopsys.com/2013-12-10-Synopsys-Demonstrates-Industrys-First-SuperSpeed-USB-10-Gbps-Platform-to-Platform-Host-Device-IP-Data-Transfer

It’s one thing to make claims in paper but delivering a real demonstration of the capability adds a whole level of credibility to the data being presented. Here are the set of videos of the real demonstrations of USB 10G transfers

 The Synopsys HAPS and DesignWare IP was also used by the USB-IF to demonstrate the new USB Superspeed 3.1 10Gb/s capability:  http://www.anandtech.com/show/7652/usbif-updates-us-on-type-c-connector-demonstrates-usb-superspeed-31-transfers

 WOW……….

I’ve mentioned this in a couple of my blogs that in addition to FPGA-based prototypes being used for early software development, HW/SW integration, System validation they are the single best pre-silicon method to demonstrate new product capabilities to your prospect customers. Seeing the product in action is far more credible and valuable than simply reading a product pitch or spec sheet. A real pre-silicon demonstration leaves the prospect customer with a feeling of reduced risk with your new product as they just saw it and played with it. (it feels far more real) The same demonstration platforms can also be delivered to the prospect customer enabling a more complete evaluation or for early software development of applications that will sit on top of this new product.

Are you using FPGA-based prototypes to deliver pre-silicon demonstrations?

Also, did you like this shorter blog or my longer more in-depth blogs which I did the last couple of times?

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

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

Enjoy!

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

Command and Control

Posted by Michael Posner on 7th December 2013

It’s been a quiet week for me and prototyping but I did talk to an engineer about command and control of an FPGA-based prototype which I thought was quite interesting I will share the story.

The engineer was designing a subsystem and within the FPGA-based prototype wanted the capability to pre-load the DDR memory with contents as well as to dynamically control the register configuration. Initially the engineer was thinking about building custom hardware and software capabilities to achieve this which was a long and risky approach. I was able to make the engineer very happy by providing them an overview of the available Universal Multi-Resource Bus (UMRBus) capabilities the HAPS systems have.

To solve the pre-load problem the engineer had the UMRBus can be combined with a transactor which enables data to be easily written across from the host directly into the DDR memory. The UMRBus interfaces with a standard transactor like one for AMBA AXI. The data is written from the host and the transactor passes the data to the on chip bus interconnect which enables the data to be written to memory. The engineer can use the simple TCL based UMRBus interface from the host to facilitate this data write or could also make use of the generic C++ API and create a more comprehensive setup. It should be noted that in addition to pre-loading the memory like this the memory can also be read back for post process data analysis.

To solve the problem of dynamically controlling the DUT within the prototype the UMRBus can be deployed again. This time rather than using a full transactor the engineer would make use of the Client Application Interface Modules, CAPIM, which is a simple write/read interface which can be customized to meet the design interfaces needs. This was perfect for this use case as the DUT had a simple registered interface meaning the CAPIM could quickly be wired up to it. Again the CAPIM can be accessed via the simple TCL interface or from the C++ API.

Problem solved, happy engineer.

Talking of command and control I’m currently building a toy for Christmas which is designed to be like a command and control module.

This is just a picture of a little bit of the project. The front panel will have switches, buttons, dials and LED’s which my son will be able to play with. It doesn’t really do anything specific other than light up LED’s but when you add a child’s imagination to this it will turn into amazing things. The command module of a boat, car, space ship, submarine and everything else that they can imagine. I’ve been working on it for a couple of weeks now and I’ll post pictures of the final product closer to Christmas.

Posted in FPGA-Based Prototyping, Mick's Projects, Tips and Traps | Comments Off

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

Posted by Michael Posner on 8th November 2013

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

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

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

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

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

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

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

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

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

Superior debug visualization and efficiency

Posted by Michael Posner on 26th October 2013

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

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

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

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

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

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

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

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

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

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

Do you use a hammer to put in a screw?

Posted by Michael Posner on 11th October 2013

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 hammer is a great tool but it’s not the right tool for the job. Evaluation boards are not designed with FPGA-Based prototyping in mind, they are designed to enable evaluation of the individual FPGA devices capabilities. “Evaluation” board, not FPGA-based prototyping system. HAPS is architected with the FPGA-based prototyping in mind and provides the capabilities to increase the customer’s productivity. Our goal is to improve the customer’s efficiency by providing out-of-the-box capabilities which the customers can deploy immediately. To meet the demands of FPGA-based prototyping the customer would need to hand craft such capabilities for an evaluation board and then internally support it’s usage which detracts the customer from the important tasks such as early software development, hw/sw integration and creating product differentiation.

  <- DON’T USE THIS WITH THESE ->

Then of course I was asked to explain and provide a couple of examples of what FPGA-Based Prototyping capabilities are. Below are just a couple of the examples:

The evaluation board has no reuse when going from standalone IP to SoC level prototype. Pin-outs change, constraints change resulting in duplicated effort between IP and SoC teams. With HAPS this flow is streamlined as each system is designed with expansion in mind.

The evaluation board has no built in debug capabilities, HAPS offers deep trace debug with support for Synopsys’ Verdi/Siloti for deep and wide visibility. Speeding up the debug process will make the teams more productive. HAPS also includes support for Real Time Debug providing automated setup of a logic analyzer which is used to capture almost infinite debug data. Improved debug efficiency for the customer’s teams increasing productivity.

The evaluation board is typically delivered with a version of the vendors synthesis tool which has no dedicated prototyping capabilities. The HAPS prototyping software tools deliver prototyping capabilities such as gated clock conversion, clock optimization, fast synthesis and prototyping diagnostic compiler. These capabilities will ease the flow from RTL to operational prototype making the customers more productive.

The evaluation board offers no hardware flexibility (similar point to the one above for IP to SoC). The evaluation boards only offers a rigid hardware architecture forcing the DUT to have to be force fit to it. HAPS provides a flexible hardware architecture with FPGA-based prototyping capabilities and reuse across multiple projects. As an example, if an interface is used on the evaluation board that’s great but if it’s not used then it’s a wasted resource tying up IO’s. HAPS enables higher return on investment for the customers ensuring the hardware can be utilized across multiple groups and projects.

The evaluation board has no built in Hybrid prototyping support. HAPS offers a complete solution for Hybrid connectivity including native Universal Multi-Resource Bus, UMRBus connectivity and supporting API. The UMRBus also streamlines the creation of custom application widgets for tasks such as pre-loading memories, initializing registers and debug and protocol monitors. The UMRBus includes complete host software application programming interface and hardware interface modules for rapid deployment of the UMRBus capabilities.

HAPS delivers an on-board supervisor enabling remote access and HAPS-Aware query and system check capabilities. These capabilities ease the use of HAPS and provide a mechanism to check the system setup before deployment ensuring immediate productivity.

Like I said, evaluation boards play an important role enabling you to evaluate an FPGA devices functionality. However an FPGA-based prototyping system such as HAPS offers tailored capabilities which are required to successfully prototype an SoC.

No fun spam this week :(

Posted in FPGA-Based Prototyping, Tips and Traps | 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!”.

http://www.synopsys.com/cgi-bin/sld/pdfdla/pdfr1.cgi?file=my-rtl-is-an-alien-wp.pdf

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