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 'FPMM Methods' Category

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

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 | 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

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

1000 Days of the FPMM: A penny for your thoughts?

Posted by Michael Posner on 7th September 2013

Guest Blog Alert – Doug Amos, author of the FPGA-based Prototyping Methodology.

Thanks, Mick, for allowing me to guest blog on “Breaking the Three Laws”. I’ve really enjoyed reading blog and hearing where FPGA-based Prototyping has been going recently. Apparently, sometimes at a scary speed around a racing track (I’d love to have a ride in that Subaru, but I don’t think it has a passenger seat).

The reason for this guest slot is to reflect on a milestone, and look back on how far we’ve come. What’s the milestone? Well, it’s around a 1000 days since I froze the content of the FPMM (if you are a purist engineer then you can wait until 1024 days to read this, if you prefer). 1000 days sounds like a lot of time, but really is it a lot of progress? How has it worked out for you?

Let’s see how far we’ve come . . .

In November 2011 (for ‘twas then), Xilinx and Synopsys and our more advanced users, were pioneering the use of Virtex 6 FPGAs, prototyping designs of pretty decent speed (21% of prototypes running between 100 and 200 MHz) and targeting in-house developed boards (by a small but significant majority). I know this from talking with users at the time, but also because I can look back at the earliest survey data from those of you who kindly downloaded the FPMM.

The most recent survey data, however, shows some differences . . .

  • Prototypes are getting faster (over 33% of designs are now running between 100 and 200MHz).
  • More prototypes are being used for System Integration.
  • More people now use commercial FPGA Prototype solutions, rather than make their own boards.

Hopefully, dear reader, it is obvious that these three observations are inter-related. There are probably other reasons which will vary from project to project, but the trend away from starting your FPGA-based Prototype by first making a board is pronounced. So post a comment and let Mick and I know about your successes with FPGA-based prototyping

Posted in FPGA-Based Prototyping, FPMM Methods | 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

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

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

Posted by Michael Posner on 3rd July 2013

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 Paul !!!

Paul presented a paper on their use of the UMRBus at SNUG UK 2012 and came in third place. That paper can be found in the SNUG UK 2012 proceedings archive here: http://www.synopsys.com/community/snug/pages/proceedingLp.aspx?loc=UK&locy=2012 (again SolvNet access required). These are both great papers and highlight the technical advantages of using the Synopsys FPGA-based prototyping systems.

The paper on complex SoC Prototyping is going to be presented again at the upcoming SNUG in Japan on July 12th. For my Japanese readers here is a link to the JSNUG events page: http://www.event-info.com/jsnug2013/

Paul himself could not make it out to Japan so Andy Jolley, the local UK Synopsys Application Consultant and FPGA-Based Prototyping expert will be presenting it for him. It’s Andy’s first time in Japan and I’m interested to find out how he likes it. Andy is a couple of years older than me and grew up just a couple of streets from me, went to the same school and University. It’s amazing that we both ended up at Synopsys and for the same products. Best of luck Andy!

In celebration of SNUG Japan 2013 we have also launched the Japanese version of the FPGA-based Prototyping Methodology Manual, FPMM.

The English and Japanese versions can be download for FREE here: http://www.synopsys.com/Systems/FPGABasedPrototyping/FPMM/Pages/default.aspx This is the must have book for all engineers embarking on FPGA-based prototyping projects. Even if you are a seasoned prototyper the FPMM is still sure to provide guidance on techniques to improve your prototyping efficiency.

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

UPF & FPGA-Based Prototyping – More Power Mick

Posted by Michael Posner on 21st June 2013

My wife’s nickname for me is “More Power Mick” and as I am doing a blog on UPF and validating it as part of an FPGA-based prototyping flow I thought sharing this nickname was relevant.

For those of you that don’t know what UPF stands for its Unified Power Format and below is an overview of it’s relevance. Click the pic to see the full description.

There are many techniques employed to enable low power consumption but not all of them need to be modeled as part of your FPGA-based prototyping flow. Techniques that impact functional behavior such as power up/down, state retention/restore and block isolation need to be modeled. These capabilities need to be exercised in the prototype to ensure correct hardware operation and validate the software that usually manages the transition into and out of these modes.

Low power techniques that only affect the ASIC implementation do not need to be modeled in the FPGA-based prototype. These are things like voltage domains and the use of multi-vt ASIC libraries. Just like ASIC library components and memory macros these really can’t be modeled in FPGA technology anyway.

UPF is used to describe low power intent and it’s important to include the UPF scripts in the FPGA-based prototyping flow

What’s the value of modeling UPF in the FPGA-based prototyping flow I hear you ask? (and I have very good hearing)

Feedback from key SoC design teams report that many power management bugs and errors have been found with the help of FPGA-based methods. A key point is if low power design intent is ignored during prototyping, then the prototype does not match the ASIC. Ensuring that the FPGA-based prototype is as close a representation of the actual ASIC means higher confidence in the validation task that it’s being used for. This means that inclusion of the UPF scripts is important within the FPGA-based prototyping flow so the tools can incorporate and generate a model implementing what the UPF describes. The value of incorporating UPF is that you can now validate more of the designs capabilities.

It’s not only the hardware engineers that benefit from incorporating UPF the software engineers see huge value as well. A big portion of the software developer’s job is to exercise power control logic. For example turn audio processor on if someone plays a song, turn it off when paused, restore when un-paused (retention/restore). This must be done without corrupting other subsystems which are still running (isolation). Modeling the effects of power control logic in the FPGA-based prototype enables software developers to exercise their algorithms at the high performance levels available only via FPGA-based prototypes.

