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.

Unlocking the Secrets of ASIC Clock Conversion

Posted by Michael Posner on December 13th, 2014

open-safe

Warning: Technical Content!

I read an online article this week which flagged an issue with FPGA-based prototyping, clock conversion. Clock conversion is one of the most important aspects to successful prototyping and this week’s blog is dedicated to sharing information enabling you to be successful. Specifically I will cover automated Gated Clock Conversion, GCC, as the user realizes the highest benefits. With automated gated clock conversion you don’t need to maintain a separate RTL code branch for prototyping, you use the golden RTL source. Clock conversion done right ensures the prototype runs at the highest performance functionally equivalent to the source. If you look at the data from the Channel Media survey that Synopsys had conducted you see that for large FPGA-based prototyping, clock conversion is a major challenge.

Clock Conversion, the #1 challenge facing prototypers who do larger than 10M ASIC gate prototyping

Hold on, I forgot to cover why clock conversion is needed for FPGA-based prototyping. It’s one of the three laws, ASIC are not the same as FPGA’s, specifically in this case FPGA’s do not have the same clock resources like ASIC’s do. ASIC designs often use clock gating to reduce dynamic power and have complex clock logic to generate numerous internal clocks. In the ASIC flow, users do Clock Tree Synthesis to balance all the clock paths between the sources and destinations and avoid clock skews between them. The problem is the number of ASIC clocks in the design typically exceed the number of global clock lines available in the FPGAs. There are a limited number of dedicated global clock lines in FPGA devices and Global clock lines cannot accommodate clock generating and gating logic. Thus GCC is needed to convert these ASIC clock structures to FPGA comparable structures. You could do this manually but that’s time consuming and error prone.

One of the three laws of FPGA-based prototyping, ASIC clocks exceed the number of FPGA clocks

In Emulation oversampling type techniques are used to solve this problem, this is where all clocks are resolved to one synchronous clock source and all clocks are driven from derivatives of this clock. The benefit of this technique is that the conversion is fast and practically any type of clock tree structure can be handled. The main two disadvantages are #1 you tank performance as the system frequency is dictated by the slowest clock. #2 the design loses some fidelity as all clocks are synchronous to each other which may not reflect the true asynchronous clock behavior hiding issues in clock domain crossing circuits. Techniques similar to this such as the HAPS Clock Optimization in ProtoCompiler (I think I’ll blog about HAPS Clock Optimization in the future but for today I’ll focus on Gated Clock Conversion) which map clocks to HAPS hardware resources, are getting popular in FPGA-based prototyping as they can help reduce the time to first prototype enabling a prototype to be handed off to the software teams quickly. It will not have the high performance expected by the software engineers but it’s available quickly, handles almost any ASIC clock structures and this gives the prototype engineers a little breathing space to complete the high performance version.

Oversampling, the typical method used by emulation to handle clocks

Gated Clock Conversion, GCC, converts ASIC clock structures to FPGA friendly structures mapped to FPGA clock resources. GCC also needs to handle timing violations due to clock skew created because of clock gating logic. These violations are introduced on paths where the source and destination flops are driven by different clocks. Data from the source may reach the destination quicker/later than the clock resulting in hold/setup time violations in many paths. GCC has to ensure that there is no clock skew between two synchronous clock domains. The GCC capabilities of ProtoCompiler directly addresses both these conversion challenges in a fully automated fashion. ProtoCompiler maps to FPGA resources and moves the generated clock and gated clock logic from the clock pin of the sequential elements to the enable pins. This includes supporting implementation of these structures across block boundaries and across multiple FPGAs as part of partitioning.

Hold time violation example

Tool support of automated gated clock conversion is not a milestone it’s a journey as ASIC coding styles are continually evolving and the tools need to keep pace. ProtoCompiler has an extensive portfolio of supported structures including, but not limited to, Generated Clock, Gated Clock, Integrated Clock Gating Cells, Complex Sequential Cells, Instantiated Cells, Mixed Async Controls, Data Latches and MUX / XOR structures. With the correct clock constraints ProtoCompiler should automatically identify these gated clock structures and convert them to FPGA friendly structures. Below is an example of generated clock identification and the result of the automatic conversion.

Generated clock conversion example showing the result after ProtoCompiler automated conversion

In summary clock conversion is essential to successful prototyping. The ProtoCompiler Clock Conversion capabilities moves the generated clock and gated clock logic from the clock pin of the sequential elements to the enable pins, allowing sequential elements to be tied directly to the source clock, removing skew issues and reducing the number of clock sources in the design making it FPGA-based prototype friendly. Automated Gated Clock Conversion is just one of the many capabilities that ProtoCompiler delivers and is essential for prototypers.

