HOME    COMMUNITY    BLOGS & FORUMS    Breaking The Three Laws
Breaking The Three Laws
  • About

    Breaking the Three Laws is dedicated to discussing technically challenging ASIC prototyping problems and sharing solutions.
  • About the Author

    Michael (Mick) Posner joined Synopsys in 1994 and is currently Director of Product Marketing for Synopsys' FPGA-Based Prototyping Solutions. Previously, he has held various product marketing, application consultant and technical marketing manager positions at Synopsys. He holds a Bachelor Degree in Electronic and Computer Engineering from the University of Brighton, England.

Peraso engages ludicrous speed and moves past plaid

Posted by Michael Posner on April 21st, 2014

We just published a new success story on Peraso’s use of a number of the Synopsys IP, Tools and HAPS which is why I added the little call out to note this. https://www.synopsys.com/dw/doc.php/ss/peraso_usb_arc_amba_ss.pdf

Feel free to read the whole thing but I’ll focus on what HAPS and prototyping enabled for Peraso. This is what Peraso had to say about it.

Prototyping for Fast System Bring-Up
While working with Synopsys Professional Services, Peraso discussed their need for early software development and Synopsys Professional Services demonstrated how Synopsys’ Virtualizer virtual prototyping tool and HAPS FPGA-based prototyping system could help. Peraso used Virtualizer to start their software development tasks before RTL availability and seamlessly transitioned to their hardware/software integration tasks and system validation with the HAPS FPGA-based prototyping system. “Including Virtualizer and the HAPS system in the suite of Synopsys products we used on this project easily saved us three to six months in development time,” said Lynch.

That summarizes it nicely. As I have noted before, prototype enables earlier, earlier software development, earlier HW/SW validation and earlier system validation. Peraso was able to benefit from all this by utilizing Virtualizer for pre-RTL software development and then smoothly transitioned that to FPGA-based prototyping with HAPS and ran that same software directly on the RTL representation of the design. I’ve reached out to the team at Peraso to see if I can get a couple of pictures of their HAPS setup. Maybe I can get them to guess blog on their usage as well.

It’s been a rather tough couple of weeks for me. Before I went on my trip last week I was feeling a little drained but of course didn’t think it was anything special. While on my trip I felt worse and as soon as I returned to USA I ended up in Hospital, Pneumonia was the diagnosis. Yuck, lack of breath, no strength, drenched in sweat from fever and coughing up some horrible stuff. I was prescribed some antibiotics which cheered me up other than the fact that these same antibiotics are used to treat plague and anthrax victims.

It’s day three after starting the antibiotics and I still feel drained, I’m looking forward to turning the corner and feeling better again soon.

Extra kudos for anyone who comments with the name of the movie the title of this blog draws from?

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

Posted in Early Software Development, HW/SW Integration, In-System Software Validation, IP Validation, System Validation | No Comments »

When Robots Attack!

Posted by Michael Posner on April 12th, 2014

My blog on prototyping last week was huge and I have been told people are still reading it, as in they started last week and they have yet to make it to the end. This week’s blog should be nice and short and mostly off-topic.

I visited a robotic competition over the weekend using the excuse that it would be educational to see the engineering behind the creation of the robots. Really this was not an excuse, I love robots and wanted to see if I could pick up any tips and tricks from the robots competing which would aid me in my remote controlled vehicles I have been building. The builders of these robots were from Grade 9-12 and the competitions are run by FIRST. The robot challenge this year, and it changes each year, was to shoot a large inflated ball into goals, over bars or pushed into holes.

The atmosphere was great, all the kids want to win but they all cheer on the other teams. The competition groups three teams together on one side competing against another set of three teams, the reds and the blues. Extra points are awarded for robot to robot teamwork in preparation for a scoring shot. A the start of the match the robots run autonomously for the first 10 seconds executing a predefined program that the team has programmed. After the initial 10 seconds the control turns over to manually controlled by joystick or dedicated controller. The action is fast and furious with robots spinning around trying to shoot and defend.

