BLOGS & FORUMS
Breaking The Three Laws
|Breaking The Three Laws|
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
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.
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
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
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
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.
Posted in ASIC Verification, FPGA-Based Prototyping, Tips and Traps | No Comments »
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
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
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
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.
I’m not sure if you can see it or not but the back wheel is floating in the air. Fun, fun, fun.
Posted in FPGA-Based Prototyping, FPMM Methods, Humor, Milestones, Project management, Technical, Tips and Traps | No Comments »
Posted by Michael Posner on March 6th, 2015
Software driven validation is becoming very popular as it enables the same SW code you are developing for the final product to be used to verify the product under development. This has multiple benefits such as reduced verification effort from minimizing duplicated effort to create test scenarios in addition to writing the actual SW code. It also flushes out more bugs as you are running the real SW code, or close to it, to verify the design under test so inherently it’s covering much of the user space. So why is not everyone verifying designs like this?
While you can use co-simulation and run SW code against an RTL model it’s going to be slow as the RTL executes in the simulator magnitudes slower than real hardware. The benefit is that you get great RTL debug in this mode. Emulation helps as it’s magnitudes faster than simulation but what if the design requires a physical hardware driver or the design interfaces requires real world input such as from a sensor? Not to worry, this is exactly what HAPS Hybrid Prototyping was designed for.
Review the picture above. On the left hand side the customer used a Virtual Prototype of a ARM Cortex-A15 to run Linux, drivers and firmware. This Virtual Prototype is executing on Synopsys’ Virtualizer platform. On the right hand side the customer implemented their sensor and encoder subsystem on the HAPS FPGA-based prototyping platform. The physical prototype included the design under test RTL as well as physical daughter boards to enable the real CMOS sensor to be used to “feed” the design.
In the middle is the key to Hybrid Prototyping, the transactor. Transactors translate the high level transactors to real protocol based pin-toggles in the RTL. In this HAPS Hybrid Prototype the software running on Virtualizer instructs the design running on HAPS to grab an image from the CMOS sensor. This real world data is process by the DUT then transferred onto the Virtual prototype, just like it would in a real system for further processing. The output image and any artifacts of the manipulation can be viewed from this host side.
The customer was able to accelerate the verification of the DUT by weeks using Synopsys’ Hybrid Prototyping. The customer continued to use this platform extending the their early software development efforts resulting in greater quality and capabilities in preparation for the test chip. But there is more… The environment was setup is immediately re-usable for other projects and designs under test. If you look at the Virtual side you can see that this subsystem should run all sorts of software code so can be loaded for multiple scenarios across multiple design targets. On the HAPS prototype side you can see that different design under test quickly plug into the standard AMBA bus infrastructure, even larger subsystems. Hybrid Prototyping is supported across all the HAPS hardware, HAPS-70 and HAPS-DX.
There are many off-the-shelf Virtualizer Virtual Development Kits (VDK’s) to start from. In addition on the physical prototype side the complete software infrastructure and transactors come neatly packaged in ProtoCompiler so no need to try and piece together lots of different parts.
Hybrid Prototyping is highly valuable for design verification and system validation in addition to being easy to develop and deploy.
Posted in ASIC Verification, Early Software Development, HW/SW Integration, Hybrid Prototyping, In-System Software Validation, IP Validation, Real Time Prototyping, System Validation, Use Modes | No Comments »
Posted by Michael Posner on February 27th, 2015
This week a prototyping engineer challenged me that “his” customized and hand crafted pin multiplexing capability was “better” than the HAPS High Speed Time-Domain Multiplexing, HSTDM. My response, “Faster, maybe, better NO”. This blog explains why the HAPS HSTDM capability will beat out a custom coded multiplexing capability hands down every time.
First let’s list of the positives and negatives of a custom coded pin multiplexing capability
- It’s tailored to the exact design requirements
- It’s tuned for a specific set of FPGA pins and inter-FPGA connections to push performance to the limits
- It’s hand crafted meaning effort to develop
- It has to be manually inserted into the design
- It breaks if the design requirements change
- It’s tuned so will need to be customized to different FPGA pins and inter-FPGA connections
- Might be unreliable leading to mystery ghost bugs to chase down
I am sure the list of negatives is longer but I would bet that you already get the idea. While it’s possible to craft a pin-multiplexing block that eeks out every possible drip of performance the overhead of insertion, modification to different design and hardware requirements and testing makes it inferior to the HAPS HSTDM capability.
HAPS HSTDM was designed to deliver an automated, cycle accurate, highest performance, reliable, modular and scalable pin multiplexing solution for the HAPS systems. Automated insertion through ProtoCompiler ensures that the usage is as unobtrusive as possible. HAPS HSTDM is tested to run on every qualified IO pin across the HAPS-70 system. It will reliably run on any HAPS platform, we can claim this as the HAPS hardware itself is performance tested as part of the production manufacturing tests ensuring that all systems and interconnects meet the minimum required performance for HSTDM operation. It supports multiple ratios meeting the need of many different design requirements. It is very high performance using the latest differential signaling and training techniques with built in error detection. Just looking at this list it’s clear that HAPS HSTDM has many advantages over custom.
But wait, there is more…. I would challenge that using the flexible capabilities of the HAPS hardware interconnect combined with the HAPS HSTDM capabilities that the overall HAPS prototype will run at a higher system performance. I’ve talked about this capabilities a couple of times. The HAPS systems do not have any dedicated PCB traces between FPGA’s. All interconnect is done via intelligent cabling. This method enables the HAPS hardware to be customized to better match the DUT’s interconnect needs. This means you can create more interconnect density where the DUT needs it. More dense interconnect can help reduce the overall pin multiplexing ratio required resulting in higher performance system operation. Remember your prototype is only as fast as the slowest link.
This HAPS flexible interconnect combined with the HAPS HSTDM automated and deployed by ProtoCompiler is a very powerful solution and this is why I claim that it’s “better” than a hand crafted scheme.
Do you agree?
Posted in ASIC Verification, Bug Hunting, Daughter Boards, Debug, Project management, Support, Use Modes | No Comments »
Posted by Michael Posner on February 20th, 2015
Last week’s blog How many ASIC Gates does it take to fill an FPGA? definitely stirred the pot. Part Deux (two?) goes back to basics filling in some gaps and follows up with data supplied by my good friends over at Xilinx.
So first for clarification, apparently not everyone who reads my blog understands what a Xilinx Logic Cell, LC, is or what a Look Up Table, LUT, is. I was going to create a nice set of slides explaining but thanks again to Xilinx, here is one they prepared earlier. It should be noted that Xilinx provided me with written permission to re-use these as part of my blog. The full (PUBLIC) Xilinx presentation can be found here: http://www.xilinx.com/training/downloads/what-is-the-difference-between-an-fpga-and-an-asic.pptx
The Xilinx Logic Cell basics, a cell including combinatorial logic, arithmetic logic and a register. Your RTL source code is “mapped” into these Logic Cells.
A Logic Cell is the basic building block within the Xilinx devices and there is a *lot* of these per device, 4.4 Million in the new Xilinx Virtex UltraScale VU440. Yes that’s right, they are very, very, very small.
Part of the Logic Cell is a Look Up Table which is used to implement combinatorial logic.
My contact over at Xilinx also provided me the Xilinx used standard calculation of equivalent ASIC gates of the Xilinx devices.
–//– From Xilinx
Here are the basic principles that we’ve tried to stick to when generating ASIC gate count numbers:
- – 6 to 24 gates per LUT (depending on the number of inputs used)
- – RAM bits are equivalent
- – Up to 100 ASIC gates per I/O;
- – 7 gates per register
So for the VU440 here’s how this shakes down:
- Minimum 6 x 2,532,960 LUTs = 15,197,760
- Maximum 24 x 2,532,960 LUTs = 60, 791, 040 ASIC gates
IOs : 100 x 1456 = 145600 ASIC gates
Registers : 7 x 5.065,920 = 35,461,440 ASIC gates
So by this math we could have claimed anywhere from 50,804,800 to 96,398,080 ASIC gate equivalent in the VU440.
–//– End From Xilinx
So great, this passes what I call the basic “Stupid” test, as in there is sound logic and defendable data behind the calculation. It also highlights the large variance in “gate counts” which is significantly influenced by the number of inputs used as part of the look up table calculation. It’s exactly as I stated in last week’s blog, the conversion from ASIC gates to FPGA ASIC gate equivalent is design specific. Some designs will map well, some not so much.
In the material that Xilinx supplied I also spotted this slide which reinforces this point.
Specifically for Prototypers, the conclusion is very important. The Prototypers goal is to NOT modify the golden RTL source for prototyping otherwise you will not be validating a true representation of the design. Yes, some modifications are needed such as RAM’s, gated clock conversion but these can be verified as identical and are an acceptable trade-off. Outside of this the RTL is not customized for FPGA meaning that many of the dedicated resources cannot be directly mapped to. This leads to inefficient mapping of the RTL code to FPGA and is why a “fudge” factor is required in the ASIC gate equivalent calculations. The restriction is typically the Look Up Tables for combinatorial logic mapping, you run out of those before anything else. (not all the time but most of the time). By being conservative in the ASIC gate count capacity claims the vendor can ensure that expectations are met for a majority of designs
Posted in ASIC Verification, FPGA-Based Prototyping, Man Hours Savings, Milestones, Use Modes | No Comments »
Posted by Michael Posner on February 13th, 2015
How many ASIC Gates does it take to fill an FPGA?
This question almost sounds like a joke doesn’t it. In reality this is a question I am asked to answer all the time and it’s not easy as ASIC designs don’t map the same to FPGA as they do to ASIC process technologies. In the ASIC design flow ASIC gates are represented as two input NAND gate equivalent and this is the base date point which should be used in the calculation as to how the design will map to FPGA.
For multiple generations of HAPS systems Synopsys has used the following tried, true and field proven calculation as to ASIC gate equivalent capacity of the Xilinx FPGA families.
The basis of the calculation is that you can map the equivalent of six two input NAND gates per Look Up Table, LUT per Logic Cell, LC.
1* LUT = 6 Two input NAND Gate equivalent (go try it!)
With this knowledge its easy to calculate the total capacity of the FPGA in ASIC NAND Gate equivalent as you then multiply the LC count per FPGA by 6.
The Xilinx Virtex-5 series biggest capacity device was listed as 330K LC’s, so 330K times 6 = 1,980,000 two input ASIC NAND gate equivalents (~2 million)
So for the other Xilinx large devices used for Prototyping you get the following.
- Xilinx Virtex-6 = 760K LC’s = 4,560,000 two input ASIC NAND gate equivalents, (~4.5 million)
- Xilinx Virtex-7 = 2000K LC’s = 12,000,000 two input ASIC NAND gate equivalents, (~12 million)
- Xilinx UltraScale = 4400K LC’s = 26,400,000 two input ASIC NAND gate equivalents (~26.4 million)
Synopsys has shipped over 5000 HAPS units across 400 customers and with 1000’s of designs being validated using HAPS we are confident with this method to correctly set the expectations as to how many FPGA’s are needed to model the design under test. Of course you can only use this as a guideline as we all know ASIC RTL is typically FPGA hostile so you rarely get optimized mapping. Your ASIC RTL source code contains non-FPGA type resources, mux’s, adders, subtractors which don’t map nicely to FPGA resources and you have designs with intensive datapath and heavy interconnect stressing FPGA routing resources. The Synopsys defined estimation calculation has helped 100’s of customers quickly estimate the number of FPGA’s they need for their projects.
The only true way of more accurately estimating the number of FPGA’s your SoC prototype will need is by executing FPGA area estimation within a prototyping tool such as ProtoCompiler. Even running your design through the FPGA vendor tools will help you get an idea of the number of FPGA’s needed.
Simple right…… If only……. There is no standardization in the FPGA-based prototyping commercial market or across FPGA vendors so the poor prototyper is faced with multiple capacity claims for the same FPGA device!!!! A simple web search will quickly confirm this, other vendors ASIC gate equivalent capacity claims can be very different from the Synopsys calculation. This has led to some quite funny (now that I look back on it) conversations with customer. One such conversation is summarized by the quote
I have to buy two HAPS-70 systems to get the same capacity of the <other vendors> one board
I did actually laugh out loud… The hardware has the same FPGA’s !!!!!! Your SoC design does not magically shrink to fit into less FPGA’s. If your tool run estimations shows that you need four FPGA’s that’s what you need, forget the vendors claimed capacity per FPGA. Don’t be fooled by wild capacity claims, do your own area estimation based on your SoC prototyping project.
It should be noted that the software tool flow used to support your prototyping effort can make a difference in the FPGA utilization. For example ProtoCompiler has a Time to First Prototype, TTFP mode which is designed to get you onto hardware fast and as part of this can be configured to use more available FPGA capacity to reduce synthesis and P&R times. ProtoCompiler also has a performance and area optimization mode where the tool will use unique techniques to pack more logic into each FPGA. This TTFP mode is typically used at the start of a project, optimized mode when you deploy HAPS in volume to software developers.
Of course, prototypers, one way for you to neutralize the vendor capacity claims is just to compare the number of FPGAs, apples to apples.
One final point, the way Xilinx “counts” gates and markets seems to be a much more sophisticated calculation which I *think* includes much more than the raw LUT NAND gate equivalent. I reached out to my Xilinx contacts and asked them to clarify, I’ll post a blog on the results if they give me permission to. (Hey maybe I can twist their arms and get them to guest blog!!!) I think their calc includes memory, hardened IP blocks and other logic but I’m just speculating.
Do you count FPGA capacity in another way? If yes drop me a note or comment and share.
Click the links to the left and below to subscribe and get blog updates as soon as I post them
Posted in Man Hours Savings, Milestones, Project management | 2 Comments »
Posted by Michael Posner on February 6th, 2015
I traveled from Oregon to California this week and visited the new Synopsys offices aka “The 690!” all I can say is wow, I want one. The Synopsys offices in Hillsboro Oregon are nice but we don’t have the new technology that the Synopsys CA offices got. Gym, cafeteria, bright nice cubes/office and Champagne on tap….. Of course one of these is a lie, can you guess which? Yes that’s right, no cube space can ever be nice. There is a HUGE hardware lab and I was able to wing it and get someone to flash me in, apparently I’m not on the authorized entry list “yet”. There are many HAPS stations for development and regression testing, one of the stations that caught my eye is pictured below
This pictures one of the development & regression stations for HAPS Multi-FPGA Deep Trace Debug. This is the HAPS debug simulator like experience, debugging at the RTL source code with an almost seamless flow for your HAPS-based multi-FPGA prototype and external deep trace capture. I’ve blogged about this before a number of times, the last time in my “Top 3 Myths of FPGA-based prototyping BUSTED” blog which blew apart the stagnate mindset that you only get very, very limited debug visibility in FPGA-based prototypes. We have a nice video about this and other debug capabilities integrated into HAPS: http://www.synopsys.com/prototyping/fpgabasedprototyping/pages/troubleshoot-debug.aspx
If we look at the recent survey data that Synopsys commissioned
You see that debug is rated almost equally challenging to multi-FPGA partitioning, ASIC clock conversion and a hair above performance. Synopsys has been focusing on addressing these debug challenges.
Prototype debug visibility is like the tree with roots picture I posted above. The top of the tree is your ASIC/SoC and the roots are the network of debug visibility points. You don’t need to look at everything to successfully debug. Hold it right there you say, we want 100% visibility….. This is a common request as it’s what you get in an RTL simulator or emulator, but remember, in comparison to even the fastest simulator (VCS), or emulator (ZeBu), HAPS FPGA-based prototyping is magnitudes faster. The problem is that there is that thing called Physics which gets in the way. As you add real hardware logic for debug instrumentation you start having to trade off available FPGA capacity for the actual design with the debug logic. Yes you can do this but the result is that you need many, many more FPGA’s to support the design size plus the debug logic and this could become cost prohibited.
To manage this you need to make smarter choices on debug points. This is exactly what we do in the DesignWare IP Prototyping Kits, these are pre-instrumented with a set of debug points which aid debug of the design and interface once the IP integrated. RTL developers should be doing the same for your code, identifying critical debug points early in the design cycle and carrying those through to the prototype.
But what if your RTL developers throw the code over the wall with no debug points identified? In this scenario the Verdi and Siloti tools help. The Verdi/Siloti tools are used to derive a minimum set of “essential” signals to be recorded. This essential signal database is then used to generate the instrumentation list within the prototype. HAPS with ProtoCompiler supports this in an automated flow. The visibility automation technology in the Siloti system combines visibility analysis techniques and a data expansion engine to reduce the impact of observation on the prototype maintaining performance and significantly reducing the instrumentation capacity overhead.
The end result, less overhead, more root like debug, but still high debug visibility.
This is just one type of FPGA-based prototype debug and HAPS has multiple others depending on what you are debugging.
Traditional FPGA debug utilizing the FPGA embedded memories still play an essential part in the debug methodology. While the depth of storage is narrow when using FPGA resources, the capture performance is high, typically at the same speed the internal logic is running. This can be helpful when debugging high speed logic and interfaces. HAPS Real Time Debug, the process to connect internal FPGA signals to external FPGA IO’s and capture with a logic analyzer is also essential. One such example is when you want to debug the interface from the FPGA to the DDR memory. The HAPS debug interposer card can be placed between the HT3 connectors and the DDR3 daughter board enabling the signals to be traced with almost unlimited storage on a logic analyzer. The use and setup of HAPS Real Time Debug is automated through the ProtoCompiler flow, you don’t even need to modify your source code as passive Cross Module References, XMR’s, are used to “hook up” the signals. Multiplexed sets enables multiple debug groups to be created and then selected at runtime reducing the need to go back and add additional debug. Compression and smart tracing is used to more efficiently store debug data for expansion off-hardware. And of course the HAPS deep trace debug, the ability to trace 1000’s of signals and store the data off-FPGA. This has the added advantage of reducing the debug logic overhead.
How do you debug your design in FPGA-based prototype? Drop me a comment and let me know. I would love to hear about other debug methods such as bus monitors which are implemented into the prototype. I have seen the HAPS UMRBus capabilities used for built-in protocol monitors, I will blog details about those in the future.
Posted in ASIC Verification, Bug Hunting, Debug, Man Hours Savings | Comments Off
Posted by Michael Posner on January 30th, 2015
I was forwarded this user quote and I thought I would share as it was so heartwarming for me
The design came up on HAPS in less than two weeks and we found a rather serious bug early in testing. This is the bug that would have cost the company dearly if it wasn’t found until later in the development cycle.
It’s short and sweet and communicates the HUGE value that FPGA-Based Prototyping delivers. This note reminded me that a while back I did an internal analysis of the value of HAPS FPGA-based prototyping in respect to the various use modes. The use modes I examined was Functional Verification, HW/SW Integration, Firmware Development, System Validation and Software Development. First I created a baseline score for HAPS in respect to various user requirements. This list stays consistent across all use modes.
- Early Availability
- Initial Design Setup
- Iteration Turnaround Time
- Execution Speed
- Deployment (Ease of/Cost of)
- HW Debug Visibility
- SW Debug Visibility
How the scoring works, 1 = Sub-Optimal, 10 = Excels. To score I created a set of definitions per requirement and using real data which compared the results to other technologies thus to objectively score. The scores are mapped into a radar chart. Here is the scoring baseline for HAPS. I should point out that its subjective but I tried to be as data driven as possible. If anything I might have been a little harsh on HAPS to be fair.
At the same time and using the same list of requirements I scored the NEEDS of the use mode. For example the user needs for software development are pictured here. Note the dotted line.
The baseline needs were mapped for each of the desired use mode. Then it’s a simple case of overlaying the results of the baseline value score of HAPS against the use mode. It’s a multiplication of the value times the need. This way it clearly shows where there is synergy of a need and as strength.
Starting with Functional Verification
Remember the dotted line represents the user needs within the use mode of functional verification and the solid line represents the relative strengths of HAPS. Within a radar chart it’s easy to see the matching requirements and HAPS strengths. It’s clear to see that while HAPS does bring value to functional verification it’s definitely not the best technology for the use case. Hey, we all knew this already. A simulator such as VCS or emulator such as ZeBu is a far better choice for functional verification as they deliver on the key needs of the use case such as early availability, debug visibility, capacity etc. But I also know that HAPS is used in this use mode as the performance enables a huge amount of tests to be run in a short amount of time flushing out those hard to find RTL bugs.
Now lets review the HW/SW Integration use mode
Immediately it’s clear that the value of HAPS FPGA-based prototyping is far better matched to the requirements for HW/SW Integration. HW/SW Integration is typically the point at which FPGA-based prototyping is deployed in development. As more and more RTL blocks are coming together and the volume of software has become significant then the additional performance that HAPS FPGA-based prototyping delivers is needed to execute in a reasonable timeframe.
Now onto Firmware Development
FPGA-based prototyping enables the use of real physical interfaces using the real interface blocks such as DesignWare IP. This means that the hardware aware firmware development is a key use case for HAPS FPGA-Based prototyping and this is represented in how well the values match the use case needs. The real physical IO, actual RTL blocks combined with the high performance operation make HAPS FPGA-based prototypes one of the best firmware development platforms next to the real silicon. Actually I would be bold enough to say better than the real silicon as once you have silicon its too late to fix RTL bugs!
For the same reasons as firmware development it’s clear to see that HAPS FPGA-Based prototyping is the best technology to address the needs of System Validation use mode. In System validation you will be running lots of software against the hardware, doing interoperability and compliance testing against real hardware. No other technology enables you to do this, PRE-SILICON
Finally the software development use mode
This is the traditional and most well know use mode for FPGA-based prototyping. Again the HAPS values map very well against the needs and requirements of Software Development. Really the only area in question is capacity. I thought it would be interesting to add the benefits of Hybrid Prototyping into the scoring for this particular use model.
Hybrid Prototyping, the combination of HAPS FPGA-based and Virtualizer Virtual Prototyping makes for a powerful platform for software development. Hybrid Prototyping combines the accuracy, performance and real world IO of HAPS with the capacity and differentiated debug capabilities of Virtualizer. I can tell you that a number of customers have adopted Hybrid Prototyping to improve their early software development activities. A number of these have been able to accelerate their software development and validation to a point where the software run on the real silicon on day one! Hey bonus, the green radar chart line looks like a fish, do you see it?
Anyway, there you go, the value of HAPS across multiple use modes. Is this consistent with your scoring of FPGA-based prototyping in respect to your project usage?
Posted in ASIC Verification, FPGA-Based Prototyping, HW/SW Integration, Hybrid Prototyping, In-System Software Validation, IP Validation, Milestones, Project management, Real Time Prototyping, System Validation, Use Modes | 2 Comments »
Posted by Michael Posner on January 25th, 2015
Last week I spent a week in Japan visiting users to discuss their FPGA-based prototyping challenges and explain how Synopsys can help. My overall take-away of the visits was that many companies want to expand their current single FPGA-based prototyping to multi-FPGA but fear the challenges associated with this. The summary of what I explained was pretty simple but to the point. #1 Having a defined methodology, flow and tool set is key. #2 Yes Multi-FPGA is more complex but it’s not as steep of a learning curve as you may think. And that’s it…..
#1 Having a defined methodology, flow and tool set is key
In respect to methodology you of course can refer to the FPGA-based Prototyping Methodology Manual, FPMM. (English and Japanese versions, 英語版と日本語版) I used Google translate so I hope I didn’t just offend the whole of Japan. Read the FPMM and you will become an expert prototyper but we all know that in this age of technology a summary is always nice. This is why I blogged about 3 Phase Approach to Successful Prototyping a while back. Yes, this is the blog with the upside down pyramid which at the time I thought was a great way to show the progression down through a funnel. The three phases are “Make Design FPGA Ready”, this is all about making the ASIC RTL FPGA friendly. “Bring Up Functional Prototype”, this is where you want to get onto the hardware as quickly as possible so you can functionally validate the design. Finally “Optimize Prototyping Performance”, pretty self-explanatory really.
Along with a defined methodology you need to utilize a tool flow which is designed for prototyping. I was amazed in Japan that many companies still tried to use the FPGA vendor tools for prototyping. I have nothing against FPGA vendor tools, they are great for their job which is FPGA synthesis. When I asked about the challenges these customer faced it was the same story I have heard before, ASIC clock conversion, gated clocks, memories and for the few that did multi-FPGA the key challenge was clock/reset synchronization and pin multiplexing. If you want to go fast on the freeway you don’t buy a bicycle you buy a car, it’s the same with prototyping. If you want to prototype buy a tool set which is designed for the purpose. I blogged about ASIC Gated clock conversion a while back, Unlocking the Secrets of ASIC Clock Conversion, which is just one example of a tool set designed for prototyping. Search my blog and you will find a stack more examples of what is possible by the tools these days. You need a tool set which is more than just a FPGA synthesis tool, you need a tool set that understands your challenges and can help with automation and dedicated capabilities.
#2 Yes Multi-FPGA is more complex but it’s not as steep of a learning curve as you may think.
If you have never prototyped before I’m not going to tell you to start doing multi-FPGA prototyping straight away, too many variables to take on at once. Start small, create a single FPGA-based prototype of a subsystem of your design. Don’t fall into the trap of thinking you can get away with using the FPGA vendor tools (see above) use a dedicated FPGA-based prototyping tool. This is exactly why we provide ProtoCompiler DX as part of the HAPS-DX system. ProtoCompiler DX is everything you need to implement the prototype and more as it includes high visibility debug capabilities. Once you have a prototype up and running on a single FPGA, then it’s time to expand, but don’t bite off more than you can chew, again start small. My suggestion is that you do not add anything new to the design you already have operational. Simply select a block or two from the existing design and move them into a 2nd FPGA. Using your multi-FPGA prototype tool, such as ProtoCompiler, get familiar with partitioning and pin multiplex IP insertion. Get familiar with customizing the hardware to match the needs of your design. Abstract Partition Flow Advantage, this is an important step to ensure that you create the highest performance multi-FPGA prototype. Once you have the same design up and running on two FPGA’s and a design flow and expertise in place you are ready for greater things. Go off and be successful in multi-FPGA prototyping.
The weather was pretty nice in Japan, here is the view from the hotel I was staying at:
We had lots of nice meals out, can you guess what was served at this restaurant?
We did a day trip to Shin-Osaka via the bullet train, Shinkansen, what a mean looking train
Nice view of Mount Fuji on the way up
While the Japanese can build a train that goes 200 MPH they have the same problem as the rest of the world, horrible coffee. Luckily when we arrived the local team treated me to vending machine coffee
Of course many may question my judgment for even trying train coffee and vending machine coffee. You have to remember I was jet lagged and this was better than no coffee….. but only marginally.
I met the star of the film, Big Hero6, Bay Max, well at least his inflatable body double
The funny thing is that Bay Max the real character is also inflatable so what this really a body double or his clone?
Posted in FPGA-Based Prototyping, FPMM Methods, Getting Started, Technical, Tips and Traps, Use Modes | Comments Off
Posted by Michael Posner on January 16th, 2015
In late 2013 I blogged about the newly announced Xilinx UltraScale devices, the VU440 specifically that will be the largest FPGA device on the market: http://blogs.synopsys.com/breakingthethreelaws/2013/12/xilinx-fpga%E2%80%99s-for-fpga-based-prototyping/
Well this week Xilinx officially announced that they have shipped the first samples of the VU440 devices: http://press.xilinx.com/2015-01-15-Xilinx-Delivers-the-Industrys-First-4M-Logic-Cell-Device-Offering-50M-Equivalent-ASIC-Gates-and-4X-More-Capacity-than-Competitive-Alternatives
And check out who received the first of these samples…………………………… ok, you don’t need to read it, Synopsys did…….. We have optimized every generation of our HAPS prototyping systems for the highest system performance, greatest capacity while adding significant capabilities on top delivering prototyping specific features. We all know the FPGA device is a required component within the FPGA-based prototyping hardware but it’s not what defines or makes the solution useful. Anyone can slap an FPGA on a board but this does not help a prototyper as the device alone does not deliver the capabilities they require. Prototypers rely on a solution which includes a software implementation tool flow, integration between hardware and software accelerating time to operation, built in capabilities such as high speed pin multiplexing and high visibility debug to ease bug hunting while being modular and scalable. (side note: Synopsys offers exactly this…. just in case you didn’t know)
I recommend you also check out the VU440 demo video. It stars my friend Kirk from Xilinx who introduces the new device and the demo running ten ARM Cortex-A9 CPU’s, pretty impressive. http://www.xilinx.com/products/silicon-devices/fpga/virtex-ultrascale.html#uniquePlayer1
Over the coming weeks I’m going to focus my blogs on the capabilities that the new Xilinx UltraScale devices deliver and the impact they have to prototypers. As noted above, an FPGA alone does not deliver FPGA-based prototyping so I will discuss how the device capabilities are expected to be integrated and leveraged delivering a solution.
Oh, and just because Synopsys has received Xilinx sample devices don’t expect a new HAPS next week. Delivering a solution requires hardware development, software development and a huge amount of validation. But I’m confident that when you are ready to adopt, Synopsys will be ready to deliver…..
Posted in Admin and General, ASIC Verification, Bug Hunting, Debug, Early Software Development, FPGA-Based Prototyping, HW/SW Integration, In-System Software Validation, Man Hours Savings, Milestones, Technical, Tips and Traps | Comments Off
| © 2015 Synopsys, Inc. All Rights Reserved.