Summary list of ProtoCompiler capabilites and benefits

Don’t forget that the FPGA-based Prototyping Methodology Manual, FPMM, has a section to help understand clock conversion and other ASIC design structure handling. Last week I had the pleasure to hang out with Rene Richter, one of the authors of the FPMM. Rene signed a book copy for me, this copy could be yours if you comment and answer the following question

How many HAPS systems has Synopsys shipped and to how many customers?

A signed copy of the FPMM

Answer the question by comment and if you get the answer right I will contact you to get your shipping addresss.

If you like this or other previous posts, send this URL to your friends and tell them to Subscribe to this Blog.

To SUBSCRIBE use the Subscribe link in the left hand navigation bar.

Another option to subscribe is as follows:

• Go into Outlook

• Right click on “RSS Feeds”

• Click on “Add a new RSS Feed”

• Paste in the following “http://feeds.feedburner.com/synopsysoc/breaking”

• Click on “Accept” or “Yes” or whatever the dialogue box says.

  • Print
  • Digg
  • StumbleUpon
  • del.icio.us
  • Facebook
  • Twitter
  • Google Bookmarks
  • LinkedIn

Posted in ASIC Verification, FPGA-Based Prototyping, Man Hours Savings, Technical, Tips and Traps | No Comments »

Recap of what you missed, impactful blogs from the last 3 months

Posted by Michael Posner on December 5th, 2014

WOW

During a customer meeting last week I found myself explaining many different topic’s all of which I have blogged about over the last couple of months. I suddenly realized that while I blog every week that many of you might not get time to read them every week and miss important information. Below is a list of what I think are the impactful blogs from the last couple of months, just in case you missed them.

The Top 3 Myths of Prototyping – BUSTED. This was a particularly popular blog as it highlights the state of FPGA-based prototyping addressing capacity, time to first prototype operation and debug.

http://blogs.synopsys.com/breakingthethreelaws/2014/09/top-3-myths-of-fpga-based-prototyping-busted/

Solving the ASIC Prototype Partition Problem. Discusses a Synopsys whitepaper on partitioning of an SoC/ASIC to FPGA-based prototype using ProtoCompiler. ProtoCompiler generates a partition solution in minutes, (under 10 minutes in most cases).

http://blogs.synopsys.com/breakingthethreelaws/2014/08/solving-the-asic-prototype-partition-problem/

Abstract Partition Flow Advantage. Sort of goes hand in hand with the solving partition problems blog. This blog focuses on how to use an abstract partition flow to create the highest performance and optimal hardware interconnect and software partition for a given SoC/ASIC.

http://blogs.synopsys.com/breakingthethreelaws/2014/10/abstract-partition-flow-advantage

The Secret Ninja-Fu for Higher Performance Prototype Operation. It’s no secret how to achieve the highest performance prototype, you need an integrated solution and the ability to tailor the hardware inter-FPGA interconnect to the needs of the SoC/ASIC being modeled. Dedicated “fixed” traces just don’t cut it, they restrict the platforms flexibility and introduce interconnect bottlenecks.

http://blogs.synopsys.com/breakingthethreelaws/2014/04/the-secret-ninja-fu-for-higher-performance-prototype-operation/

3 Phase Approach to Successful Prototyping. Pretty much the bible of successful prototyping. Follow these three commandments will lead to successful prototyping.

http://blogs.synopsys.com/breakingthethreelaws/2014/10/3-phase-approach-to-successful-prototyping/

Going vertical for all the right reasons. Blog on developing and the advantages of vertical daughter boards. One of our customers read this post and then went on to develop a stack of custom vertical daughter boards for their specific needs. I’m happy that my blog helped this customer to be successful.

http://blogs.synopsys.com/breakingthethreelaws/2014/07/going-vertical-for-all-the-right-reasons/

Anyway, this should be enough to keep you busy for a week.

  • Print
  • Digg
  • StumbleUpon
  • del.icio.us
  • Facebook
  • Twitter
  • Google Bookmarks
  • LinkedIn

Posted in ASIC Verification, Bug Hunting, Daughter Boards, Debug, HW/SW Integration, IP Validation, Man Hours Savings, Use Modes | 1 Comment »

Mick’s Projects Update

Posted by Michael Posner on December 1st, 2014

The blog is about work in progress or completed

With it being USA Thanksgiving last week you would think I would have relaxed but I must say I’ve been very busy finishing off a couple of projects. So this week’s blog is on these my latest projects.

