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.

Top Secret IP Accelerated Testing

Posted by Michael Posner on June 6th, 2014

IP-Accelerated

Synopsys’ big press this week from DAC was the announcement of the IP Accelerated initiative. As this initiative combines Synopsys’ leading interface IP, DesignWare, HAPS FPGA-Based Prototyping systems and Virtual Development Kits as you might guess I have been very involved in this evolutionary development. I executed my own personal top secret testing of the deliverables, more on that later in this blog. I’m so happy that we have finally made this initiative public as I have really wanted to talk about it.

Highlights from the press along with my personal comments on each of the bullets

  • The IP Accelerated initiative augments Synopsys’ leading IP portfolio with new IP prototyping kits, software development kits and customized IP subsystems

Synopsys has taken an evolutionary step and will be delivering packaged subsystems for DesignWare IP with HAPS FPGA-based systems for immediate prototyping productivity, virtual development kits enabling pre-RTL early software development. These DesignWare IP reference subsystems also enabling rapid customization for application specific needs. Customers demand high quality IP where the digital RTL controller has been validated against the mixed signal PHY and Synopsys has always delivered this value. The IP Accelerated initiative delivers the DesignWare IP packed up in a reference subsystem. The subsystem enables Linux to be booted immediately, no effort from the user, and includes the DesignWare IP software drivers. These subsystem references enable the IP users to be immediately productive with either early software development for the select IP. For the hardware or prototyping engineers these subsystems deliver a fully operational prototyping reference which can be used to explore the IP capabilities and accelerate the bring-up of an SoC level prototype.

  • The DesignWare IP Prototyping Kits include a proven reference design for the IP preloaded onto a HAPS-DX prototyping system and a software development platform running Linux OS with reference drivers

Wow, it’s like the Synopsys R&D engineers have been reading my blog and have implemented a hugely scalable IP prototyping subsystem enabling immediate productivity and a flow for streamlining IP to SoC prototype bring up.  I urge you to watch the videos, especially the demo as it’s amazing to see Linux boot so fast and see the IP operating under a real OS.

  • The DesignWare IP Virtual Development Kits are SDKs that include a processor subsystem reference design, a configurable model of the DesignWare IP as well as a Linux software stack and reference drivers

These deliverables are targeted at the software engineers who want to start there customization of the DesignWare IP drivers targeting their specific application. The advantage of the SDK is that they do not require RTL, they are highly portable and very fast. The advantage of the hardware based DesignWare IP prototyping kits is that they include the prototyping model of the DesignWare IP RTL so cycle accurate and physical real world IO enabling compliance and interoperability testing. Software drivers developed on the SDK can be executed on the real hardware to validate their operation in real world scenarios.

  • For hardware engineers, the IP Prototyping Kits provide a validated IP configuration that can be easily modified to explore design tradeoffs for the target application
  • For software developers, both the IP Virtual Development Kits and IP Prototyping Kits can be used as proven targets for early software development, bring-up, debug and test

These are self-explanatory, basically you are productive immediately. Even an engineer with no previous IP, FPGA-based or virtual prototyping experience can use them.

  • To reduce risk and accelerate time to market, Synopsys experts can assist designers in creating and customizing IP subsystems for their specific application requirements as well as integrating the subsystems into their SoC

The deliverables are packaged as a reference but as the IP is highly configurable enabling it to be tailored to application specific needs it’s expected that the deliverables will be modified for specific project usage. Some of this customization is enabled directly in the kits and the Synopsys experts are there to help with this task.

As mentioned above, I have been personally involved and took on a top secret project as a test pilot. You can see the summary of the top secret testing here: https://www.youtube.com/watch?v=WN-ZsLK_IZw

IP_Accelerated_Initiative_test_pilot

Do you have a question on the IP Accelerated Initiative? If yes, post me a comment and I promise to respond.

I was at DAC this week, I’ll write up that fun next week

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

Posted in Debug, Early Software Development, Humor, HW/SW Integration, In-System Software Validation, IP Validation, Real Time Prototyping, System Validation, Use Modes | 2 Comments »

Go Faster Stripes

Posted by Michael Posner on May 31st, 2014

