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.

Maximizing Debug Visibility in Xilinx UltraScale FPGA-Based Prototypes

Posted by Michael Posner on May 22nd, 2015

While the Xilinx UltraScale VU440 FPGA device looks to rocket FPGA-based prototyping forward in respect to ASIC gate capacity is sadly does nothing to help you debug your prototype. If anything it amplifies the engineers debug challenge by enabling huge volumes of RTL to be modeled. The HAPS and ProtoCompiler integrated solution debugging capabilities have revolutionized FPGA-based prototype debug but engineers still want more. Proof of this can be seen below in the contrast between the 2011-2012 and 2013-2014 FPMM survey data. The question asked is to rate the most challenging aspect of FPGA-based prototyping. You can see that the priority on debug increased significantly in the 2013-2014 timeframe over the 2012-2013 range.

This is a long blog but I hope you read to the end as it’s filled with great technical data and a previews of what’s coming in the HAPS next generation systems.

Synopsys FPMM Survey data from 2012-2013

Synopsys FPMM Survey data 2013 to 2014

This shift could partly be due to HAPS ProtoCompiler successfully solving the 2012-2013 main challenge of Time to Prototype. It’s logical that the quicker you can get your DUT onto the prototype the quicker the need for debug. HAPS ProtoCompiler can generate results in as little as 5 days from initial RTL drop and incremental FPGA images overnight making HAPS prototypes highly productive. The other factor driving the increased need for debug is that the overall size(in ASIC gates and number of FPGA’s) of the FPGA-based platform has increased significantly. Whereas 1,2 and 4 FPGA platforms used to be the mainstream maximum sized prototype this has been superseded with prototypes of 8,12 or more FPGA’s (we even have customers using HAPS systems consisting of 32 FPGA’s) thanks to the HAPS seamless scalability and the modularity of the HAPS ProtoCompiler tool flow easing the modeling of the SoC DUT. When you add the Xilinx UltraScale VU440 device into the mix with 2.2x capacity over the Virtex-7 2000T you can understand why debug is a priority for prototypers.

Debug must no longer be treated as an afterthought, I see a lot of this when I visit and chat with prototypers. HAPS ProtoCompiler has helped as it moved some decision making on debug to the top of the flow ensuring that engineers don’t just focus on partitioning and implementation. Always accounting for debug is the key to success.

Here is a simple example of the impact of not accounting for debug upfront. In our picture below the SoC have been partitioned and implemented across four FPGA’s. Note that debug was NOT considered when the partition was created. (I should note, this is a real life case, engineer does not use HAPS or ProtoCompiler). You can see the clouds of logic and the arrows of interconnect between FPGAs.

Traditional prototype without debug

However the engineer needed to debug (of course) their DUT so they then tried to force fit debug into the partitioned design. Unfortunately as they had not accounted for debug when they did the original partition the addition of the debug logic, even though it was pretty light, still forced the partition and interconnect between FPGA’s to change. In the picture below you can see that the logic in one FPGA was over utilization and had to be split into another FPGA. This is hugely invasive to the prototype. Basically the engineer had to begin from scratch, re-partition the design, re-do the interconnect and pin multiplexing. It was horrible.

Traditional prototype with debug inserted as an after-thought

Synopsys does not want other prototypers to face this challenge in the future so we have solved it as part of our next generation solution. In essence a debug infrastructure which has the capability to capture 1000’s of debug signal bits per-FPGA at prototype platform speed is built-into directly into the HAPS hardware and the HAPS ProtoCompiler tool flow automated the implementation ensuring its seamless and minimally intrusive to the user DUT. As with the solution today, the engineers view the debug data in familiar RTL and waveform formats compatible with Synopsys’ Verification Continuum tool set.

HAPS Next Generation built-in, always available debug

Dedicated debug data storage memory and dedicated debug interconnect communication scheme is built into the HAPS hardware so you are not utilizing FPGA embedded memory blocks or precious FPGA standard IO’s for debug. The HAPS debug IP infrastructure is pre-compiled and instantiated automatically by HAPS ProtoCompiler making the addition of debug almost seamless to the user. As its pre-compiled and validated, we ensure that timing within the debug hub IP and infrastructure is always met. The design interface to the debug interconnect infrastructure is asynchronous and pipelined minimizing any effect of timing closure based on the users design and performance constraints.