Firstly I put the finishing touches on the Sauna which was a birthday gift for my wife. It’s a kit from Finlandia which comes with almost everything you need, you just need to build it, roof it, tile the floor, install electric, you know, one of these “two weekend” projects

Outside view of our Finlandia Sauna

I had never done a shingle roof before but I must admit I really like the look. Actually the whole sauna looks and smells (cedar) nice.

The inside of our Finlandia Sauna kit

The inside is nice as well and the 8KW heater warms the sauna up in about 15 minutes even from freezing. It’s been great and the whole family is enjoying sauna time.

Next I completed the conveyor belt toy that I was building. It goes up and down with the use of a linear actuator and the conveyor moves objects like Lego’s from one end and drops them off at the others. In the pictures you can see it transporting from the toy box to the toy truck.  

Mick built conveyor belt toy. Belt runs, conveyor goes uo and down

Notice that I put a Lego plate on it so my son could build his own Lego structure on top of it.

Next project as a big one, a water feature for the local school. The school has an outside nature garden area and they wanted a water feature which the kids could play in, build dams and do all the fun things kids do with water. Well below is a picture of what I came up with.

The water feature I built for the local school

It uses a bilge pump to recirculate water from a tank. The surface is large pebbles and some odd rock columns I found at the local rock shop. It’s 12v battery powered that is recharged with a solar panel. It’s built with materials that can withstand the elements but the school thinks it looks so nice they are going to try and find somewhere to store it in the winter. It’s heavy with all the river rock but at least it has wheels to move it around.

Finally while with the in-laws over the thanksgiving weekend I thought I would play with my father-in-laws wood working lathe. I had bought him some wood blocks for Christmas and given them to him early…. I thought I would use one myself. Here is the result.

Mick Built Bowl, not bad for first time wood working lathe use

Not bad for a first time using a wood working lathe. The wood is Orange wood and it’s color matches it name

Opps, forgot one small project, I modified a box kit toy, the OWI-536 robot, to be wirelessly remote controlled. I don’t have a picture of that but I do have a short video: https://www.youtube.com/watch?v=bTg1RtThVj8 If you are wondering why it’s got a huge battery zip tied to the top stop and ponder this, I had all the parts for the modification laying around the garage.

Did you do any projects over the last couple of weeks? If yes send me a comment and tell me about them.

If you like this or other previous posts, send this URL to your friends and tell them to Subscribe to this Blog.

To SUBSCRIBE use the Subscribe link in the left hand navigation bar.
Another option to subscribe is as follows:
• Go into Outlook
• Right click on “RSS Feeds”
• Click on “Add a new RSS Feed”
• Paste in the following “http://feeds.feedburner.com/synopsysoc/breaking”
• Click on “Accept” or “Yes” or whatever the dialogue box says.

  • Print
  • Digg
  • StumbleUpon
  • del.icio.us
  • Facebook
  • Twitter
  • Google Bookmarks
  • LinkedIn

Posted in Mick's Projects | No Comments »

Instant Productivity with IP Prototyping Kits

Posted by Michael Posner on November 21st, 2014

List of new DesignWare IP Prototyping kits, USB 3.0, UFS, PCIe and more....

This week Synopsys announced that we have expanded the IP Accelerated Initiative with New DesignWare IP Prototyping Kits for 10 Interface Protocols 

  • IP Prototyping Kits enable designers to accelerate prototyping, software development and integration of IP into SoCs
  • Supported protocols include USB 3.0, SSIC, PCI Express 2.0, PCI Express 3.0, DDR3, LPDDR3, LPDDR2, MIPI CSI-2, HDMI 2.0 and JEDEC UFS 

What are IP Prototyping Kits?

IP Prototyping Kits center around a complete, out-of-the-box reference design that consists of a validated IP configuration and necessary SoC integration logic (clock, reset, power management, and test logic) for a specific IP protocol. With these kits, designers can be instantly productive—integrate the IP into their target SoC, optimize the IP configuration, and develop drivers and software applications with real world I/Os and hardware.

The kits include:

  • Synopsys’ HAPS-DX FPGA-based prototyping system with pre-configured IP and SoC integration logic
  • PHY daughter board
  • Simulation testbench
  • DesignWare ARC-based software development platform running Linux or Host PC Connection
  • Reference drivers
  • Application examples

Why is this important?

  • With the increase in SoC hardware and software complexity, companies need more from their IP providers to help meet their time-to-market schedules.
  • Delivering IP blocks alone is no longer adequate to address growing SoC design and integration challenges.
  • Synopsys goes beyond the traditional IP supplier paradigm, redefining what is expected from IP providers to help customers achieve successful IP integration with less effort, lower risk, and faster time-to-market.