It’s was a short week for me with Memorial day on Monday and the I took Thursday off to play at the race track. Next week is DAC so if you happen to be visiting make sure you drop past the Synopsys booth and say hello. I’m only attending DAC on Monday so don’t miss out, maybe I’ll buy you a cup of coffee or something.

My track time this week was tough, I coach for a company called Hooked on Driving and this time I had a novice student who had never been on the track before as well as being the Group D lead. A group lead manages the group ensuring they are safe and controlled. Group D are the top advanced driver group, many of them long time racers, but Hooked on Driving is not a racing event. This group was very hard to control so on top of a novice student I was running around way more than usual. I actually only drove myself in the morning sessions. Here is a link to one lap following one of the Group D drivers. https://www.youtube.com/watch?v=W9eXJ6M2wY4 The good news was that my novice student was very easy going and did a great job on track as well as off track picking me up so I didn’t have to run around too much.

With DAC coming up I promise that I’ll have a lot to write about next week.

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

Posted in Mick's Projects | Comments Off

Imagine more, Prototyping GPU’s

Posted by Michael Posner on May 24th, 2014

While at SNUG in England I had the pleasure of being one of the first people on the planet, yes planet, to see the demonstration of the Imagination PowerVR Series 6XT running at speed on HAPS. The demonstration streamed video data from a host to DDR3 on the HAPS system via a PCIe connection. This video data is then manipulated via the GPU and output in real time to DVI for display on a monitor. The demonstration was very impressive and eye catching to anyone who reviewed it. Imagination internally developed this setup to do what they call DriverLive software development as well as be able to run the 1000’s of GPU compliance tests in a matter of hours thanks to the high performance operation.

For the longest time FPGA-based prototypers would be forced to remove the GPU from the prototype as it used to be too complex to model or the platform did not have the scalability and modularity to handle the size (gate counts) of the GPU. In the above setup the IMG PowerVR Series 6XT is partitioned across four Xilinx Virtex-7 2000T FPGA’s using Synopsys’ prototyping tools. One of the keys to being able to do this is the use of high speed signal multiplexing between the FPGA’s handling the very large number of signals that cross between the FPGA’s. There is also an FPGA being used to manage the interfacing to the host PC, DDR3 and DVI real time connection. This design is over 50 Million ASIC gates but even at this size it’s still one of the smaller GPU configurations.

Imagination’s Colin McKellar presented their use of HAPS at SNUG UK and very shortly the paper will be uploaded to the SNUG Proceedings website found here http://www.synopsys.com/community/snug/pages/proceedings.aspx

Imagination commented in the presentation that they intend to continue to improve this setup expanding the configuration of the GPU as well as implementing the design with ProtoCompiler using HAPS High Speed Time-Domain Pin Multiplexing to increase the performance of the setup. I’m excited by this and promise to blog again as I get more information and am approved to talk about it.

Is there something else you would like to know about this setup? If yes then leave me a comment and I’ll follow up

While I was staying at the Hilton Hotel in Reading the staff decided to give me a nick name, see the food slip below

Yes, Mr. Bacon, I have no idea why they picked this name for me but it’s perfect for me as I love BACON. The hotel offers what I think is the best British Breakfast and of course I use the opportunity to get my fill. I took this picture of one of the courses of my breakfast. I didn’t plan this but I think it looks like a Bacon Cookie Monster

What do you think?

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

Posted in Early Software Development, Humor, HW/SW Integration, In-System Software Validation, IP Validation, Real Time Prototyping, System Validation, Use Modes | Comments Off

First Pass Silicon Success with design up and running in 24 hours!

Posted by Michael Posner on May 16th, 2014

Achieving first pass silicon success is always the goal of the project. While a company may plan for a second chip spin they really want first pass silicon success enabling reduced cost and earlier time to market. I ran across this video featuring Peraso and Eric from the DesignWare USB team,  http://youtu.be/DyNyZP8Ysj4 . Now while Peraso do not claim first pass success bringing up a chip in the lab in 24 hours is amazing. Peraso used HAPS FPGA-based prototypes for system validation enabling them to test their software with their RTL implementation before they taped out. As you can tell from the video, Peraso were very, very happy with the fact that they had the silicon up and running in such a short period.

While we are on the subject of videos, here is another featuring the DesignWare HDMI IP and the HAPS-60 series systems. http://youtu.be/Ao-JeWz9g0A