HAPS Next Generation built-in debug infrastructure

As the debug infrastructure is automatically and always accounted for during the partition and implementation phase within HAPS ProtoCompiler its minimally invasive and overall seamless to the engineers. This is in respect to both the debug logic IP and the debug interconnect communication as that is all handled via dedicated routes. As noted above, these dedicated debug routes are not FPGA standard IO’s. FPGA standard IO’s are prioritized for user defined interconnect between FPGA’s in the same flexible HAPS manor maximizing system performance.

HAPS Next Generation built-in debug, minimally intrusive to DUT

Finally, this new solution is modular and scalable across system so as your prototype scales from 4 to 8 to 12 to more FPGA’s, so does the debug. There was a little preview to this in last week’s blog when I posted a picture of one of the new systems. The systems include an external debug panel that enables debug to be chained across systems. Simply connect the dedicated debug routes between systems and the HAPS ProtoCompiler tool flow does the rest by providing a unified debug view back to the RTL golden source code regardless of the number of FPGAs in the prototype partition.

HAPS Next Generation built-in debug multi-system seamless modularity and scalability

There we go. Built-in, always available, minimally intrusive debug  where the data is presented in context of the original source RTL for a simulator-like debug experience. Don’t forget, you still have other great HAPS and HAPS ProtoCompiler debug capabilities such as Real Time Debug, where design signals are routed seamlessly to a daughter board for capture using a logic analyzer. You can also create custom debug capabilities utilizing the HAPS Universal Multi-Resource Bus, UMRBus.

I hope you found this blog interesting. To get my blogs sent directly to you subscribe now.

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.

I’m traveling again next week so I might be tardy in respect to the next blog. Stick with me though as I have some more exciting progress and capabilities to share with you.

Oh, if you liked this blog, post a comment and let me know. If you didn’t like this blog post a comment and let me know that as well. You only improve with feedback and I welcome it. Of course this is blog post ~150 so you might have wanted to post a comment sooner if you didn’t like what I write.

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

Posted in Debug, UltraScale | No Comments »

UltraScale Based HAPS Pictures

Posted by Michael Posner on May 15th, 2015

I have been traveling internationally this week and am rather jet lagged so I’m just not feeling a blog this week. However I did get sent a picture of one of our UltraScale based HAPS development systems and thought I would share.

UltraScale Based HAPS System

Pretty isn’t it. This one is only 1/2 populated which explains the blanking plates on the left hand side. I like the silver colour but I think we only did this on the development systems. Those with keen eyes and access to the existing HAPS-70 systems will be able to quickly spot the new additions such as the built-in debug ports, Ethernet, extra HT3 connectors and the addition of a third fan port. Of course these are only the visible changes, I can’t wait to tell you about all the other new capabilities. However you will have to wait as I’m boarding my international flight bringing me back home. Bye for now

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

Posted in UltraScale | No Comments »

Expectation setting for FPGA-based prototyping

Posted by Michael Posner on May 8th, 2015

The myths of FPGA-based prototyping are still being proliferated and I have taken on a quest to educate the world on what FPGA-based prototyping really delivers. The latest myth propagation is seen below and was cut from a recent posting on a well-known industry website. You are all smart, you will be able to work out where it comes from. Fun read.

Myths of FPGA-based prototyping being propogated

Charlie hits the nail on the head, you need both speed (for Real World IO and OS boot) along with accuracy.

However the comments around it are what I am talking about, they continue to propagate the myths. The top 3 recapped :-

  • Capacity limited to less than 100 Million ASIC Gates
  • It takes months to get prototype working
  • Limited debug visibility

I’ve busted these myths a number of times but you know what they say, tell’em once, tell’em twice, tell’em three times then hit’em with a stick. (ok so I added the stick bit to the saying but that was to increase the humor level of my blogs as some have complained I’m become far too serious)

Capacity is not limited to 100 Million ASIC gates. Proof point: HAPS-70 scales today to twenty four (24) FPGA’s supporting 288 Million ASIC gates and we even have customers successful in prototyping with more FPGA’s. High performance is maintained with operational performance only limited by pin-multiplexing ratio’s. These large sized prototypes can operate in the 10’s of MHz ranges. If I look into my crystal ball (which is very accurate) I see a vision of a HAPS platform supporting in excess of 1 Billion ASIC gates while maintaining scalability and flexibility to support a complete range of designs.