When are the kits available?

  • IP Prototyping Kits for all listed protocols are available now.

Additional information

I’m personally very proud of the DesignWare IP Prototyping kits as I feel I helped drive the initial concept. Back in 2010 we had identified the need and in 2011 I presented the slide below at an offsite strategy meeting.

DesignWare IP on HAPS initial concept

The actual DesignWare IP Prototyping kits deliver this and far more and I have to give credit to the product managers who really drove this from concept to product as they did all the heavy lifting. I still like to think that I was there at the beginning.

If you like this or other previous posts, send this URL to your friends and tell them to Subscribe to this Blog.

To SUBSCRIBE use the Subscribe link in the left hand navigation bar.
Another option to subscribe is as follows:
• Go into Outlook
• Right click on “RSS Feeds”
• Click on “Add a new RSS Feed”
• Paste in the following “http://feeds.feedburner.com/synopsysoc/breaking”
• Click on “Accept” or “Yes” or whatever the dialogue box says.

  • Print
  • Digg
  • StumbleUpon
  • del.icio.us
  • Facebook
  • Twitter
  • Google Bookmarks
  • LinkedIn

Posted in DWC IP Prototyping Kits | No Comments »

FPMM Book Achieves Major Milestone, More than 8000 Copies Distributed

Posted by Michael Posner on November 14th, 2014

FPMM Book Cover. FPMM is the holy grail of FPGA-based prototyping unlocking the secrets to successful prototyping

Recently Synopsys promoted that “Synopsys Virtual Prototyping Book Achieves Milestone of More Than 3000 Copies in Distribution to Over 1000 Companies” – http://news.synopsys.com/2014-11-05-Synopsys-Virtual-Prototyping-Book-Achieves-Milestone-of-More-Than-3000-Copies-in-Distribution-to-Over-1000-Companies Virtual Prototyping continues to gain momentum including Hybrid Prototyping, which combines Virtual Prototyping with FPGA-based prototyping. The VP book statistics prompted me to have a look at the FPGA-based Prototyping Methodology Manual, FPMM statistics.

To date there have been over 6000 FPMM downloads across 2800 different companies and over 2500 free books handed out. WOW. I expect a bit of overlap between the two but still that’s got to be over 8000 copies distributed. I’m happy that the FPMM has been able to help so many engineers around the world.

Looking at the challenges facing these prototypers, below image, you can see that conversion of ASIC to FPGA is still rated as #1.

Challenges identified by prototypers who downloaded the FPMM. These challenges are solved by integration of HW and SW prototyping tools such as the Synopsys HAPS and ProtoCompiler products

Actually the #2 challenge, clocking issues, really falls into the this same category. As previously blogged, these challenges are not solved with just software or just hardware changes, they are solved by integration. When the software has built in understanding of the hardware and when the hardware can be customized to the needs of the SoC many of the challenges disintegrate.

A great example of the value of integration is the DesignWare IP Prototyping Kits which are part of the Synopsys IP Accelerated Initiative. DesignWare IP prototyping kits deliver a comprehensive IP subsystem which enables immediate productivity for both Hardware and Software engineers. Individually IP & FPGA-based prototyping deliver value but when combined the value is increased. It’s like the 1+1 = 3.

Talking of IP, DesignWare USB 3.1 IP is now available. http://www.synopsys.com/Company/PressRoom/Pages/usb-3-1-news-release.aspx . I have been talking about USB 3.1 for a while now and blogged about it here. You can also find a video of the DesignWare IP for USB 3.1 running on the HAPS-70 systems here https://www.youtube.com/watch?v=isQ7cvuyoTw

Enjoy

Do you have a topic you would like me to blog about? If so, drop me a comment and I’ll pop it in the queue.

  • Print
  • Digg
  • StumbleUpon
  • del.icio.us
  • Facebook
  • Twitter
  • Google Bookmarks
  • LinkedIn

Posted in FPGA-Based Prototyping, FPMM Methods, Getting Started, IP Validation, Technical, Tips and Traps | 1 Comment »

Dr. Lauro Rizzatti please read my blog, your information is out of date

Posted by Michael Posner on November 7th, 2014

–//–//–//–//–//–//–//–//–//–//–
Dear Dr. Lauro Rizzatti,

   I enjoyed reading one of your recent articles http://electronicdesign.com/eda/hardware-emulation-weapon-mass-verification but was dismayed that you were still quoting limitations from the early years of FPGA-based prototyping. I recommend you refresh your knowledge and read my recent blog on the top myths of FPGA-based prototyping busted. http://blogs.synopsys.com/breakingthethreelaws/2014/09/top-3-myths-of-fpga-based-prototyping-busted/