The most amazing thing for me was to see all the designs the robots used to solve the problem of picking up the ball and shooting it. If you think about they were all solving the same problem but they all came up with many different ways to solve it. It was great to see engineers in the making. I commend the sponsors as without their help many of these kids would never be exposed to such electrical, mechanical and computer engineering. While I’m saying it, thank you Raspberry Pi who created a platform putting computer and programing capabilities in reach of everyone. I’m personally looking forward to the next generation of engineers who will have grown up totally immersed in engineering.

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

Posted in Humor, Mick's Projects | No Comments »

The Secret Ninja-Fu for Higher Performance Prototype Operation

Posted by Michael Posner on April 5th, 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.

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

Posted in Debug, Early Software Development, FPGA-Based Prototyping, HW/SW Integration, Mick's Projects, System Validation, Technical, Tips and Traps | No Comments »

The Prototyping Rub from SNUG San Jose

Posted by Michael Posner on March 27th, 2014

 

It was the Synopsys Users Group, SNUG in San Jose this week and on top of the Synopsys announcement on ICC 2.0 with the Powar (I know this is a typo but I enjoy saying the word like this, you try it Powarrrrrr) of 10x there was a whole track dedicated to FPGA-Based prototyping. Knowing that the whole world does not revolve around California I thought I would provide you with an overview of the days FPGA-base prototyping sessions. As a reminder if you have an active Synopsys SolvNet account you can download the session presentations and papers shortly after the event ends

The day started with : Automating SoC RTL to Operational Prototype – Synopsys R&D Presentation

This session delivered technical information on new Synopsys prototyping software that increases the level of automation and streamlines RTL to operational HAPS FPGA-based prototyping including ultrafast partitioning. I personally think this session might have been a little too technical (is there such a thing) as it jumped into how the software solved the problems but seemed to skip the explanation of the problem itself. Now for experienced prototypers they immediately saw the benefits being delivered but I think some of the more in-experienced prototypers were in over their heads. Even with this in mind I highly recommend this presentation. Using this software the user can see up to a 50% reduction in time to prototype, achieve on average 2X or more performance improvement in system performance and get greater debug visibility.

Next up: Achieving Maximum System Performance on Multi-FPGA designs using HAPS-70 System – SanDisk use of HAPS-70 for an enterprise SSD SoC

Two words, killer presentation. I love seeing real users present their experience with FPGA-based prototyping systems. This presentation included the various steps that SanDisk used to bring up the HAPS-70 FPGA-based prototype of their enterprise SSD design and then optimize it for the highest system performance possible within the limitation of the SoC design constraints. It was very interesting and I recommend the presentation as it includes lots of great real world information on what it takes to create a full SoC FPGA-based prototype. The picture above was snuck off without anyone noticing (until now) pictures/videos within the sessions is prohibited. (whoops)

Final presentation of the day was: Putting IP and Subsystem Prototyping on the Fast Track – Synopsys Mick Posner (yes that’s me) and Antonio Costa from the DesignWare IP R&D team.

I came prepared with giveaway’s to bribe the audience for good feedback, we will have to wait and see if that worked. I introduced HAPS-DX for complex IP and Subsystem prototyping and tried to explain the various validation use modes and best practices for IP prototyping to streamline hand-off to the SoC team streamlining their prototyping efforts. I then handed over to Antonio who provided details on how the DesignWare IP R&D utilize the many generations of HAPS systems to validate the IP. I think the bits that resonated the best with the audience was Antonio’s explanation of the validation scenarios that could only be reached using FPGA-based prototyping. Antonio also introduced the IP R&D teams use of HAPS Deep Trace Debug to capture seconds of debug visibility enabling long protocol scenarios to be successfully debugged.

I highly recommend that you download these SNUG presentations on FPGA-based prototyping from SolvNet.