Time to first prototype does not take months, customer usage results with HAPS ProtoCompiler exhibits proven success in as little as one week. The note in the screen shot above says that RTL needs to be rewritten for FPGA, this is not a true fact. Many transformations for FPGA are fully automated in HAPS ProtoCompiler so you maintain a single “Golden” RTL code base.

Debug capabilities have leapfrogged over the last couple of years with HAPS Deep Trace Debug delivering visibility of 1000’s of debug signal bits across multiple FPGA’s and across multiple system setups. While this is not the same level as you have in a simulator or in an emulator you have to remember that you don’t actually need full visibility as typically the RTL being prototyped is more stable as it has passed the block level tests. And just wait and see what my crystal ball is predicting for debug in the next generation of HAPS systems.

So join with me on the quest to rid the world of the myths of FPGA-based prototyping.

  • Become educated: Read the whitepaper dispelling the myths of FPGA-based prototyping
  • Subscribe to my blog and stay up to date with the latest in FPGA-based prototyping

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, Bug Hunting, Debug, Early Software Development, HW/SW Integration, Man Hours Savings, Performance Optimization, System Validation, Use Modes | No Comments »

Comparison of Prototyping bridge vs. Hybrid Prototypes

Posted by Michael Posner on May 1st, 2015

DesignWare Hybrid IP Prototyping Kits

This week Synopsys’ announced the availability of the DesignWare Hybrid IP Prototyping Kits: http://www.synopsys.com/IP/ip-accelerated/Pages/hybrid-ip-prototyping-kits.aspx The Synopsys DesignWare® Hybrid IP Prototyping Kits pre-integrate a Virtualizer™ Development Kit (VDK) and a DesignWare IP Prototyping Kit to accelerate IP prototyping, software development and integration of DesignWare IP in 64-bit ARM®-based designs. Hybrid IP Prototyping Kits enable designers to accelerate hardware/software integration and full system validation, thus reducing the overall product design cycle. The included Linaro® Linux® software stack, reference drivers, and pre-verified DesignWare IP reference design allow users to start implementing and validating IP in an SoC context in minutes.

Now I’ve spoken about Hybrid Prototyping a number of times, the most recent was Valuable Software Driven Validation where I discussed how users are deploying Hybrid Prototyping to accelerate IP validation. The DesignWare Hybrid IP Prototyping Kit of course comes with validated IP, Synopsys does that work, but many IP’s required customized drivers which are application specific. It’s this software development, within the context of a CPU subsystem, which the kit focuses on accelerating.

I was asked a question this week which I think is important to clarify, what is the difference between a prototyping bridge and Hybrid Prototyping. A prototyping bridge is a native PCIe host to prototype physical connection with standard interfaces such as AMBA AXI to connect to the user design under test in the hardware. This is what I have previously called a memory mapped interface. Synopsys provides such a prototyping bridge example, you can find it in SolvNet buried in the HAPS documentation

HAPS Prototyping bridge example on SolvNet

A prototyping bridge like this is good for test cases where you want to stream data to a design under test on the prototyping hardware. You will need to write a customized PCIe driver, which is memory mapped on the host workstation, which you build on top of to create the custom application test code.

HAPS PCIe Prototyping Bridge example

Within the small context of this need the prototyping bridge works well. However its usefulness reduces very quickly due to the following limited capabilities

  • Only provides  1x AXI master and 1x AXI slave interface, what happens if you need more?
  • No support for mixing with other AMBA protocols or sideband signals (interrupt, GPIO, etc.)
  • No control over the AMBA protocol parameters (you get what you get through the PCIe interface)
  • Manually effort to instantiate into design (Might require changes in golden RTL to fix interfaces offered)

I’m not saying there is not a place for this type of prototyping bridge, our own DesignWare USB IP team use such a bridge to enable the standard, off the shelf PCIe based USB host drivers to be tested against the IP. It’s a standalone environment and as the driver is PCIe based it’s not directly reusable when the IP is integrated into a  the end ARM/ARC/MIPS/Tensilica/Other SoC.