I’m looking forward to future articles integrating the latest information.

Best Regards

Mick Posner
–//–//–//–//–//–//–//–//–//–//–

Just in case you don’t take the time to read Dr. Lauro’s article the three points of out of date information were on capacity supported, time to first prototype operation and debug.

Quote “Even in the largest configurations, they address designs with about 100 million gates.”

– New Data Point, Synopsys HAPS supports 288 Million ASIC gates

Quote “ Conversely, very long setup time to map a design into a proto board and rather limited design visibility are its two main drawbacks.”

– New Data Point, Synopsys HAPS and ProtoCompiler software accelerated time to first prototype and delivers high visibility debug.

When you correct these mistakes the radar graph in the article changes quite a lot.

Just in case you missed my blog on the top myths here is a direct link to it again: http://blogs.synopsys.com/breakingthethreelaws/2014/09/top-3-myths-of-fpga-based-prototyping-busted/

  • Print
  • Digg
  • StumbleUpon
  • del.icio.us
  • Facebook
  • Twitter
  • Google Bookmarks
  • LinkedIn

Posted in ASIC Verification, Debug, Man Hours Savings | No Comments »

3 Phase Approach to Successful Prototyping

Posted by Michael Posner on October 30th, 2014

Synopsys' three phase approach, best practices and methodology for successful prototyping

In previous blogs I have spoken a lot about automation, features and capabilities which accelerate time to operational prototype and deliver higher performance enabling you to run more software against your design representation. These capabilities are designed to reduce the need for prototyping expertise and effort……..  but not to zero. Anyone who tells you that no expertise or effort is needed is not telling you the whole truth. This was the basis of this blog, “Breaking the three laws” of which the first law is ASIC are FPGA Hostile! Who can tell me what the other two laws are? I know but this is like a quiz for my readers.

Pictures in the blog are posted large so they are easier to read, click on the picture to see the full view version.

Synopsys has created a simple three phase definition for FPGA-based prototyping, including methodology guidelines and I am happy to share them with you. The three phases split into 1. Make Design FPGA Ready. 2. Bring Up Functional Prototype. 3. Optimize Prototype Performance. Follow these three phases and you will be on a path for FPGA-based prototyping success.

Synopsys' definition of the three phases of FPGA-based prototyping. Follow this methodogy for success

Make Design FPGA Ready

This is probably the most important step as the rule of thumb is garbage in, garbage out. There is only so much automation a tool can deliver so understanding the basic needs and best practices for FPGA-based prototyping is essential. Synopsys ProtoCompiler can help here with automated ASIC to FPGA translation, clock conversion and replication as needed. However you should always follow the best practices defined here to yield better results in the final implementation. Don’t forget, full best practices can be found in the FPMM, FPGA-based Prototyping Methodology Manual.

Synopsys' Phase 1, Make Design FPGA Ready. Automation through ProtoCompiler

Bring Up Functional Prototype

Once code is prepared the bring up functional prototype phase is entered. This is the phase with the goal of getting the prototype up and running as quickly as possible, TTFP, enabling the team to hand off a platform to the software developers. The faster they get a platform the most productive they can be. Even if you have traded off a little performance to get the fastest time to prototype your software team will thank you for the fast enablement. ProtoCompiler and HAPS helps here, especially in the partition phase, I recently blogged about this: Abstract Partition Flow Advantage. Another important best practice is to plan your debug needs upfront in this phase, don’t treat it as an afterthought. This is exactly why in the ProtoCompiler flow debug is highlighted ensuring you at least give it some thought.

Synopsys' Phase 2, Bring Up Functional Prototype, use HAPS and ProtoCompiler for fastest time to operational prototype

Optimize Prototype Performance

As you have already delivered an operational prototype to your software team you have a little breathing space now to focus on performance optimizations. In the fast turn-around abstract partition flow ProtoCompiler might have identified some bottlenecks that you skipped past in order to achieve fastest time to prototype. Now you have time to focus on these and other areas of the FPGA-based prototype to squeeze the most out of the solution. An example of this was shared with me recently where the prototype was fully operational at 9 MHz but with a little more effort, new partition and careful analysis of critical paths, the prototype performance was increased to 13 MHz. What a great improvement.

Synopsys' Phase 3, Optimize Prototype Performance. Using HAPS and ProtoCompiler will enable the highest possible customization for performance

So there it is, three simple phased approach ensuring successful prototyping, enjoy!