Progress on my latest garage project has been slowed by business travel and sickness. But I have made some progress and am happy to say that basic functionally has been validated.

If you can’t recognize what it is from this picture then let me tell you that it’s a custom designed remote control tracked vehicle with full suspension tracks. I designed the track runner system and this picture is of revision 2.0. It’s not perfect but it does the job and I can see a 3.0 revision to get better articulation. When finished I’ll take a little video if it in action, it’s a lot of fun. Here is a preview of the vehicle in action: https://www.youtube.com/watch?v=yF4uRSzL5qQ 

Some has asked me where I find time to do projects like this, the answer is I don’t find time but I manage to fit in a little here and there at the expense of other things like family time, house projects, eating…. I’m going to slow down on the project as family time, house projects and eating should really take priority.

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

Posted in ASIC Verification, Bug Hunting, Debug, Early Software Development, FPGA-Based Prototyping, HW/SW Integration, In-System Software Validation, IP Validation, Mick's Projects, System Validation, Use Modes | No Comments »

Avoiding Virus Contamination

Posted by Michael Posner on March 24th, 2014

You might think this blog is going to be all about using high tech to avoid having your laptop infected with a nasty virus but it’s not. It’s about the traditional virus avoidance, trying not to contract the flu.

Unfortunately I returned from my China/Taiwan trip with a hitchhiker of significance, the flu. I’ve not been badly sick since 2011 and this flu knocked me off my feet. When I travel I try my best to stay healthy and I do a couple of things to avoid picking up a nasty bug. Below are a couple of the things that I do to avoid other peoples bugs:

  1. Sanitize my airplane space. I travel with bleach wipes and use them to sanitize the area around me on the plane. I ran out of these wipes before the last trip so this could have been where I picked up my bug
  2. Avoid touching my eyes, nose and mouth with my hands. This is the way bugs get in so just don’t do it
  3. Always sanitize or wash my hands after shaking hands with the people I meet. Washing the germs off is better than trying to kill them with chemicals but if sanitizer is all you have it’s better than nothing.
  4. Exercise. I don’t know if this helps but I feel more healthy when traveling if I continue to work out as normal
  5. Eat healthy. Again I don’t know if this helps but I feel better if I eat healthy foods. Sometimes while traveling you don’t get the choice of what you eat

What other tips would you provide to help stay healthy while traveling?

More on FPGA-based prototyping next week. I’m presenting at SNUG in San Jose this week so I’ll return to normal blogging later in the week.

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

Posted in Bug Hunting | No Comments »

Prototyping wearables and the Internet of Things (IoT)

Posted by Michael Posner on March 16th, 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?

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

Posted in ASIC Verification, FPGA-Based Prototyping, FPMM Methods, Getting Started, Technical, Tips and Traps | No Comments »

More than just early software development as easy as 1-2-3

Posted by Michael Posner on March 6th, 2014

I often get asked about enabling early software development and there are a number of technologies that can help here. Of course the earliest way to enable software development is with Virtual Prototyping using tools like Synopsys’ Virtualizer. A virtual prototype has the advantage that it can be done pre-RTL so at any time during the project phase. This is a great approach but the specific question I was asked this week was is there any way to run software against a new RTL design before a processor is integrated into the design. Again, easy answer, Hybrid Prototyping, this is where you typically model the CPU subsystem in the virtual prototype and connect to the FPGA-based prototype via transactors.

Great right!….. Well no, this was not what this specific customer wanted to do. They wanted to create a standalone FPGA-based prototyping setup that would enable early software development and act as a “boxed” customer demonstration. They wanted to be able to connect two of these systems together to show complete end-to-end capabilities. These would also be the sample platforms that they would use for compliance testing and interoperability tests.

<Click pictures to enlarge>

The customer does not have access to the RTL for the 3rd party CPU that they plan to use in the final SoC otherwise I would have suggested just modeling the complete SoC in HAPS.