So I recommend that if you have adopted UPF to describe your designs low power intent that you also utilize an FPGA-based prototyping tool flow that enables you to incorporate it into the resulting FPGA model.

Off topic (as usual) my wife started calling me “More Power Mick” after I modified the 12v battery system on our small Teardrop trailer. If you don’t know what a teardrop trailer is then here is a picture of ours, she is called “Dottie”

The 12v system is used to power the heater, fans, fridge and odd other electrical things. Stock the trailer comes with one small 36 AH battery. Out off-grid you get about 1 ½ days on that battery if the fridge is running. That was not long enough IMO so I modified the setup and added two more batteries in parallel, hence the nickname “More Power Mick” or MPM for short.

But what happens if those run out? I solved that problem by making a backup battery setup.

It’s a modified trolling motor battery box. It already has a power meter, two 12v sockets and battery connection posts I just added a set of USB sockets so you can charge you phone and other stuff from it.

Inside you have the charger for it, you have the cables used to connect it to Dottie using the backup battery to power Dottie’s 12v system and you also have a small 150W pure sine wave inverter. The inverter enables 110v AC from the 12V DC. (Side/Side note, at the top right of this picture you can see one of the pistons from my Subaru which makes a great paper weight. This one has a hole in the top after a dramatic failure. I have three others just like it. Post a comment, include the key phrase “MBT” and I’ll send you one, first come first served)

The battery backup itself is powered by two small 22 AH batteries which sit at the bottom of the box. Pretty neat right! This is actually the 4th one I have built, each version was an improvement over the previous. I’ve waffled on for long enough……

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

DDR3 memory and how useful a brick can be

Posted by Michael Posner on 19th April 2013

Last week I wrote almost nothing about FPGA-Based Prototyping because I was off in the weeds talking about painting fish and my Subaru building and racing hobby (Some says it’s an obsession, not a hobby). I got so many complements on my blog, thanks! This week it’s back to your normally scheduled programming. I was planning a short blog posting this week but then I got carried away and now I find this post really long. Stick it out and read the whole thing it’s full of useful tips.

I was challenged this week to explain why HAPS systems don’t have DDR memory hard wired directly on the FPGA but rather support them via a daughter board. The assertion from the person (they work at Synopsys) was that you couldn’t support the DDR3 speeds via a connector and DDR3 had to be hard wired.

First of all, this person obviously does not read my blog otherwise they would have read me UFC Cables vs. PCB Traces blog a while back: http://blogs.synopsys.com/breakingthethreelaws/2013/03/ufc-cables-vs-pcb-traces/ It includes information on the high speed HapsTrak 3 connectors. Just from this post they should have worked out that the Hapstrak connectors has the performance capable of supporting DDR3 interface speed. Another give away that DDR across a connector on a daughter board is not a problem is that we supported DDR2 on the classic HAPS-50 systems and support DDR3-800 (400MHz interface) on the HAPS-60 system.

With the HAPS-70 systems and the move to the new Hapstrak 3 connector we raised the bar again and support DDR3-1066 (533Mhz interface) and have even been testing at DDR3-1333 (666 MHz interface).

So you say argument done, Mick wins, case closed…….. NO. Challenge me and prepare to go down. Now it’s my turn, I’m on a mission to show that not only does HAPS support DDR3 but because of the flexible daughter board implementation that the prototypers get additional value. Some people would call this the double punch, I like to call it the punch while holding a brick (yay, finally I tie the title of this blog into the post).

The brick held punch; Simply put, if you hard wire DDR3 or any interface to the FPGA of a prototype you are reducing your IO count available for interconnect or other daughter boards. If you read my post on interconnect flexibility and signal mux ratio: http://blogs.synopsys.com/breakingthethreelaws/2013/02/how-io-interconnect-flexibility-and-signal-mux-ratios-affect-system-performance/ you understand the importance of available IO. Lets say your design does not use DDR3 memory, with a board that has DDR hard wired those IO’s are wasted, you are not using the DDR but you can’t use the IOs because they are hard wired. On the HAPS system if you are not using the DDR you have no wasted IO.

If you are using DDR memory you might think that at that point a solution with hard wired DDR and the HAPS flexible solution are the same. If you thought this you would be mistaken. With a hard wired solution you are forced to place your memory controller in the SLR where the DDR3 is hard wire connected. This pretty much ties your implementation hands which could also force a sub-optimal interconnect topology. With the HAPS system you are free to move the DDR between any of the Xilinx Virtex-7 2000T’s SLR’s. Way more flexible and you get to choose the best location for the memory controller which makes sense to your system. Of course you should always bank and SLR match as that’s the requirement of the FPGA and DDR operation.

So at this point I have proved that DDR on a daughter board is possible, you don’t waste IO’s and the additional flexibility of placement results in a prototype implementation optimized to your design requirements. But I’m not finished…… (I know, I bet you were wishing I was)

Lets look at a block diagram of a typical prototyping board. This board has one DDR3 SODIMM connectors hard wired per FPGA. Tell me, how many SoC’s have you seen with multiple DDR controllers? None, that’s how many I’ve seen.

You are forced to implement your DDR controller in one of the FPGA’s and then you have 372 wasted IO’s.

Now look at the HAPS-70 S48 with the memory controller implemented. NO WASTED IO. If for some crazy reason you did want to implement four (or more) DDR controllers on the HAPS-70 S48 you can do that and you still have the flexibility to implement those where you want to. Just plug in a DDR daughter board.

Now that’s what I call the brick held punch! Anyone else want to challenge me :)

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