These examples show the power of HAPS for reducing project risk, achieving first pass silicon success and exhibit high performance enabling the validation of very high speed real world interface.

Honestly I’m a little tired this week so I’m going to keep this blog short. A couple of weeks ago I did get the chance to take out one of the best off-road vehicles on the market. While I am used to far more horse power, this one horse power proved sufficient for the activity and we climbed some terrain that not many other modes of transport could reach. Unlike my other hobbies this trek was very relaxing. In addition I did not burn any fossil fuels in the process.

Do you want to meet me in person? Are you going to DAC? If the answer is yes to both drop me a comment and let me know and I’ll be happy to meet.

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

Posted in ASIC Verification, Early Software Development, HW/SW Integration, In-System Software Validation, IP Validation, Mick's Projects, Milestones, Project management, Real Time Prototyping, System Validation | Comments Off

The price of support

Posted by Michael Posner on May 9th, 2014

One of the unquantifiable values of a company’s offering is it’s support. Support is very important all the time but more so for a hardware such as FPGA-based prototyping products. You may need support on how to use the platform, on using the software, on using the capabilities or support for debugging and resolving a hardware issue. It’s hard to put a value (price) on support as you don’t really value it until you need it.  I had a personal experience this week which in my eyes speaks to the value of support.

For my birthday last year I was purchased a very nice business style backpack from a company called Everki, it’s the VERSA model. This backpack replaced a high quality backpack that I had used for over 10 years. Based on this you can see that I expect a quality product to last a long if it’s treated well. Well within a year my new backpack had an issue

You can see that the zipped material itself seems to have failed and is coming unstitched. I contacted the company and after confirmation that the backpack was indeed a real Everki backpack they assessed the problem and are going to fix/replace the item. WOW. I like to say that you don’t judge a company by a problem, everyone has problems, you judge a company by the way it resolves them. Everki, just like Synopsys, stands behind its products. This exhibits the value of support IMO. What if I had purchased a cheaper backpack and the same issue occurred? Would the other vendor supported me in the same way, I doubt it very much. Sometimes the saying “You get what you pay for” is very true. This is a premium backpack and along with the premium price I received premium support which makes the investment a smart one. It’s great peace on mind to know that my investment is protected and backed by great service and support from the company.

It would be very hard for me to put a price value on support as I think it’s priceless.

In the market space of FPGA-based prototyping I’ve been told horror stories about support. Examples like the vendor sending the hardware schematic with a note saying “Here you go, debug it yourself”, users unable to get support as the one support engineer at the vendor was on vacation as well as cases of hardware failure and the vendor responding, “buy another one then”.

Don’t fall into the trap of discounting the value of support. IMO it could be the single most important value a vendor provides. Do you have any good or bad support horror stories? I would love to hear about them.

Off topic, did you know that the pic snippet at the top of the blog comes from a marketing campaign that I ran many, many years ago announcing the availability of the Synopsys SmartModel (verification IP’s) ported to the Windows NT platform (yes that old). Below is a picture of the complete poster promotion (yes that’s me in the reflection)

As part of the promotion we mailed (snail mail, remember that) these posters along with a T-Shirt out to over 2000 customer contacts. The Synopsys marketing director at the time thought we were crazy and that the T-Shairt was one of the ugliest he had ever seen… but he still let us do it.

Well he was right, these were the ugliest T-Shirts even our customers had ever seen and the funny thing is that rather than throwing them away or using them to clean the car the customers took the time to send them back to Synopsys. Many of them arrived back with notes stating the fact that the T-Shirts were ugly. This was a huge success, customers took notice of the promotional material sent, can’t ask for more than that in marketing.

Also, look what turned up in my office

Someone read my blog and made their own Foldify creation. This creation was to celebrate 10 years of Synopsys acquiring Accelerant Networks. Nice job!

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

Posted in Man Hours Savings, Milestones, Project management, Support | Comments Off

PCIe Gen 3 = 8Gb/s – Prototyping and Protocol expertise

Posted by Michael Posner on May 2nd, 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

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

Posted in ASIC Verification, FPGA-Based Prototyping, IP Validation, System Validation, Technical, Use Modes | Comments Off

Synopsys’ New ProtoCompiler Software Speeds Time to Prototype

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

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

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

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 | Comments Off

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 | Comments Off

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 | Comments Off