It just so happens that the ARC Software Development Platforms have just been made available: Synopsys Launches DesignWare® ARC® Software Development Platforms:

These are pre-Verified Hardware and Software Platforms Integrate ARC Processors, Peripherals, Operating Systems and Software Development Tools to Enable Immediate Productivity. You can watch a video of the platform in action from this page. http://www.synopsys.com/dw/ipdir.php?ds=arc-software-development-platform

I showed this to the customer and they immediately stated that while the ARC is great it’s not the embedded processor they are using in their end SoC design. I know that but at a software development application level, C code is just C code right? Silence……. Silence…. Right….. This little ARC software development platform include HAPSTrak connectors designed to enable the board to be connected to HAPS systems. There is a bus routed across this connection enabling the ARC to rapidly integrated into the rest of the system under test.

Here is an example setup like this. In the picture you can see the HAPS-DX connected to the ARC Software Development Platform via standard HAPStrak cables.

The ARC Software Development Platform also supports connection to the higher capacity HAPS-70 systems (it will even connect directly to the HAPS-60 and HAPS-50 systems if you already had those available)

Sorry, picture taken in Fuzz-o-Vision

The software runs on the ARC, in our above example Linux is booted and application software can be developed to manage the design under test. The application written in C code can be made portable so it can be quickly re-compiled for other embedded processors.

Problem solved as easy as 1,2,3! #1 – Prototype RTL in HAPS, #2 – Connect HAPS to ARC Software Development Platform, #3 – Start software development. As this setup is relatively small it’s easy to box it up and use it for demonstrations, compliance testing and highly portable for interoperability and plug fests. The customer pointed out that their might be a couple more steps in the process but as I like to say “Don’t let the technical details get in the way of a good story” Mick(TM). As you can see this little platform is more than just a platform enabling early software development.

What do you think of this solution? Could you utilize something like this?

Finally can you guess what my new home project is from this picture? I should point out that this picture shows a prototype of one of the parts, not the final design.

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

Posted in Early Software Development, IP Validation, Mick's Projects, Real Time Prototyping, System Validation, Use Modes | Comments Off

Super UltraOcta cores with ARM CPU and Imagination GPU’s boosted with FPGA-Based Prototypes

Posted by Michael Posner on February 28th, 2014

Recently All Winner announced that their new UltraOcta A80 Mobile application processor utilizing the Imagination PowerVR 6230 64-core GPU would be coming to mobile devices very soon. (I call this the Super UltraOcta just for the effect)

http://www.intomobile.com/2014/02/25/allwinner-ultraocta-a80-processor-revolutionizes-mobile-market-advanced-biglittle-technology-and-powervr-6230-64core-gpu/

Maybe not many people know this but All Winner utilized HAPS-70, the Xilinx Virtex-7 2000T based systems as part of the development and validation cycle for the A80 Octa SoC

http://www.synopsys.com/Systems/FPGABasedPrototyping/Pages/synopsys-allwinner-ss.aspx

The All Winner SoC features eight ARM(R) processor cores in a big.LITTLE(tm) processing configuration as well as the Imagination PowerVR GPU core. With both CPU and GPU you end up with a lot of hardware/software interaction which we know requires extensive validation to ensure that both the hardware and software are bug free. The high performance of the HAPS FPGA-based prototype enabled a huge volume of tests to be run which are needed to flush out those hard to find bugs.  

All Winner’s eight core-based SoC demanded a high performance validation solution to speed validation of their this SoC design. HAPS FPGA-based prototypes are the proven and essential methodology to perform large SoC validation tasks. HAPS delivered the performance needed to validate Allwinner’s A80 Octa SoC. The complexity of Allwinner’s SoC increased both cost and schedule risks due to the need to verify real-world scenarios early in the development cycle. HAPS mitigated those challenges as a cost effective solution that achieved the performance required to validate Allwinner’s SoC, while reducing ASIC design time and cutting months off their development schedule