Happy Halloween, here is the costume that I built, I call it Atomic Dinosaur. I am a construction spray foam  master and it has LED lights down it’s back too!

Mick's Atomic Dinosaur costume

That’s some crazy eyes I’ve got going on…………….

  • Print
  • Digg
  • StumbleUpon
  • del.icio.us
  • Facebook
  • Twitter
  • Google Bookmarks
  • LinkedIn

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

SW Dev Env using ARM-based daughter board directly vs. Hybrid Prototype

Posted by Michael Posner on October 24th, 2014

Amazingly this is a REAL animal, it's called a Liger

This week’s blog is a bit of a mashup (Yes that is a real word, a mashup, in development, is something that uses content from more than one source to create a single new offering) as I am pulling together two topics to create one. The #1 usage case of prototyping is for early software development. You can do this very early, pre-RTL using Virtual Prototypes, later in the design cycle with FPGA-based Prototypes but it’s the bit in the middle that this week’s blog examines.

The bit in the middle is typically unit level or IP validation with the goal of early software development before the rest of the subsystem is available. The DesignWare IP Prototyping Kits : http://www.synopsys.com/IP/ip-accelerated/Pages/ip-prototyping-kits.aspx were designed to address the need for immediate productivity and early software development for DesignWare IP’s. The kit includes the actual DesignWare IP modeled on HAPS-DX and an ARC based Software Development Platform

The ARC Software Development Platform based DesignWare IP Prototyping kit

The question which has been raised a couple of times is what if you are not using an ARC processor in your end SoC? At this point I usually start probing a little more as to what type of software is being developed, if its physical layer and processor specific then yes the ARC software development platform is not going to work for you. If it’s higher layer software then typically the software engineer does not care as it’s layers above and abstracted from the physical execution machine. But what do you do in the case where you need physical layer and processor specific software development?

Lets use the example that you want to enable early software development on an ARM-based system representation and you still want to validate your design under test modeled on a FPGA-based prototype. The problem is that your SoC engineers have not complete the subsystem design and/or you don’t have access to the RTL to put the processor subsystem on the FPGA-based prototype along with your DUT.

One solution would be to do similar to what Synopsys did with the DesignWare IP Kits and that is connect the FPGA-based prototyping platform to a physical daughter board containing an ARM-based subsystem. One of the possible ways to do this is to use an off-the-shelf Xilinx Zynq based daughter board. The Zynq device includes a Dual Cortex-A9 MPCore processor subsystem and provides the ability to connect this to the FPGA-based prototyping platform via an AXI tunnel across typically FMC connectors. This is true for the HAPS series where you have the ability to connect the Zynq based board to HAPS via FMC cables.

Xilinx Zynq ARM-based subsystem including Dual Cortex-A9 MPCore's

Great right? Hummm…. Seems too good to be true…… Yes, you are right, this use mode is a trade-off. While you can execute ARM-based code against your prototype you are not running the software against YOUR ARM-based subsystem. You are stuck with the processor configuration hard-coded into the Zynq device which you know will never match your SoC subsystem. Also, in the case of the Zynq it’s the 32bit processors not the 64bit versions. There is a better way to enable early software development using a processor subsystem which is a better match to your SoC’s subsystem, it’s the Hybrid Prototyping approach.

I’ve blogged about this before, one such case was Zoro’s use of Hybrid Prototype for early software development for USB 3.0 : http://blogs.synopsys.com/breakingthethreelaws/2014/06/zoro-delivers-hybrid-prototype-for-early-software-development/

The advantage of using a Hybrid Prototype rather than a fixed hardware daughter board is that the virtual processor based subsystem can be tailored to more specifically match the SoC subsystem design. New to virtual prototyping? Don’t worry, Synopsys provides ARM Virtual Development Kits (VDK’s) : http://www.synopsys.com/Systems/VirtualPrototyping/Virtualizer-Development/Pages/vdk-family-arm.aspx to jump start your development. These VDK’s can be used at the starting point for your customization to match your SoC’s need. This full virtual environment is expanded to a Hybrid Prototype with the use of the off-the-shelf transactors which are a bridge between the TLM virtual and the RTL hardware systems. You are not sacrificing performance either as the Synopsys Hybrid Prototyping solution enables asynchronous operation between the Virtualizer and HAPS ensuring that the software env executes at speed as well as the hardware env which is typically required to keep real world interfaces alive.

Hybrid Prototype. ARM-based Virtual Development Env running with the HAPS-based prototype