Enter Hybrid Prototyping from Synopsys. Hybrid has none of the restrictions as noted above with a prototyping bridge. You can insert multiple transactors into a design, configure them to your direct need in an automated fashion. With Hybrid the software that you are running is the same as the end SoC software, as in in the example of an ARM-based SoC you are executing ARM code.

Hybrid Prototyping design with CPU subsystem and RTL design

The key to Hybrid Prototyping is the transactors. A transactor translate between the Virtual SystemC abstract level across to cycle accurate protocol specific pin level interface. Synopsys delivers off the shelf transactors for the AMBA protocols and more. There are two sides of a transactors, the software side and the RTL hardware side.

HAPS high level view of Hybrid Prototyping transactors

On the software side, the interface which is exposed to the user is the abstracted SystemC level interface, read/write etc. This is what software engineers understand, the transactor looks just like the software that they are used to coding against. All the nitty gritty engineering of the transactors is done by Synopsys so the user can become immediately productive.

HAPS Transactor, Software side

On the hardware side, the interface is RTL, again all the deep protocol stuff is done by Synopsys so the engineers instantiate the transactor into their design just like any other AMBA based design block.

HAPS Transactor Hardware side

The HAPS ProtoCompiler flow automatically understands the transactors and seamlessly connects up the physical interface, UMRBus, with no user intervention.

The Virtualizer environment delivers amazing software debug as well, here is a view of the software debug capabilities which the DesignWare Hybrid IP Prototyping kit delivers.

VPExplorer, amazing software debug

So in a comparison of a prototyping bridge and Hybrid Prototyping, Hybrid wins hands down.

  • Predefined environment, fully supported, configurable, automatic hook-up in user design
  • Runs SoC specific software which can be directly run on the final product
  • Multiple protocols, multiple instances per design
  • Amazing software debug, especially for multi-core

In most cases a Hybrid Prototyping environment can replace the use of a prototyping bridge because it can also be driven via a C/C++ or native TCL interface, just like what you would do with the prototyping bridge. The additional advantage is that the same environment can easily be expanded to a full Hybrid Prototype with Virtual Prototype connection without having to change the design.

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

Posted in ASIC Verification, Debug, DWC IP Prototyping Kits, Early Software Development, HW/SW Integration, Hybrid Prototyping, In-System Software Validation, IP Validation, Use Modes | No Comments »

SYNOPSYS SETS NEW STANDARDS FOR FPGA-BASED PROTOTYPING WITH COMPLETE PROTOTYPING PLATFORM

Posted by Michael Posner on April 23rd, 2015

SYNOPSYS SETS NEW STANDARDS FOR FPGA-BASED PROTOTYPING WITH COMPLETE PROTOTYPING PLATFORM…. Yes, we did this way back in 2010 with the launch of the HAPS-60 complete solution, and then raised the bar in 2012 with the launch of the evolutionary HAPS-70 complete solution. Synopsys HAPS is a proven integrated solution delivering the fastest time to operational prototype, highest system performance, superior debug and advanced capabilities including Hybrid Prototyping and global server farm access.

HAPS Solution

This week I’m feeling feisty so my blog is going to be a little more edgy than normal. The launch of the HAPS-60 series in 2010 delivered the first integrated FPGA-Based prototyping solution with key capabilities such as automated deployment of unique HAPS High Speed Time-Domain Multiplexing (pin-multiplexing) schemes in Synopsys’ Certify. Host connected, globally accessible hardware with the HAPS Universal Multi-Resource Bus, UMRBus, as well as advanced data streaming and platform connectivity. The solution included integrated superior debug visualization for bug hunting. Yes, in 2010, over 5 years ago, Synopsys set the new standard for FPGA-based prototyping with a comprehensive prototyping platform. Since then, our solution has rapidly evolved delivering far greater value.

HAPS-70 hardware, just becuase I like the picture