I went looking on the WWW for a block diagram of this chip but as it’s so new I could not find anything, what I did find on the following link was an different multi-media design from MediaTek http://www.engadget.com/2013/07/29/mediatek-mt8135-biglittle-mp-powervr-series6-g6200/

I’m sure the All Winner and MediaTek designs are different in various ways but we can use this block diagram (on the linked page) to talk about the main componets. You have the ARM CPU and Imagination GPU but you can see all the other standard interfaces such as MIPI, DDR3, LPDDR, USB and a whole bunch of sensor interfaces. The strength of FPGA-based prototyping as mentioned above is perfromance and real world IO. Mobile multi-media designs like this are a perfect fit for FPGA-based prototyping due to the real world interface testing need as well as the challenge to validate the CPU to GPU connectivity. CPUs can be abstrated and run at incredible high performance as virtualized models but GPUs are not a goot fit for abstraction like this. GPUs require full cycle accuracy which is why FPGA-based prototyping is perfect fit for modeling them.

One problem of modeling GPUs on FPGA-based prototypes is the fact that the GPU is typically far bigger than a single FPGA (Hey, that’s one of the Breaking the Three Law’s for FPGA-Based Prototyping). This is where the HAPS Multi-FPGA systems step in and help solve the problem. First the HAPS software tools are used to partition the GPU design across multiple FPGA’s. Belows block diagram is an abstracted diagram of a typical GPU partition. Note the 1000’s of signals between FPGA’s. FPGA’s don’t have this many physical pins so the HAPS High Speed Time Domain multiplexing needs to be used to package up the signals and send them between FPGA’s using a high speed 1Gb/s link.

The HAPS-70 flexible interconnect architecture (Blog on this capability) is utilized to create an interconnect that has increased density where needed to help reduce the overall mux ratio. (Lower mux ratio, higher the system performance) Between this capability and the HAPS HSTDM the resulting platform is optimized and high performance. A GPU partition like the above on HAPS can run in the range of up to 15 MHz which is amazing.

How fast are you running your GPU cores?

Off subject, last week my son was asked to draw a picture of one of their parents hobbies. Finn decided to draw a picture of me and my race car hobby, one of the drawings is below.

I’m not sure where he got the idea that my car racing included using a fire extinguisher to put out engine fires ;) Click the idea link to see a short video of just one case which might have lead him to think this.

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

Posted in ASIC Verification, Bug Hunting, Early Software Development, In-System Software Validation, System Validation | Comments Off

Big.LittleIP

Posted by Michael Posner on February 22nd, 2014

I’ve been traveling in Europe popping into see various FPGA-based prototypers. It’s been a good week of lively discussion covering all aspects of prototyping from mapping RTL to prototype, to higher debug visibility and Hybrid Prototyping. At a number of these visits we discussed IP validation using the PCIe connected use model. I’ve discussed this use mode a number of times, in summary an IP block is placed in the FPGA-Based Prototype and then a PCIe end point core is used to memory map the IP across to a host machine. Typically the IP has a standard SoC bus interface such as AMBA so a bridge from AMBA to a PCIe core is used.  

The PCIe connected mode is delivered as part of the HAPS-DX complex IP and subsystem prototyping system. A automated insertion solution is delivered as part of the HAPS-DX prototyping software tools flow. The users can select the PCIe connected use mode and the software tools will insert a PCIe end point into the prototype. Hey presto, it’s easy to deploy the PCIe connected mode. Now while HAPS-DX meets the need for many IP’s I spoke to a number of customers who’s IP blocks were far, far larger than the capacity of the HAPS-DX, 4 Million ASIC gates. The good news is that the PCIe connected mode can be used with any of the HAPS-70 series as well. On the HAPS-70 systems the multi-gigabyte (MGB) connectors are used with a cable based connection to a host machine. With the HAPS-70 capacity scaling to 288 Million ASIC Gates (more on this in a later blog) you have plenty of space for even the biggest IP blocks.