What a mashup !!! It’s clear to me that Hybrid Prototyping is a far better solution to enable early software development as you can customize the processor subsystem to more precisely match the SoC. This way the software code created and executed on the prototype is a closer or direct match to the software which will run on the SoC.

  • Print
  • Digg
  • StumbleUpon
  • del.icio.us
  • Facebook
  • Twitter
  • Google Bookmarks
  • LinkedIn

Posted in ASIC Verification, Daughter Boards, DWC IP Prototyping Kits, Early Software Development, Hybrid Prototyping, IP Validation | 1 Comment »

Abstract Partition Flow Advantage

Posted by Michael Posner on October 20th, 2014

Which came first? The Chicken or the Egg?

It’s the age old question, what came first, the chicken or the egg?

When we ask this question about FPGA-based prototyping then the answer uncovers some interesting facts about the evolution of this technology. When first utilized most customers would build their own boards and tailored them to the exact SoC project’s needs. The advantage of this is that the board is specifically designed for the SoC, meaning it included the exact real world interfaces needed and an interconnect architecture specifically matching the SoC architecture. The result of this customization was the best FPGA-based prototyping hardware for the SoC project. Of course because the hardware was customized for the exact project needs the hardware was typically not reusable in the next projects.

To address the need of reusability along came 3rd party commercial FPGA-based prototyping boards. They offered a generic FPGA-based prototyping hardware solution that enabled reuse across projects. But at what technical cost we ask ourselves? The boards offered many real world interfaces but the interconnect (PCB traces) were not customized to the needs of the SoC being modeled. The result sometimes was that the highest performance could not be reached as you had to force fit the SoC prototype implementation to the fixed interconnect topology. This force fitting means that high signal multiplexing ratios were needed reducing the system performance. I blogged (How IO Interconnect Flexibility and Signal Mux Ratios Affect System Performance) about the relationship between these before. The HAPS-50 and HAPS-60 systems provided both PCB traces and flexible connector options which started to address the need for commercial hardware that could be customized directly to the needs of the SoC. The HAPS-70 systems revolutionized this approach by providing the ability to tailor the system to the exact requirements of the SoC using intelligent high performance links. I have previously blogged (UFC: Cables Vs. PCB Traces) about the fact that the performance of these flexible links is as good as pure PCB traces. I’ve also blogged (The Secret Ninja-Fu for Higher Performance Prototype Operation) about how this flexibility enables higher performance prototypes.

But the problem is not that simple to solve. SoC prototypes are multi-FPGA so sometimes large blocks could be split up across multiple FPGA’s which add new interconnect requirements. So how are these handled as you don’t know about them until you come to partition the SoC? The answer is that you need an integrated solution which can quickly generate a partition from an associated interconnect architecture but also provide the flexibility to adapt it. This is what Synopsys calls the abstract partition flow with ProtoCompiler and HAPS-70. In summary, the combination of ProtoCompiler and HAPS-70 enables you to quickly create an abstracted interconnect architecture representation, generate a partition solution for it, then incrementally customize it based on the needs of the SoC. Let me share an example which was from the Imagination PowerVR 6XT on HAPS collaboration case study presented at recent SNUG events.

In the ProtoCompiler flow for HAPS-70 you first create an abstract representation of the interconnect between FPGA’s. This is very quick to create as it’s a simple text file with TCL commands defining the connections. The picture below is an example of such an abstract system interconnect. Remember that there are no fixed traces between FPGA’s but this abstract is not exact connections, just a representation of possible IO interconnections. Then run ProtoCompiler

ProtoCompiler for HAPS-70 abstract partition flow

ProtoCompiler in this case study took less than 1 minute to come to a five Xilinx Virtex-7 FPGA partition. Remember that ProtoCompiler is HAPS-Aware so it incorporates the hardware capabilities in automatically. The picture below shows some of the reports from ProtoCompiler at this point. Firstly the expected FPGA utilization and secondly, the most important, signal to multiplexing ratio report.

Abstract partition flow report showing utilization and prototype bottleneck

The mux ratio report has highlighted the worst case mux-ratio, 16, on a path from FPGA A to FPGA D. Remember that the higher the mux ratio the lower the system performance. Within 1 minute ProtoCompiler not only partitioned the design but it also identified the main bottleneck based on the abstracted interconnect architecture. The flow is incremental so at this point you go back to the abstract file.

Abstract partition flow rapid update

We know the HAPS-70 interconnect is flexible so in the abstract flow we theorize that we need more physical IO between FPGA A and FPGA D. In our case we are going to raise the IO count from 200 to 300. This is a one line change in the abstract file as seen in the below picture.

