BLOGS & FORUMS
Breaking The Three Laws
|Breaking The Three Laws|
Archive for the 'FPGA-Based Prototyping' Category
Posted by Michael Posner on 20th February 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 30th January 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 25th January 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 | No Comments »
Posted by Michael Posner on 16th January 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
Posted by Michael Posner on 10th January 2015
Let me be the last to wish you “Happy New Year” and all that….
Of course it was the Consumer Electronics Show, CES recently and no good blogger would let this opportunity pass without writing something about it. Regardless of this I’m still going to write something. (If you got that joke comment below)
Hot at CES was self-drive cars with Advanced Driver Assistance Systems (ADAS), Sling TV, SuperHD TV’s, robots and of course wearables and the Internet of Things, IoT, because everyone wants a cooker with built in internet browser (well I do but as I already have a full PC in the kitchen for streaming TV and web browsing I will hold off on buying a cooker with similar capabilities)
It was nice to see that a number of projects that I know have been prototyped were being debuted at CES. It’s very fulfilling seeing a product go from idea to reality. While the big buzz was around everything you could see it’s the things you could not see which I want to discuss this week. These little electronic gadgets power the world of self-drive cars, wearables and IoT…. Yes I’m talking about sensors!!!!!
Lets face it, the sensors themselves don’t make the product but without them the device would not be able to operate so they really are the little product hero’s. Managing and data acquisition from these sensors can be a complex project in itself which is why Synopsys made it easier with the DesignWare Sensor and Control Subsystem.
This nifty subsystem is optimized to process data from digital and analog sensors, offloading the host processor and enabling more power efficient processing of the sensor data. The DesignWare Sensor and Control IP Subsystem provides designers with a complete, pre-verified solution that optimizes sensor fusion and actuator/motor control functions increasingly prevalent in automotive, mobile, industrial and IoT markets.
If you look at the block diagram above you can see that the interface to these sensors is usually pretty simple, UART, DAC/ADC, SPI, I2C and basic GPIO with the most complex interface being AMBA APB. I worked with a user recently who wanted to incorporate sensor information directly into their FPGA-based Prototype. The solution we came up with was to utilize off-the-shelf Peripheral Module interface, PMOD, boards. PMOD is a standard defined by Digilent Inc : http://en.wikipedia.org/wiki/Pmod_Interface
Diligent have a wide range of these little modules: http://www.digilentinc.com/Products/Catalog.cfm?NavPath=2,401&Cat=9 covering various applications.
Note that the PMOD’s are typically a standard 6-Pin interface with 4 signals, one ground and one power pin so very low pin count. The user connected these to the new HAPS GPIO board, pictured below, in order to interface the modules into their custom design modeled within HAPS.
Note that the HAPS GPIO board is a vertical mounted board so just like the PMOD’s themselves do not take up much physical real estate.
We ended up making full use of the HAPS GPIO board with multiple PMODs connected, interface to the ARM debugger, LED’s to signal various operational states and push switches to simulate user input. The GPIO board is very versatile with 3 standard 3.3V HAPS 10-pin GPIO headers, (Compatible with HAPS BIO1), 2 high-speed VCCO level GPIO headers (Red), 20-pin ARM JTAG header, Micro-USB for UART, MMCX clock connectors, 5V TTL header for serial LCD display, Level shifted header for I2C and SPI, 6 buttons and 4 LEDs on mini-daughter board which is connected to 3.3V HAPS 10-pin GPIO header when needed.
Unfortunately I was sick during the break so I didn’t get to as many of my little projects as I would have liked. I did however manage to complete one of them that I had been excited about for a while now. I made myself a portable gaming station complete with 412 games from the 1980-1990 era.
The whole setup packs away in a study roller case (which I got used which is why it’s so beat up). Open it up and pull the control station to the top of the box, plug it in and you are off. Favorite games like Pacman, Space Invaders, 1945, Donkey Kong and many, many more. I can now waste away many hours into the wee night playing mindless video games.
Posted in Daughter Boards, DWC IP Prototyping Kits, FPGA-Based Prototyping, Getting Started, Humor, Mick's Projects | Comments Off
Posted by Michael Posner on 13th December 2014
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.
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.
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.
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.
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.
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.
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?
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.
Posted in ASIC Verification, FPGA-Based Prototyping, Man Hours Savings, Technical, Tips and Traps | 2 Comments »
Posted by Michael Posner on 14th November 2014
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.
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
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.
Posted in FPGA-Based Prototyping, FPMM Methods, Getting Started, IP Validation, Technical, Tips and Traps | 1 Comment »
Posted by Michael Posner on 30th October 2014
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.
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.
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.
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.
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!
That’s some crazy eyes I’ve got going on…………….
Posted in FPGA-Based Prototyping, FPMM Methods, Getting Started, Technical, Tips and Traps | Comments Off
Posted by Michael Posner on 2nd May 2014
This week I was asked to clarify what the PCIe Gen3 protocol speed is, to confirm, PCIe Gen3 speed is 8Gb/s per lane. PCIe Gen 1 is 2.5Gb/s and PCIe Gen2 is 5Gb/s. Yes I know I’m usually seen as the prototyping guy, (Or Mick “I’m not dead yet” Posner thanks to my pneumonia) but I also happen to double up as a protocol expert. One of the key advantages of FPGA-Based prototyping is the ability to model real world interfaces at speed so to be a prototyping expert you basically have to be a protocol expert as well. The above eye diagram (click image to view full size) is measured on the HAPS-70 (-2) speed grade systems running one of the many DesignWare PCIe Gen3 controller validation tests for interoperability and compliance testing. That is a good looking wide open eye!
I sneaked into the lab and snapped off this picture. (Click on image to view full size)
The little HAPS-70 S12 (-2) speed grade system is perched on top and that large black cable sticking out is the PCIe Gen3 capable cable connection. The cable plugs into a PCIe Gen3 host adapter board that in turn plugs into the host machine. In this specific setup I was told that we have the DesignWare PCIe Gen3 End Point controller modeled in a x4 lane configuration. Yes that’s x4 lanes of PCIe Gen3 so x4 lanes of 8Gb/s. I’m going to try and have the R&D engineer do a little video for me of the system in action as it was very impressive.
Oh, when using the Xilinx built in transceivers (Rocket IO) as the physical link the (-2) speed grade systems are required to model PCIe Gen3. The (-1) Xilinx Virtex-7 2000T devices only support up to 6.6 Gb/s while the (-2) support up to 10.3125 Gb/s thus supporting PCIe Gen3 speeds. Looking for PCIe Gen3 expert advice, go check out the Express Yourself blog
Off topic, spring has sprung in Oregon !! Yay, it was here for a whole 4 days and now we are expecting rain again. This is fine, this is what you expect and grow to love when living in Oregon. The mix of sun and rain makes everything really green, just look at how beautiful this little baby fern is. This is growing in my yard along with a huge amount of moss which is also typical across Oregon.
Click on image to view full size
Posted in ASIC Verification, FPGA-Based Prototyping, IP Validation, System Validation, Technical, Use Modes | Comments Off
Posted by Michael Posner on 28th April 2014
Synopsys just announced ProtoCompiler which is automation and debug software for HAPS FPGA-Based Prototyping Systems. ProtoCompiler is the result of years of R&D effort to generate a tool that addresses prototypers challenges today and built on top of an architecture which can support the needs of prototypers long into the future. ProtoCompiler focuses on the needs of prototypers specifically addressing the need for accelerated bring up as well as providing capabilities which result in higher system performance as compared to existing solutions. In this blog I’ll discuss some of the technical details behind the main tool highlights. Below are the detailed highlihts.
Integrated HAPS hardware and ProtoCompiler software accelerate time to prototype bring-up and improves prototype performance
Automated partitioning across multiple FPGAs decreases runtime from hours to minutes for up to 250 million ASIC gate designs
Enables efficient implementation of proprietary pin multiplexing for 2x faster prototype performance
Captures seconds of trace data with gigabytes of storage capacity for superior debug visibility
(Read to the end of the blog if you also want an update on Mick’s Projects)
Highlight: Integrated HAPS hardware and ProtoCompiler software accelerate time to first prototype bring-up and improves prototype performance
As noted above the goal of ProtoCompiler is to accelerate the bring up of a prototype as well as providing a path to the fastest possible operating performance. ProtoCompiler is unique as it combines hardware/software expertise with intimate knowledge to deliver superior results. Think of it as delivering a HAPS hardware expert packaged up into a format that anyone using the tool can access. ProtoCompiler has deep technical knowledge of the HAPS hardware including configuration, clocking structures, interconnect architecture, pin multiplexing expertise and more. ProtoCompiler is not only a hardware expert, it’s also a software expert. ProtoCompiler is built on top of a state of the art Synopsys proprietary prototyping database that means RTL is effectively processed and incremental and multi-processing techniques can be deployed with ease.
All this results in blazingly fast processing speeds. As an example ProtoCompiler’s area estimation, essential for automated partitioning, can processed 36 Million ASIC gates in less than 4 hours as compared to 22 hours in existing solutions. Now that’s fast!. Thanks to the new data model and incremental modes all subsequent compiles are even quicker.
Highlight: Automated partitioning across multiple FPGAs decreases runtime from hours to minutes for up to 250 million ASIC gate designs
So there are actually two announcements packaged up in this highlight. Starting in reverse ProtoCompiler supports 250 Million ASIC gate and larger designs. Humm, this sounds a little suspect as when HAPS-70 was launched it only supported 144 Million ASIC gates, what does ProtoCompiler know that we don’t? Luckily I know, HAPS-70 can now be scaled to support 288 Million ASIC gates, 2x the capacity. HAPS-70 now supports chaining of any six systems so if you chain six HAPS-70 S48’s you get a total of 288 Million ASIC gates supported which is 24 Xilinx Virtex-7 2000T FPGA’s. All working in one synchronous system.
Any 3 HAPS systems can be chained via our standard control and data exchange cabling, when you go above 3 systems you utilize a synchronization module that manages the system synchronization. Managing clock skew, reset distribution and configuration is all handled automatically. ProtoCompiler understands the hardware capabilities thus making deployment of such a system a snap. No longer do your engineers have to worry about how to distribute clocking, we have done the hard work so you don’t have to. Other vendors “claim” scalability and modularity but if all they are delivering is boards then it’s nothing more than a wild claim. To deploy a scalable and modular system you need a complete solution of software and hardware. You can now prototype SoC designs you thought never possible
The first part of the highlight introduces the new partition technology deployed in ProtoCompiler. ASIC’s are bigger than a single FPGA so you need to quickly partition the design across multiple FPGA’s. Historically this has been a challenge but with ProtoCompiler that challenge has been overcome. The partition engine in ProtoCompiler requires minimal setup before you can apply it to your design. There are four simple steps to setup the partition engine #1 Create target system, basically which system(s) you are compiling to. #2 Establish basic constraints which are things like blocks of IO. #3 Define the design clocks. #4 Propose an interconnect structure. Actually #4 can either be defined telling the partition engine to use a set interconnect architecture or leave it open and let the tool do it. There are advantages of both. By letting the tool pick the needed architecture the resulting system should be higher performance as ProtoCompiler will maximize interconnect to reduce pin multiplexing ratio. In a previously deployed system you may have already set the interconnect and then want the tool to use the available resources so you don’t make any changes to the hardware in the field. ProtoCompiler has the flexibility to do both meeting the needs of new prototype creation and image re-spin after a new RTL code drop.
ProtoCompiler partition engine is FAST, using the same example as above, 36 Million ASIC gates, ProtoCompiler was able to come to an automated solution is 4 minutes!!! WOW. ProtoCompiler provides a huge amount of information as to what it automatically did so that the engineer can quickly review the results and maybe provide ProtoCompiler more guidance to optimize the partition. For example after the first run you might want to lock down select parts of the design and then incrementally run the engine to push it to find a better solution for the rest of the design. As it runs so fast you can do multiple of these optimization iterations in a matter of hours. I’ve played with the tool as I was interested in this particular capability and have to say it’s amazing. I’ve tried the open method and let the tool find a solution for itself, in this mode ProtoCompiler pretty much finds a solution every time. I also played with challenging the tool for example locking the tool to use only 100 IO’s (two HT3 connectors) between FPGA’s. ProtoCompiler quickly finishes and told me that I was crazy and that the design could never be partitioned with my selected interconnect architecture.
Highlight: Enables efficient implementation of proprietary pin multiplexing for 2x faster prototype performance
OK, this is simple, this basically says that ProtoCompiler can automatically deploy the HAPS High Speed Time-Domain Multiplexing (HSTDM). HSTDM is developed and optimized on HAPS and ProtoCompiler packages up this expertize and automated the deployment. The partition engine will automatically select HSTDM and instance it into the prototype design. HSTDM delivers high performance pin multiplexing between multiple FPGA’s. The signals are packaged up, sent across a high performance link and unpacked at the other side. This all happens within one system clock and is completely transparent to the user. No manual intervention, no additional latency, and it’s stable and reliable as HSTDM is tested as part f the HAPS production testing and every system has to pass the minimum HSTDM performance tests. This ensures that when you deploy am image with HSTDM that it runs on every system the image is loaded on. No need to tailor the pin multiplexing implementation for each board like you have to do with other vendors.
Highlight: Captures seconds of trace data with gigabytes of storage capacity for superior debug visibility
ProtoCompiler expands the debug capabilities and grows the HAPS Deep Trace Debug capability which utilizes off-FPGA memory to store debug data. ProtoCompiler provides seamless multi-FPGA debug capabilities on top of a set of other debug capabilities tailored to delivering visibility at the right level of the debug cycle.
In debug one size does not fit all, you need to deploy the right level of debug visibility capability dependent on what you are trying to debug and the specific point you are in the project cycle. Sometimes you want very wide debug visibility with fast incremental turn-around. Later in the design cycle you typically want very, very deep debug windows. ProtoCompiler delivers both, fully automated through the flow, seamless and transparent to the users. And when I say deep, I mean deep, the example below is very typical of the debug window where you can easily capture seconds of debug data.
As usual my blogs got really long. I wrote it in the car while driving from Portland to Eugene. Amazing that I could type all of this and drive at the same time (LOL, only joking I was in the passenger seat)
Anyway, ProtoCompiler is the bees knees and I personally think it revolutionizes FPGA-based prototyping using HAPS. What do you think of ProtoCompiler?
If you have managed to get this far into my blog then congratulations. I’ve been taking it easy this week while I recover from the pneumonia that I came down with. In the evenings I finished off the two mini RC tracked vehicles I had been working on. The basis of both are simple kits which I then modified and added RC receivers and motor controllers to. While I am a grown adult I must admit they are fun to play with. The first is a basic platform RC tracked vehicle which I attached a Lego sheet to. Little did I know that this would be so popular with my son. He has been building towers and all types of structures on top of it.
Why drive your car to a car park when the car park can come to you. No joke that’s what my son said.
Mobile tire store
Bulldozer and sweeper
At the same time I also built a kit that has a shovel that moves on the front. Again I modified it to be radio controlled, including the shovel. This vehicle is a HUGE hit with my son and he has been busy building towers, knocking them down, then tidying them up with the shovel.
There are a couple of video’s of these little things in action on my You Tube page: https://www.youtube.com/user/MrMickPosner (and a video of my chicken food winch system)
Posted in Admin and General, ASIC Verification, Bug Hunting, Debug, Early Software Development, FPGA-Based Prototyping, FPMM Methods, Getting Started, HW/SW Integration, In-System Software Validation, Man Hours Savings, Mick's Projects, Milestones, Project management, System Validation, Technical | Comments Off
| © 2015 Synopsys, Inc. All Rights Reserved.