BLOGS & FORUMS
Breaking The Three Laws
|Breaking The Three Laws|
Archive for the 'Tips and Traps' Category
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 | No 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 5th April 2014
Not many people know this but I am a FPGA-based prototyping Ninja-Fu master. What super power do I have you ask? I have the power to enable higher performance prototype operation and in this week’s blog I am sharing this ancient secret power with you. Wow, the start of this blog sounds like the bio from a really bad “B” movie, it definitely seemed funnier in my mind, then again everything seems funnier in my mind. There is actually some seriousness to this blog as I really am going to share the not so secret method to enable higher performance in your FPGA-based prototypes.
First, let’s study a typical SoC, this case it’s ~40-50 Million ASIC gates. I chose this design as it’s easier to explain but the principle for higher performance operation is even more important for larger more complex SoC’s. Our example SoC includes a CPU with tightly coupled GPU and DDR3-based memory subsystem, PCIe high performance interface, SRAM scratch pad storage, global bus, custom logic block (your SoC’s special sauce for instance) and a number of lower performance peripherals
When you model such an SoC in an FPGA-based prototype, even with the largest FPGA’s, you need to partition the design. Partition is to split up the design across multiple FPGA’s. The challenge is that the SoC design blocks have more signals than you have FPGA pins (Hey that’s one of the three laws of the breaking the three laws blog). We all know that when you partition such a design you need to insert pin multiplexing to manage the many signals over the limited FPGA pins. As I am writing this I suddenly realized I have shared the secret of higher performance prototyping before, here, anyway, this blog is way cooler so I’ll continue writing.
The challenge of partitioning this design is that due to the tightly coupled CPU/GPU you end up with many signals spanning out from a small number of design blocks. Lets assume the CPU and GPU are partitioned across two FPGA’s. If all you are prototyping is these two blocks then with the use of pin multiplexing you can connect the two blocks together. The challenge of this prototyping project is that you are also modeling the other design blocks as you want to validate the software and use that to validate your RTL design blocks. This means you end up with the SoC partitioned across four FPGA’s which forces even more connections between FPGA’s.
The picture above is a representation of the partition, the raw IO interconnect usage and the number of external IO’s required for daughter boards. Suddenly you see not only the sheer volume of interconnect needed but also the number of individual connectors required to create such an partition. Just look at FPGA 2, it’s packed with IO and daughter boards. You could try and partition the design in a different way but it’s sure to tank the performance as the GPU needs to be tightly coupled to the DDR3 memory and the CPU requires a tight link to the PCIe interface. If you sacrifice physical IO between FPGA 1 and FPGA 2 you will end up with very high pin mux ratios resulting in very low system performance.
If you were to try and model this SoC on a board with a fixed interconnect between FPGA’s or forced to use a board with great big IO connectors you would physically not be able to support SoC designs like this. With the fixed interconnect board, even if you could work out a partition, you will have to force fit your SoC interconnect topology across a fixed number of IO’s resulting in high mux ratio’s thus low performance. In addition it’s unlikely that the board would have the number of available external connector IO to support the SoC’s external interfaces for daughter boards. It’s similarly bad on a board with high pin count connectors. Using our typical SoC as the example, if the FPGA-based prototyping board has FMC like connectors, ~150 IO’s per connector, you would need ten connectors to support the required interconnect and daughter boards for the tightly connected CPU/GPU. Whoops, I know of no board that has this many connectors. Again you would be forced to use very high pin multiplexing tanking the performance and making the platform worthless.
Now look at the HAPS-70 S48, the Synopsys four FPGA FPGA-based prototyping system. This type of typical SoC design is the reason why the HAPS-70 systems expose all the FPGA’s pins to HapsTrak 3 (HT3) connectors. HT3 granularity is 50 FPGA IO’s per connector and are bank matched to the Xilinx Virtex-7 2000T banks and Super Logic Regions (SLR’s). This granularity is the “not so secret” enabler for SoC prototyping and the key to higher performance operation.
Now you can see that not only do you have the connector granularity to tailor the interconnect to the requirements of the SoC design but you also have ample connectors to support the external IO daughter boards. You can create a very dense interconnect between FPGA 1 and FPGA 2 supporting the tightly coupled CPU/GPU and you don’t need pin multiplexing as you have the physical number of IO’s needed. At the same time you can support all the other interconnect requirements to the other FPGA’s and the required daughter boards.
Hold on, there’s more….
You have ample connectors to setup the prototype with the needed JTAG debugger daughter board connecting your software debugger to the CPU. You have ample connectors to add real time debug to the platform. Real time debug is when you extract signals from the design and route them to a debugger daughter board which you connect a logic analyzer to. Oh and you can also add on some HAPS Deep Trace Debug memory so you can capture seconds of debug visibility. So not only is the HAPS system higher performance but the hardware architecture is the enabler for prototyping typical SoC’s. If you are smart you will also understand that as the SoC grows in size and requires more FPGA partitions that the HAPS flexible interconnect architecture becomes even more important. Below you can see a picture of the HAPS-70 S96, eight FPGA system, deployed for SoC prototyping enabling earlier software development and system validation
Now you have the secret Ninja-Fu.
I’ve pretty much finished my large tracked vehicle project which I featured last week. I plan to add a controllable shovel and other attachments to the front but I got side tracked building a new project.
This is a very small shovel dozer, you can see how small it is as it’s sitting on top of my home-built tracked vehicle. (Or maybe my tracked vehicle is just very big). You this little shovel dozer come from a kit but rather than using the supplied hard wired connection I’m going to retro fit this model with some tiny radio controlled electronics. I have not built the RC control yet and with upcoming business travel I’m not sure when I am going to get a chance to. I’ll be sure to post an update when this latest project is finished.
Posted in Debug, Early Software Development, FPGA-Based Prototyping, HW/SW Integration, Mick's Projects, System Validation, Technical, Tips and Traps | Comments Off
Posted by Michael Posner on 16th March 2014
Is this the future of wearable technology?
LOL, no…. well maybe…..
There are lots of questions on if wearables will bring the end of the Smartphone, I personally think these two technologies will co-exist. I like the idea of wearing my technology but there are many people that don’t thus there should be a place for both technologies for a while yet. Of course for anyone who travels a lot like me they will know that the airport security creates a new issue not previously encountered. I use a fitbit which is a small step tracker and I wear this on my trouser (pant) pocket. It pretty much lives in this spot and I’ve almost put it through the washing machine when I’ve forgotten to take it off. The problem is that this little device has become a part of my life and when going through airport security I’ve also forgotten to take it off which leads to an extra search pat down. A simple solution to this would be for me to remember to take it off but it would be nice if these devices are security certified of something like that.
When it comes to prototyping these deeply embedded SoC designs you will find out that while the form factor is small and simple the SoC designs are not. These designs are multi-million ASIC gates so when they are prototyped using FPGA’s the challenges of handling non-FPGA code, multi-FPGA partitioning and prototype assembly must be overcome. I visited a load of customers last week while traveling internationally and the common theme at the meetings was discussion around how to enable complex FPGA-based prototyping without the need for in-depth specific expertise. The first place to start is to put a methodology in place to define a flow supporting FPGA-based prototyping making a part of the larger SoC project. The FPGA-based Prototyping Methodology Manual, FPMM, is the perfect place to start in defining what is needed as part of this flow.
I had the pleasure of traveling with Rene Richter, one of the co-authors of the FPMM. In the picture above you can see him explaining the basis of multi-FPGA partitioning and how to utilize pin multiplexing. His expertise helped a lot of customers last week but he was the first to say that everything he explained was already documented in the FPMM.
This week’s call to action, download the FPMM if you have not already done so………… and read it.
I was thinking that it might be time to work on the 2nd revision, updating the FPMM with information on how FPGA-based prototyping has evolved over the last couple of years, what do you think? What do you think has changed in FPGA-based prototyping which should be documented?
Posted in ASIC Verification, FPGA-Based Prototyping, FPMM Methods, Getting Started, Technical, Tips and Traps | Comments Off
Posted by Michael Posner on 17th January 2014
This week’s blog is going to show you how FPGA-based prototyping delivers a whole new level of WOW factor to a new product introduction. Oh, and this also sends a message of reduced risk to the prospect customer. OK, so here we go, recently Synopsys announced the industry’s first USB Superspeed 3.1 10 Gb/s platform to platform, host to device, data transfer demonstration. Here is a link to the news release.
It’s one thing to make claims in paper but delivering a real demonstration of the capability adds a whole level of credibility to the data being presented. Here are the set of videos of the real demonstrations of USB 10G transfers
The Synopsys HAPS and DesignWare IP was also used by the USB-IF to demonstrate the new USB Superspeed 3.1 10Gb/s capability: http://www.anandtech.com/show/7652/usbif-updates-us-on-type-c-connector-demonstrates-usb-superspeed-31-transfers
I’ve mentioned this in a couple of my blogs that in addition to FPGA-based prototypes being used for early software development, HW/SW integration, System validation they are the single best pre-silicon method to demonstrate new product capabilities to your prospect customers. Seeing the product in action is far more credible and valuable than simply reading a product pitch or spec sheet. A real pre-silicon demonstration leaves the prospect customer with a feeling of reduced risk with your new product as they just saw it and played with it. (it feels far more real) The same demonstration platforms can also be delivered to the prospect customer enabling a more complete evaluation or for early software development of applications that will sit on top of this new product.
Are you using FPGA-based prototypes to deliver pre-silicon demonstrations?
Also, did you like this shorter blog or my longer more in-depth blogs which I did the last couple of times?
Posted in FPGA-Based Prototyping, Tips and Traps | Comments Off
Posted by Michael Posner on 10th January 2014
As it’s my first blog of 2014 (Happy New year and all that) I wanted to reflect back on 2013 and what better way to do that than review the best of the best of my blog postings from 2013. So drum roll please… here is my short list of cracking blog posts from 2013 in chronological order. This is not a list of all the blogs (but it did turn out to be a big list) just the ones that I personally think have the most valuable FPGA-based prototyping information.
Also, check out my new Blog Bio Photo –> 007 Style !!
How IO Interconnect Flexibility and Signal Mux Ratios Affect System Performance
One of the “Breaking The Three Laws” is that your SoC partitioned blocks typically have more signals than physical IO’s on the FPGA. Technically this is not one of the three laws but it should have been and as I own this blog I can make one more up. Welcome to the Breaking The Four [...]
Direct Route or Take the Bus?
Last week’s blog was on direct interconnect density and the effect it has on pin mux ratios. The example focused on using HSTDM but one of the readers correctly pointed out that interconnect density effects any pin muxing scheme, not only HSTDM. The rule of thumb is the greater the density of interconnect routes the [...]
UFC: Cables Vs. PCB Traces
UFC: Cables Vs. PCB Traces With the new HAPS-70 all cable based interconnect architecture we often get asked about overall raw performance of the cables vs. PCB traces. Below is the data on the raw cable and new HapsTrak 3 connector performance. This in itself shows that the cable and connector architecture are cable of running [...]
Jim Hogan falls prey to HAPS cloak of invisibility
I used to own a Ford F350 truck and it was huge with the long wheel base, full bed, extended crew cab measuring a length of about 25 feet (8 meters). The problem was that it came installed with a cloak of invisibility. I didn’t know it had a cloak of invisibility when I purchased [...]
EDACafe Video’s and the best dressed presenter
While at DAC, EDACafe video interviewed me discussing the HAPS-70 FPGA-based prototyping solutions. You can find the video here: http://www10.edacafe.com/video/Synopsys-Mick-Posner-Director-Product-Marketing/40055/media.html I liked the interview style and the whole interview was shot in one take, no breaks and was completed in less than 5 minutes. I think you will find the video informative so please watch [...]
Complex SoC Prototyping using Xilinx Virtex-7 based HAPS-70 Systems
At the recent SNUG UK Paul Robertson from Broadcom presented a paper on their use of FPGA-Based Prototyping for their current generation of SoC’s. For those with Synopsys SolvNet access the paper can be found by following this link: http://www.synopsys.com/Community/SNUG/UK/Pages/Abstracts.aspx?loc=UK&locy=2013#C1 Based on participant votes Paul was awarded with the prestigious “Best of SNUG” award. Congratulations [...]
Understanding IP and IP to SoC Prototyping
I’m presenting at the quarterly GSA Intellectual Property (IP) Working Group Meeting this morning and while reviewing my slides I thought I would blog on a couple of aspects of IP (RTL blocks) and IP to SoC Prototyping. I’ve blogged on this topic before but it was ages ago and even I’ve forgotten what I spoke [...]
Do you use a hammer to put in a screw?
This week I was asked to compare the Synopsys HAPS systems to FPGA vendor evaluation boards. I only have good things to say about the FPGA vendor evaluation boards but when comparing these evaluation boards to HAPS for serious FPGA-Based Prototyping I just said, “That’s like using a hammer to put in a screw”. A [...]
Designing an Electrochemical Cell
A couple of folks complained that my last blogs have been a bit long and boring. (Boring! Me?) So I would like to start this week and apologize to all my 5th Grade readers, I’ll try harder in the future to use smaller words and more pictures. The good news is that this week is [...]
Accelerating Prototyping Hardware Assembly
This week I wanted to focus on a discussion around prototyping hardware assembly. Prototype hardware assembly is the process to tailor FPGA-prototyping hardware to meet the needs of the project. The first type of prototype assembly would be to build a custom platform directly matching the projects requirements. The building of prototyping hardware is the [...]
Xilinx FPGA’s for FPGA-Based Prototyping
If we look at the FPMM survey respondent data it’s clear to see that the favored FPGA device for FPGA-based prototyping is Xilinx devices This week Xilinx announced the Virtex® UltraScale™ VU440 3D IC. http://press.xilinx.com/2013-12-10-Xilinx-Doubles-Industrys-Highest-Capacity-Device-to-4-4M-Logic-Cells-Delivering-Density-Advantage-that-is-a-Full-Generation-Ahead This is the device that Xilinx wants the future generation of FPGA-based prototyping hardware to make use of. Rather than [...]
Tear down of the new HAPS-DX FPGA-based prototyping system
I’ve talked about streamlining IP to SoC prototyping and the use modes that prototypers use for IP validation. This week Synopsys announced the new HAPS Developer eXpress (HAPS-DX) prototyping system. This new HAPS-DX system is perfect for complex IP and subsystem prototyping and ties in nicely with the flow that I have been blogging about [...]
Posted in Debug, FPGA-Based Prototyping, FPMM Methods, Getting Started, In-System Software Validation, Technical, Tips and Traps | Comments Off
Posted by Michael Posner on 7th December 2013
It’s been a quiet week for me and prototyping but I did talk to an engineer about command and control of an FPGA-based prototype which I thought was quite interesting I will share the story.
The engineer was designing a subsystem and within the FPGA-based prototype wanted the capability to pre-load the DDR memory with contents as well as to dynamically control the register configuration. Initially the engineer was thinking about building custom hardware and software capabilities to achieve this which was a long and risky approach. I was able to make the engineer very happy by providing them an overview of the available Universal Multi-Resource Bus (UMRBus) capabilities the HAPS systems have.
To solve the pre-load problem the engineer had the UMRBus can be combined with a transactor which enables data to be easily written across from the host directly into the DDR memory. The UMRBus interfaces with a standard transactor like one for AMBA AXI. The data is written from the host and the transactor passes the data to the on chip bus interconnect which enables the data to be written to memory. The engineer can use the simple TCL based UMRBus interface from the host to facilitate this data write or could also make use of the generic C++ API and create a more comprehensive setup. It should be noted that in addition to pre-loading the memory like this the memory can also be read back for post process data analysis.
To solve the problem of dynamically controlling the DUT within the prototype the UMRBus can be deployed again. This time rather than using a full transactor the engineer would make use of the Client Application Interface Modules, CAPIM, which is a simple write/read interface which can be customized to meet the design interfaces needs. This was perfect for this use case as the DUT had a simple registered interface meaning the CAPIM could quickly be wired up to it. Again the CAPIM can be accessed via the simple TCL interface or from the C++ API.
Problem solved, happy engineer.
Talking of command and control I’m currently building a toy for Christmas which is designed to be like a command and control module.
This is just a picture of a little bit of the project. The front panel will have switches, buttons, dials and LED’s which my son will be able to play with. It doesn’t really do anything specific other than light up LED’s but when you add a child’s imagination to this it will turn into amazing things. The command module of a boat, car, space ship, submarine and everything else that they can imagine. I’ve been working on it for a couple of weeks now and I’ll post pictures of the final product closer to Christmas.
Posted in FPGA-Based Prototyping, Mick's Projects, Tips and Traps | Comments Off
Posted by Michael Posner on 8th November 2013
As we all know FPGA-based prototyping enables early software development, HW/SW integration and system validation but did you also know that HAPS FPGA-based prototyping is also designed to make Eric Huang, PMM for USB IP at Synopsys famous? I’ll be honest, when we designed the HAPS-70 systems we did not highlight this as part of the MRD which shows that sometimes capabilities evolve on their own.
The HAPS-70 is making Eric famous as it’s being used by his R&D team to validate and demonstrate the new 10G USB 3.1 standard. Eric recently published a video documenting the first platform to platform demonstration of 10G USB 3.1 and it’s powered by HAPS-70’s. (Eric-Hollywood-Huang we call him in the office now). There are some very pretty models in the video, HAPS-70 based prototyping models that is. The HAPS-70′s are the real star’s of this video
Eric and his R&D team have been working on 10G USB 3.1 for a while now and a couple of weeks back I cornered Eric in the lab to quiz him on the HAPS-70 usage. The HAPS-70 FPGA-base prototyping solution enabled this team to rapidly develop a validation platform and enabled this demonstration. I’ve mention this before but FPGA-based prototyping is the single best way to wow a customer with functionality implemented in hardware giving the demonstration high credibility.
The Synopsys DesignWare USB R&D team (the stars behind the scenes) were able to prototype both the 10G USB 3.1 Host and 10G USB 3.1 Device using the HAPS-70 platforms. The flexibility and capabilities of the HAPS-70 enables the USB R&D to quickly customize the platforms to meet the designs needs. One of the key parts of the development was a way to connect the two separate platforms together using a standard USB cable while transmitting and receiving at the new higher 10G rates. For this the DesignWare USB R&D developed a custom HAPS Multi-GigaBit daughter boards, MGB for short.
HAPS has had an MGB interface implemented for a number of generations now and there are available off the shelf daughter boards for it such as PCIe, Ethernet and SATA. It’s a very well documented simple daughter board interface with reference designs and the DWC USB R&D team were able to develop this custom USB 3.1 MGB in about two weeks. Now that’s rapid prototyping.
In the 10G USB 3.1 demo you can see that the demonstration uses host machines to run the software that is executing on the USB 3.1 cores. The DesignWare USB 3.1 IP team use the PCIe connected IP validation mode. If you remember I blogged about this IP validation usage mode a couple of months back. The PCIe connection is also hosted via the MGB, this time using the off-the-shelf HAPS PCIe MGB. It can be seen in the picture below, it’s the thick cable sticking out of the HAPS-70 and then connected into the host via a host adapter card. This connection is an off-the-shelf offering for Synopsys so it’s easy to deploy in your designs as well.
I’m going to visit Eric next week and see if I can encroach on his stardom and get myself into one of his videos.
I can’t wait for 10G USB 3.1 to go mainstream. USB 2.0 was revolutionary at the time and USB 3.0 at 5Gb/s was a huge leap forward. Copying files which took minutes with USB 2.0 then took mere seconds with USB 3.0. But then the files got bigger and the copy times started to increase. Hey presto… along comes 10G USB 3.1 to the rescue, yay. Super fast copy, sweet.
Posted in ASIC Verification, FPGA-Based Prototyping, In-System Software Validation, Tips and Traps | Comments Off
Posted by Michael Posner on 26th October 2013
I noticed that Synopsys launched the new Verdi3 which provides the capability to debug both the hardware RTL code and the Software C code. Here is a video demo of the new capabilities: http://www.synopsys.com/Tools/Verification/debug/Pages/verdi-hw-sw-debug-video.aspx
Verdi3 addresses the need for a simultaneous view of both hardware and software languages enabling designers to efficiently and effectively advance their debug productivity. So call me a geek but I think this is way cool. I think it’s so cool as I see this as a key new technology which will really benefit designers doing FPGA-based prototyping. The reason I say this is that FPGA-based prototyping is when you are executing key software modules against the hardware aiding in hardware validation and hardware/software integration. Having combined hardware and software debug visibility is going to help you track down the source of the bug much faster.
This is one of the key challenges engineers talk to me about. FPGA-based prototyping gives you the ability to run software against the hardware but when you do run into an issue it can sometimes take a long time working out if the issue is a result of hardware or the software. I’ve seen this at interoperability plug fests where we have the DesignWare IP running on HAPS enabling the IP to be put through the full interoperability testing. Many of the DesignWare IP’s are a combination of the hardware RTL and a software driver. When we run into an issue we have to quickly work out if the error source is our RTL, our software or the component that we are testing interoperability against. Historically we have used a mix of FPGA-base prototyping hardware debug tools such as Synopsys’ Identify and off-the-shelf software debuggers. I am sure we will be looking at utilizing the new Verdi3 in the future.
While we are talking about Synopsys’ Identify did you know that it includes an interface for Verdi? Well it does, extending the great Identify at-speed FPGA-based debug capabilities to Verdi (and visa-versa)
From Verdi you can write out a list of points that you want to add debug visibility and Identify uses this to instrument the RTL. Verdi can be used to automatically create a list of “essential signals” for a block or module. This list of essential signals is the minimum set that Verdi needs to provide 100% debug visibility to the module. Verdi does not require you to log all points as it can re-build the logic state of the others as long as it has the details of the essential signals. This is an amazing feature when added to the FPGA-based prototype. Logging just the essential signals minimizes the FPGA logic utilized for instrumentation while at the same time providing 100% visibility for debug.
The FPGA-based prototype runs at hardware speeds and Identify captures the signal trace data. Once you are finished you then simply export the Verdi FSDB for post processing.
The integration between Verdi and Identify is just one of the many debug capabilities that the engineers have at their fingertips. When using HAPS as the hardware platform you can combine the use of the HAPS Deep Trace Debug with the Verdi support providing the capability to store a huge amount of signal trace data.
Wow, how did this happen, this blog got huge (its Saturday morning) Do you do FPGA-based prototyping? (yes because you read my blog) Do you have access to Verdi? If the answer is yes I would like to hear about your experience in combining the two enabling superior debug visualization and efficiency.
Only lame spam this week. Well all spam is lame but this week was really lame.
Posted in ASIC Verification, Debug, FPGA-Based Prototyping, Tips and Traps | Comments Off
| © 2014 Synopsys, Inc. All Rights Reserved.