Results of 2nd pass of ProtoCompiler for the HAPS-70 showing higher performance from lower TDM ratio and customized interconnect architecture

ProtoCompiler is re-run and again generated a new partition result in a matter of minutes. Looking at the mux report now you can see that the more dense IO between FPGA A and FPGA D has relived the multiplexing ratio. The new ratio is 12 which means our prototype will run at higher performance. This is the solution to the chicken and egg question, you don’t want to fix your hardware interconnect architecture until you have a partition solution. Then based on the partition solution you want to fine tune the hardware to best match the partitioned SoC requirements. The Synopsys solution of ProtoCompiler and HAPS-70 is the only integrated solution that provides this capability. This rapid and incremental flow results in hardware that is tailored to the exact SoC prototyping requirements and of course you maintain the reuse aspect as the hardware can be reconfigured to your next SoC project’s needs.   

Finally….. I have been build a new toy, this is a conveyor belt toy with working conveyor belt, articulation and many lights.

Conveyor belt toy design and built by Mick

You can see the toy in action here: https://www.youtube.com/watch?v=2aVdOXWo-2Q

  • Print
  • Digg
  • StumbleUpon
  • del.icio.us
  • Facebook
  • Twitter
  • Google Bookmarks
  • LinkedIn

Posted in Man Hours Savings, Mick's Projects, System Validation, Use Modes | Comments Off

Rabbets, the Importance of Bank/SLR 1-1 mapping and Certify 2014.09

Posted by Michael Posner on October 10th, 2014

Really nothing to do with this blog but I love fast cars and track race

Rabbets, the Importance of Bank/SLR 1-1 mapping and Certify 2014.09, starting in reverse order this week.

Certify 2014.09 is now available and we’ve packed it with new capabilities. Below is just a snippet of the new additions.

  • Advanced synthesis options deliver improved timing QoR, correlation and rapid timing closure. On average 5-6% timing QoR improvement. Just flip a switch, non-disruptive use mode.
  • Exploratory P&R,  Improved Timing QoR, better routability and runtime by optimizing P&R setting based on the design. Determines different P&R settings based on the design. Runs multiple parallel P&R jobs and gets the best results. Compare QoR Results and Save Best P&R Settings. Up to 8% improvement in post  P&R results
  • Distributed Processing, Allows running different jobs on network machines. Improved Runtime and delivers quicker turnaround.

Onto Rabbets, who here knows what a Rabbet is? No, that’s not a typo, Rabbet……. Anyone, Bueller…. Bueller…. Bueller….. ok, no one, good, as until recently I didn’t know what it was either. Simply put it’s a groove cut into the edge of something: http://en.wikipedia.org/wiki/Rabbet

Rabbet terminology. Used on the new HAPS HT# connector board

Why am I talking about Rabbet edges you ask? Well we have just released a new daughter board for HAPS which is designed to connect the center rows of Hapstrak 3 connectors to it’s adjacent FPGA partner East/West

New connector boards mounted on HAPS system. 1-1 bank and SLR mapped, East West connectivity

It’s a small board with very high signal integrity but we found that it was pretty tough to remove, enter the rabbet. A small groove cut in the edge of the board ensures that the included little plastic pry bar can be used to safely remove the board. (Remember that ESD precautions should always be observed).

Picture showing the Rabbet edge on the new connector board for HAPS East West connectivity

On the HAPS systems the Hapstrak 3 (HT3) connectors are bank and SLR mapped 1:1 with the Xilinx Virtex-7 2000T FPGA pins. No HT3 connector IO crosses Xilinx’ SuperLogic Region, SLR, boundaries. This is hugely important as ensures that additional SLR crossings are reduced as the Xilinx P&R tool naturally can route directly to pins of a connector within the associated HT3 connector.

 See the two examples below from a real multi-FPGA SoC design which was targeted at both a board with connectors that are not bank and SLR matched and the HAPS-70 systems with 1-1 bank and SLR mapping.

Typical BYO or 3rd party prototyping board. Lack of bank and SRL mapping reduces performance and no amount of software can fix this

Wow, the SLR crossing adds a 2x delay on the critical performance path, this tanks system performance

HAPS-70 systems with 1-1 bank and SLR mapping to Xilinx Virtex-7 2000T FPGA pins

No additional forced SLR crossing with HAPS. This is a pure hardware capability, no amount of synthesis and P&R software can work around this.

  • Print
  • Digg
  • StumbleUpon
  • del.icio.us
  • Facebook
  • Twitter
  • Google Bookmarks
  • LinkedIn

Posted in Daughter Boards, Man Hours Savings, Use Modes | Comments Off