The HAPS-70 (which, by the way, was selected as Electronic Design http://electronicdesign.com/ “Best of 2012” recipient) with fully integrated HAPS ProtoCompiler, the prototyping implementation environment, accelerated the deployment of prototypes by providing advances in automation including time to first prototyping modes and timing biased partitioning.

HAPS ProtoCompiler, the leading FPGA-based prototyping implementation tool

Synopsys has always been the leader in debug visibility and the HAPS integrated debug capabilities enables at speed debug across multiple-FPGA’s in addition to integration with the leading Synopsys Verdi debug visualization software.

HAPS Debug, superiour debug visualization

The HAPS UMRBus has for multiple generations enabled the hardware to be a globally accessible resource for server farm and multi-user scenarios in addition to enabling data streaming modes and Hybrid Prototyping capabilities.

HAPS UMRBus, global access, farm usage, advanced data streaming modes

At about the same time as the HAPS-70, Synopsys launched the first commercial Hybrid Prototyping solution. HAPS Hybrid Prototyping enables HAPS to be connected with Virtualizer, Virtual Prototype delivering early prototyping capabilities, IP and in context validation scenarios.

HAPS Hybrid Prototyping, accellerating the availability of prototypes

Talking of IP, Synopsys is the leader in interface IP and offers DesignWare IP Prototyping kits for immediate software development and prototyping of key IP titles.

DesignWare IP Prototyping Kits, immediate availability

All this wrapped with the global expert support, eco-system of HAPS Connect partners, professional services. This is how we define a complete solution. What I am trying to illustrate is that Synopsys is now, and will continue to be the technology leader in FPGA-based prototyping. Synopsys continues to invest and the HAPS next generation solution will raise the bar again ensuring that our integrated FPGA-based prototyping products meet your requirements today and way into the future.

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

Posted in Admin and General, ASIC Verification, Bug Hunting, DWC IP Prototyping Kits, Early Software Development, HW/SW Integration, Hybrid Prototyping, In-System Software Validation, IP Validation, Man Hours Savings, Milestones, Performance Optimization, Real Time Prototyping, Support, System Validation, Use Modes | 1 Comment »

Reduce WNS by up to 60%, sometime more

Posted by Michael Posner on April 17th, 2015

Bats with White Nose Syndrome. Please help reduce the spread of this and wash boots, clothes and equipment between caves

The WNS I am talking about is Worst Case Negative Slack and not White Nose Syndrome, a disease in North American bats which, as of 2012, was associated with at least 5.7 million to 6.7 million bat deaths. Please help and stop the spread of this nasty disease. Poor little bats have no defense against it. The WNS I’m going to talk about is Worst Case Negative Slack of a prototyping design, reduce WNS and prototype execution performance increases.

A couple of weeks back I blogged on Timing Biased Partitioning and received a number of follow up questions and comments. This blog is to hopefully answer those and provide more information on the Synopsys capabilities to optimize for the highest system performance on your HAPS-based prototype.

The first question, actually statement was from one of the Synopsys engineers who correctly pointed out that my blog title only covers a fraction of what HAPS ProtoCompiler does in the area of prototype performance optimization. In addition to reducing the number of multi-hop paths during the automated partition stage, ProtoCompiler can also reduce the path length and automatically use a lower pin mux ration on multi-hop paths. The combination of these result in the highest performance prototype. In essence timing biased capabilities cross the partition, system route and system generate stages of the prototyping design flow.

Something that I did not mention in the previous blog was the recommendations for pin mux ratios for optimized performance, so here they are.

  • All paths are not critical
    • Some paths don’t need to be fast
    • False paths and asynchronous clock crossing
    • Slow clocks and debug paths
  • Some paths are just fast, pipeline paths with little logic
  • Don’t use one HAPS HSTDM ratio everywhere
    • Lower ratios on critical paths
    • Higher ratios on non-critical path
    • HAPS ProtoCompiler supports ratios up to 128:1
  • HAPS Hardware Traces are precious
    • High ratios on non-critical paths, frees up traces for critical paths (HAPS flexible interconnect)
  • No cost to mixing ratios with HAPS HSTDM
    • Source sync clock is shared across ratios
    • No overhead of mixing ratios

Much of this is automated in HAPS ProtoCompiler but the 2nd question was why these timing biased capabilities are not default “ON”. The answer is that typically the goal at the start of the project is Time to First Prototype (TTFP), and you sacrifice performance optimization to get a valid solution in the least amount of time. Optimization for performance, while automated, increases the runtime of the tool. The recommendation is that you utilize the HAPS ProtoCompiler TTFP mode to generate a feasible solution and hand this off to your developers. While it might not be performance optimized your developers will thank you as you delivered it very quickly. They can be very productive debugging the initial HW/SW integration, board support software and completing initial OS boot procedures. With your developers busy and happy you have an extra day or so to optimize the platform for performance. Now you turn on timing biased capabilities as you can afford the slightly longer runtime to a feasible solution. This is an iterative process as you play with partition, route and physical interconnect on the HAPS systems.

The results of HAPS ProtoCompiler timing biased capabilities are astonishing and I was able to get my hands on the results of these capabilities from a suite of test designs. This suite of designs consist of real customer designs which we have gather over time (with permission). The goal of this testing was to judge the automated capabilities of the tools.

HAPS & ProtoCompiler test suite of designs for timing bias optimization benchmarks

First the “hop” reduction with multi_hop_path optimization enabled is amazing. It’s hard to see in the picture but all designs yielded multi-hop path reduction with the capability enabled.

HAPS ProtoCompiler multi-hop reduction. Less hops = higher system execution performance

Second, the effect to worse case negative slack showed up to 60% reduction. Reduce WNS and performance is improved !!!!

HAPS ProtoCompiler timing bias optimization WNS reduction yields up to 60% execution performance improvement

The funny thing is that the effect on runtime is not huge so while above we recommend a TTFP flow first and then a timing optimized flow you can be successful in generating a timing optimized solution right out of the starting gate. Well at least a version where you have enabled the capabilities but spend no time analyzing the output. Remember, to get the most out of the HAPS solution you should tailor the HAPS hardware flexible interconnect to the SoC partition needs.

I’ve not had much time for projects recently and the next couple of months are busy, busy, busy with business stuff but I have been making slow progress on my new gaming console in a briefcase. Below you can see pictures of the custom controllers, I had to make them small to ensure they fit inside a briefcase. The second picture is a mock up of the monitor and controllers in the briefcase. You open the case and the monitor pulls up and can be rotated for vertical and horizontal play. The whole system is powered by two 7 ah 12v sealed batteries which based on the current draw should enable 5 hours of play before needing to be charged. There are 912 games installed, all the old school favorites like pacman, donkey kong, street fighter, 1945 etc…

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.

Mick Built Toys, new gaming console in a briefcase controllers

Mick Built Toys, prototype of monitor and controllers in a briefcase

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

Posted in ASIC Verification, Early Software Development, HW/SW Integration, In-System Software Validation, Man Hours Savings, Mick's Projects, Milestones, Performance Optimization, Project management, System Validation, Use Modes | No Comments »

Prototyping Over 700 Million ASIC Gates Using Xilinx Virtex-7 2000T FPGAs

Posted by Michael Posner on April 10th, 2015

HAPS Super Chain Testing at Synopsys HAPS Lab, 64 FPGA's operating together

You read the title correctly, this blog discusses prototyping over 700 Million ASIC gates using the Xilinx Virtex-7 2000T FPGA’s. To get to this capacity you need to utilize sixty four (64) FPGA’s. The picture above was taken in the Synopsys HAPS lab and shows part of our Super Chain testing. As noted previously, HAPS documented seamless deployable capacity is 288 Million ASIC gates, which is six HAPS-70 (four) FPGA systems chained together, a total of twenty four (24) FPGA’s. However we have customers where this is not enough. The HAPS solution is modular and scalable with base building blocks of x1, x2 and x4 FPGA systems and supported with a HAPS-Aware design tool flow.

The HAPS capabilities and software infrastructure enables the solution to scale with ease but Synopsys does not claim support for capabilities until they have been tested and validated. Once the HAPS systems are configured in the Super Chain they act as one unified massive prototyping system. Thanks to our synchronized clocking capabilities the prototyped design still utilizes the HAPS High Speed Time-Domain Pin Multiplexing, HSTDM, which enables the highest system performance. The above picture super chain models sixty four FPGA’s operating synchronously with HSTDM between all FPGA’s ensuring the highest system performance. That’s over 700 Million ASIC gates (12 million ASIC gates per FPGA)…

While HAPS can scale to these huge systems that does not mean that users of just x1, x2, x4 or x8 FPGA’s do not benefit from this testing. Testing of such large systems ensures that the communication, clock synchronization, HSTDM and other capabilities are bullet proof which benefits the smaller system usage ensuring maximum reliability and uptime when used in server farms or on the user’s desk.

Off subject, while visiting Mountain View CA I noticed that one of our creative R&D engineers had come in over the weekend and decorated their Cube space for Easter

Easter Cube decoration

Absolutely amazing don’t you think! Anyway I introduced myself to the R&D engineer and congratulated them. Apparently they do this once in a while and shared a couple of pictures of their previous cube creations.

Cube decoration Cube2 Cube3 Cube4

Crazy cool right!!! I also think that this R&D engineer might have just a little too much time on their hands. Or maybe they are just like me and maximizes every second or every day. I personally think there is a business here, cubicle decoration in a box…. Would you buy a box of decorations to jazz up your cube?

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

Posted in ASIC Verification, Debug, Early Software Development, Humor, HW/SW Integration, In-System Software Validation, Man Hours Savings, Project management, Support | No Comments »

Success Prototyping with UltraScale VU440 devices

Posted by Michael Posner on April 3rd, 2015

UltraScale based HAPS system operation in Synopsys lab

It’s been a while since Xilinx shipped the first UltraScale VU440 engineering sample devices to Synopsys so I thought it time to deliver a short update on development progress. It might be hard to see in the above but that is a picture of one of the new development HAPS systems for the UltraScale VU440 devices. I say hard to see not only as the picture quality is low but also because we have the system completely configured with intelligent interconnect as part of our stringent characterization and functional validation process.

Each module is individually tested, see picture below as an example, this is the controller module in standalone test. The controller module hosts the HAPS supervisor which controls the system and manages advanced capabilities such as the Universal Multi-Resource Bus, UMRBus for short. Once all individual modules are signed-off they are assembled and the system is validated.

New HAPS Control module in standalone test jig

So far both the Xilinx VU440 devices and the new systems are functioning well. Xilinx has posted an errata on the engineering sample VU440 devices but these issues do not preclude the devices from being useful for system development or actual usage as part of a production prototyping project. All IO’s are operational as well as the transceiver GTH links. We have been filling the devices with high speed toggle designs as part of the performance and power characterization and smaller IP designs for other test purposes so we have not compared the utilization between V7 and UltraScale devices yet. We still predict that the UltraScale VU440 devices will deliver ~26 Million ASIC gate capacity, about 2.2X increase over the V7 2000T devices.

As a teaser for future blogs, the new integrated solution is expected to deliver

  • Highest performance w/superior partitioning & new time domain pin-multiplexing schemes
  • Always available debug with deep trace storage
  • Fastest time-to-first-prototype with HAPS aware prototyping software
  • Rapid Turn-around Time from RTL to Bit file with incremental flows
  • Native integration for regression farm & remote accessibility
  • Both HW and SW tool flow is Modular & scalable to over 24 FPGA’s (Over 600 Million ASIC Gate capacity)
  • Hybrid Prototyping ready

Preserves existing HAPS investment

  • Interoperable with HAPS-70 & HAPS-DX, (mix and match HAPS V7-based systems with UltraScale systems) same form factor, I/O voltages, HT3 connectors, daughter boards, cables

In the coming months I’ll post more information on these new and unique capabilities.

HAPS Integrated solution

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

Posted in Admin and General, ASIC Verification, Bug Hunting, Daughter Boards, Debug, DWC IP Prototyping Kits, Early Software Development, FPGA-Based Prototyping, HW/SW Integration, Hybrid Prototyping, In-System Software Validation, IP Validation, Man Hours Savings, Milestones, Project management, Real Time Prototyping, System Validation, UltraScale, Use Modes | Comments Off

Automated Timing Biased Partitioning

Posted by Michael Posner on March 20th, 2015

I spent a lot of time this week talking about timing biased automated partitioning which is the ability of the ProtoCompiler partition engine to generate a partition and pin multiplexing implementation with the goal of maximizing performance of the final prototype implementation. As it’s getting close to Easter I thought it was fitting to discuss ProtoCompiler’s Multi-Hop optimization algorithm. (Easter, Easter bunny, hop, you see what I did there?)

Firstly what is a Hop you ask? In the image below you can see the ASIC design example with combinatorial logic between two register points

ASIC Design with logic clouds between register points

It’s possible during partitioning for FPGA-based prototyping that these two registers end up in different FPGA’s as seen in the image below.

Example of a single "Hop" between FPGAs on a physical prototype

This is what is known as a single hop. The design has been split up with the starting and ending register points in separate FPGA’s. However, without timing biased capabilities it’s possible that a partition is created that spans multiple FPGA’s. An example of this Multi-Hop is represented in the image below

Example of what a multi-hop is

In our example above FPGA B has basically become a feed through FPGA and while this helps a partition engine get to a partition solution it has a dramatic effect on the overall performance of a prototype platform. To explain the timing impact lets go back to our original ASIC design and review the timing between the register points

Timing delay of this logic in ASIC implementation

In our made up example the combinatorial logic has a timing impact of about 10ns. However in our FPGA partition where you have the critical path split up over multiple FPGA’s timing becomes much more significant. The reason for this is that you typically have to apply pin multiplexing between FPGA’s as you have more signals than you have physical pins (One of the three ASIC Prototyping three laws which are the grounding facts driving this blog) Now if you review the timing impact with a typical pin multiplexing scheme inserted you suddenly see the impact of a Multi-Hop

Tming impact of multi-hops and pin multiplexing

But not to worry if you are using ProtoCompiler as the partition engine is not only fast but it’s timing biased and includes a Multi-Hop optimization algorithm.

When Multi-Hop optimization is enabled ProtoCompiler partition engine will:

  • Focus on reducing the number of multi-hops, with a goal of zero
  • If multi-hops are needed to complete the partition the focus turns to reducing the path length of the multi-hop
  • Avoids pin-multiplexing on multi-hop path
  • If pin-multiplexing is needed the focus turns to using the lowest pin-multiplexing ratio on the multi-hop path
  • Selects pin-multiplexing ratio based on timing slack

Knowing that eliminating multi-hops would lead to higher prototype performance you might think that by default the partition engine should not allow any multi-hops. However multi-hops do play a vital role sometimes in enabling an automated partition solution to be found.

ProtoCompiler’s timing biased multi-hop optimization is making a huge impact on the resulting HAPS prototyping performance. Across a suite of over 40 ASIC designs ProtoCompilers timing biased optimizations improved the clock period by an average of 50ns. HUGE improvement in resulting performance. Across this suite of designs, ProtoCompiler reduced the number of nets that are included in multi-hop paths of length two or greater by up to 80%. For most designs in the suite, the number of paths of length three or greater was reduced to ZERO. Also, for most designs in the suite, the pin multiplexing ratio of the multi-hop path nets required to get feasible automated partition was reduced to one (i.e. no pin-multiplexing required). Fantastic. Not only is ProtoCompiler’s partition engine super-fast running in minutes for multi-million ASIC gate design but the out of the box results are phenomenal.

I’m out on vacation for a week (yes even I need time off once in a while) so no blog next week.

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

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

Want it all? Capacity, TTFP, Performance, Debug and More

Posted by Michael Posner on March 16th, 2015

Possibly inspired my one of my blogs, Troy Scott, wrote a new whitepaper to help dispel the myths of physical FPGA-based prototyping. TTFP = Time To First Prototype

New Whitepaper, Busting the Myths Prototyping

I highly recommend this whitepaper as unlike my blogs, which I write mostly on the fly, this whitepaper obviously had a lot of thought put into it.

That’s it for the blog this week. I was traveling in the UK last week so I am a little jet lagged. While there I picked up a little UK history

http://poppies.hrp.org.uk/

It’s a ceramic poppy from the Tower of London remembers exhibit. It’s an amazing piece of history and I feel honored to be able to buy one.

I received another honor, this time from the hotel I stayed at

Mick is Mr Bacon

Yes, I am still known as Mr Bacon. This has a little to do with the fact that I love bacon and more so because I always seem to wear a T-Shirt that says BACON on the front of it.

I also had some fun with the rental car while trying to find parking one day. Below you can see my parking spot halfway up a hillside.

Mick gets crazy with parking spots

I’m not sure if you can see it or not but the back wheel is floating in the air. Fun, fun, fun.

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

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