The great thing about the PCIe connected mode is that the IP can be stressed tested in a similar fashion to simulation unit testing, the difference is of course the performance of the FPGA-based prototype enables far more testing to be achieved. This is perfect for the IP developers and the software engineers as they have a high performance realistic model to work against.

Don’t forget that at some point the IP needs to be integrated into the SoC so that the IP can be validated in the context of the SoC infrastructure.

For all the Irish and American Irish readers, the Guinness is better in Ireland, YUM

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

Posted in ASIC Verification, Debug, Early Software Development, IP Validation, Use Modes | Comments Off

Ice Cream with Raspberry Pi for Remote System Connectivity

Posted by Michael Posner on February 15th, 2014

Engineering departments can no longer afford the luxury of all team members being located in the same office. The term global localization is used to describe how a team is split up over multiple geographies but must function as one unified entity. This is not only true for the personnel but also for the tools they use including FPGA-based prototyping hardware. While every software engineering in the world wishes for a high performance prototype directly on their desk typically logistically and financially this is not possible. FPGA-based prototyping systems must support this capability to ensure they can be accessed from anywhere around the world.

The HAPS series of FPGA-based prototyping systems support remote access via the HAPS Universal Multi-Resource Bus, or HAPS UMRBus for short.

The HAPS UMRBus enables the users to remotely access the HAPS system, configure it, monitor it and basically love it from a distance. The HAPS UMRBus enables much more than just remote access! The HAPS UMRBus enables data streaming to and from the system for test case stimuli or debug, advance use modes such as Hybrid Prototyping and transaction based validation and provides a generic API for user capability extensions. The HAPS UMRBus is able to deliver these additional capabilities because it’s a very high bandwidth, low latency connection from a host machine to the HAPS system.

The HAPS-70 series offers this high performance HAPS UMRBus and an integrated HAPS UMRBus over a lower performance USB 2.0 standard interface. The recommendation is that if you only needed remote connectivity for configuration and monitoring then use the HAPS UMRBus over USB 2.0 interface. If you needed high performance and low latency for Hybrid Prototyping and the other advanced capabilities then utilize the high performance HAPS UMRBus. Great right………………… Enter global localization…..

Our customers love that HAPS systems can be remotely accesses as it enables them to utilize the systems 24/7, 365 days a year (HAPS don’t even get Christmas off). However they like to lock them up along with their server hardware or in a data center. Some customers have dedicated hosts serving the HAPS which enables them to utilize the high performance, low latency HAP UMRBus and all the advanced capabilities. However, others just want to utilize the remote access via the HAPS UMRBus over USB 2.0 and while they have thousands upon thousands of Ethernet drops available they rarely have a host which they can plug the USB 2.0 cable into. So what are these users to do?

Enter the Raspberry Pi (see the blog title was not a typo but I bet the engineers already knew that)

To enable our customers to plug the HAPS system directly into an Ethernet hub one of our engineers came up with the great idea to utilize the off-the-shelf Raspberry Pi.

How it works: You buy a Raspberry Pi, USB cable, power supply and SD card, this is going to set you back around $50 (yep, not a typo, $50 and that’s usually a top of the range one). You then contact Synopsys HAPS support and we will provide you with a boot image to load on the SD card. The boot image is a standard Raspberry Pi OS with the HAPS remote access utilities, called HAPS Confpro, pre-installed. Next connect the USB cable between the Raspberry Pi and the HAPS-70 (or HAPS-DX) system. Finally connect the Raspberry Pi’s Ethernet connection into the Ethernet hub/switch and power it up. We recommend assigning a defined IP address to the Raspberry Pi so the HAPS system it’s connected to can be easily recognized. That’s it, you are ready to access the HAPS system remotely. I personally love this solution as it not only solves the problem but also lends itself for further capability expansion in the future. More on the expansion capabilities in a future blog….

What do you use the Raspberry Pi for?

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

Posted in Admin and General, Debug, Project management | Comments Off