Archive for the 'Getting Started' Category

Follow up from last week’s blog…… http://blogs.synopsys.com/breakingthethreelaws/2013/05/high-speed-io-and-the-cloak-of-invisibility-strikes-again/

Kirk Saban of Xilinx answered my question of why the line rate of the -2 2000T silicon is 10.3125. Kirk states:

10.3125 Gb/s is the line rate required to support 10 Gb Ethernet which requires 64b/66b encoding. (10Gb x 66)/64 = 10.3125 Gb

I would have been surprised if Kirk got this wrong as he is the Product Manager for the V7 FPGA’s. Kirk then goes on to challenge us with a follow question:

I will follow up my answer with an additional question… what speed grade of 7V2000T is required to support 12.5 Gbps!?

You would have thought the answer is the “-3 part” but you would be wrong as there isn’t a -3 part. The correct answer is the -2G part. I found the following text in one of the Xilinx datasheets which confirms the -2G part

Thanks to Kirk for answer the question and enlightening us on the -2G part. For this honor Kirk gets to buy me dinner and drinks the next time I’m in CA.

USB is everywhere; even my fridge has a USB port. Last week I asked a non-tech-savvy person if they knew what USB actually stood for. They didn’t know, they just knew that it’s everywhere and mostly works out of the box. (Universal Serial Bus for the non-tech-savvy readers). While USB is everywhere it still presents a challenge to FPGA-based prototypers as the various interfaces have minimum frequency requirements and timing constraints between RTL controller and mixed signal PHY. I ran across a great write up by John Kuhns, Design Consultant, Synopsys Professional Services, in this month’s DesignWare Technical Bulletin, http://www.synopsys.com/Company/Publications/DWTB/Pages/default.aspx

Here is a link directly to the article: http://www.synopsys.com/Company/Publications/DWTB/Pages/dwtb-usb-prototyping-2013Q2.aspx

John provides insight on how to get your HAPS-based prototype up and running in a short period of time by taking advantage of solutions such as a implementing a simple USB device driver written in C and a WINUSB-based host driver to facilitate testing. Nice work John!

Coincidently Synopsys just launched the USB University, http://www.synopsys.com/IP/Pages/usb-university.aspx If you are new to designing with USB, or looking for tips on implementing USB 3.0 IP, Synopsys’ USB 3.0 University has a session for you. From a basic USB overview, to implementing USB on FPGAs, to top-level synthesis, you’ll find the information you need in this instructional video series.

Off subject does anyone know which year Pacman the video game was launched?

Last week I discussed the occurrences of the cloak of invisibility in respect to my black truck and trailer as well as HAPS. Well fate was unhappy with me exposing the truth about the existence of the cloak of invisibility and sent me a message

Yes, last week someone drove into my car hauling fully enclosed trailer. Ouch. No one was injured but I was spooked by what the other drive said when I asked what happened, their response

I didn’t see you

Come on now, it’s a 25 foot long fully enclosed trailer that blocks out the sun. Maybe that’s the issue, maybe it’s really a black hole in disguise and the other driver was sucked into it !!!!

Last week I was asked if the Xilinx transceivers, the high speed serdes capable pins, were available on the HAPS-70. The answer is yes, we make 16 lanes of the transceivers available per FPGA across two multi-gigabit (MGB) connectors. The MGB is a generic connector meaning that the user of the HAPS system can either use an off-the-shelf MGB daughter board from Synopsys or build a custom MGB style daughter board to access the transceivers. Synopsys provides off-the-shelf MGB daughter boards for PCI E, SATA and Ethernet. The transceivers support a wide range of different protocols.

Here is an example of the Synopsys PCI MGB daughter board

Here is an example of the MGB access riser. A user would build a MGB daughter board to either plug into this of bypass it and go straight into the MGB connector itself.

Different from the previous “T” Xilinx FPGA variants the Virtex-7 2000T’s speed grade changes the max speed of the transceivers. The -1 part supports up to 6.6 Gb/s while the -2 part supports up to 10.3125 Gb/s. Does anyone know why it’s 10.3125 Gb/s? I do but if you know the answer make a comment below and I’ll ensure you are written up as a star in my next blog.

Last week I wrote almost nothing about FPGA-Based Prototyping because I was off in the weeds talking about painting fish and my Subaru building and racing hobby (Some says it’s an obsession, not a hobby). I got so many complements on my blog, thanks! This week it’s back to your normally scheduled programming. I was planning a short blog posting this week but then I got carried away and now I find this post really long. Stick it out and read the whole thing it’s full of useful tips.

I was challenged this week to explain why HAPS systems don’t have DDR memory hard wired directly on the FPGA but rather support them via a daughter board. The assertion from the person (they work at Synopsys) was that you couldn’t support the DDR3 speeds via a connector and DDR3 had to be hard wired.

First of all, this person obviously does not read my blog otherwise they would have read me UFC Cables vs. PCB Traces blog a while back: http://blogs.synopsys.com/breakingthethreelaws/2013/03/ufc-cables-vs-pcb-traces/ It includes information on the high speed HapsTrak 3 connectors. Just from this post they should have worked out that the Hapstrak connectors has the performance capable of supporting DDR3 interface speed. Another give away that DDR across a connector on a daughter board is not a problem is that we supported DDR2 on the classic HAPS-50 systems and support DDR3-800 (400MHz interface) on the HAPS-60 system.

With the HAPS-70 systems and the move to the new Hapstrak 3 connector we raised the bar again and support DDR3-1066 (533Mhz interface) and have even been testing at DDR3-1333 (666 MHz interface).

So you say argument done, Mick wins, case closed…….. NO. Challenge me and prepare to go down. Now it’s my turn, I’m on a mission to show that not only does HAPS support DDR3 but because of the flexible daughter board implementation that the prototypers get additional value. Some people would call this the double punch, I like to call it the punch while holding a brick (yay, finally I tie the title of this blog into the post).

The brick held punch; Simply put, if you hard wire DDR3 or any interface to the FPGA of a prototype you are reducing your IO count available for interconnect or other daughter boards. If you read my post on interconnect flexibility and signal mux ratio: http://blogs.synopsys.com/breakingthethreelaws/2013/02/how-io-interconnect-flexibility-and-signal-mux-ratios-affect-system-performance/ you understand the importance of available IO. Lets say your design does not use DDR3 memory, with a board that has DDR hard wired those IO’s are wasted, you are not using the DDR but you can’t use the IOs because they are hard wired. On the HAPS system if you are not using the DDR you have no wasted IO.

If you are using DDR memory you might think that at that point a solution with hard wired DDR and the HAPS flexible solution are the same. If you thought this you would be mistaken. With a hard wired solution you are forced to place your memory controller in the SLR where the DDR3 is hard wire connected. This pretty much ties your implementation hands which could also force a sub-optimal interconnect topology. With the HAPS system you are free to move the DDR between any of the Xilinx Virtex-7 2000T’s SLR’s. Way more flexible and you get to choose the best location for the memory controller which makes sense to your system. Of course you should always bank and SLR match as that’s the requirement of the FPGA and DDR operation.

So at this point I have proved that DDR on a daughter board is possible, you don’t waste IO’s and the additional flexibility of placement results in a prototype implementation optimized to your design requirements. But I’m not finished…… (I know, I bet you were wishing I was)

Lets look at a block diagram of a typical prototyping board. This board has one DDR3 SODIMM connectors hard wired per FPGA. Tell me, how many SoC’s have you seen with multiple DDR controllers? None, that’s how many I’ve seen.

You are forced to implement your DDR controller in one of the FPGA’s and then you have 372 wasted IO’s.

Now look at the HAPS-70 S48 with the memory controller implemented. NO WASTED IO. If for some crazy reason you did want to implement four (or more) DDR controllers on the HAPS-70 S48 you can do that and you still have the flexibility to implement those where you want to. Just plug in a DDR daughter board.

Now that’s what I call the brick held punch! Anyone else want to challenge me

Following up from last week’s blog I was asked what I thought were the main technical selection criteria for an FPGA-based prototyping platform. I thought hard and long (~5 seconds) and said Capacity, Performance and Ease of use. The reasoning behind capacity being #1 is that you need a platform that has sufficient capacity to cater for your current project requirements including catering for design size growth over the course of the project. You then also want to select a platform that can be reused across multiple projects increasing your return on investment. If the platform does not provide sufficient capacity for the design then you don’t leave the starting gate.

Performance is #2 as it’s the key requirement for running software. Actually I remember saying Performance, Performance, Performance as it’s so important to the software team. I always laugh when talking to software teams, their request is that the prototype platform runs as fast as the actual target product and they see anything slower as a compromise. They also complain if the coffee pot is empty but will they start a fresh one?

Finally ease of use; while you must have a platform that delivers the maximum performance you also want it to be easy to use. Ease of use means many things including ease of the implementation flow, ease of bring up, ease of partitioning, ease of debug and the list goes on.

Then I thought to myself, the FPMM survey asks this question so I looked at the data and below is the results.

Did I nail it or what! Ok, “or what” would be the answer as I did not consider the business trade-off that companies have to make. The result of this is that cost comes in as the #3 priority of selection criteria. I can regain my credibility by saying that the question was what the main technical selection criteria were. Yay, I’m right, if you had the funding then the technical selection criteria is Capacity, Performance, Ease of use.

Flexibility and Expandable shows that users look for a platform that not only meets the need of their current project but can be reused across multiple projects.

Are your selection criteria different from this?

Wow, the free ebook download of the FPGA-based Prototyping Methodology Manual has surpassed 3500 downloads. The PDF version has been downloaded over 2800 times in addition to the Epub and Kindle version at over 500 times each.

We have collected over 2800 surveys from the users who requested the download. As expected the #1 downloader of the FPMM is hardware engineers. These engineers are living and breathing FPGA-based prototyping so get immediate value from the FPMM’s guidance.

Based on this survey data the top challenges these engineers face still fall into the categories of ease of use, debug and performance. In the below data you can see mapping the ASIC into FPGA and clocking issues as the #1 and #2 challenges. Both of these are in the category of ease of use challenges and these barriers need to be crossed before you can get an operational FPGA-based prototype and become productive. This is where the Synopsys Certify multi-FPGA prototyping environment helps. Certify automates many of the steps needed to condition ASIC RTL ready for the FPGA-Based Prototype. For rapid bring up, Certify is configured to provide fast turn-around enabling multiple iterations per day as you experiment with implementations.

It’s logical that once you have an operational prototype that the key need becomes debug visibility. The engineers need to debug the initial bring-up of the prototype and function. The Synopsys Identify tool helps here by providing various debug capabilities for system validation and fast turn-around with deep trace storage debug visibility.

Once you have a good stable FPGA-based prototype it’s time for deployment for System Validation and software development. This is why the focus then changes to performance. You know that your software team won’t tolerate waiting around 5 seconds for an OS to boot. Now is the time to configure Certify for full optimization and squeeze the most out of both the FPGA technology and the FPGA-Based Prototype.

Do you agree with these challenges or do you face others? Post a comment and let me know. Oh and sorry for the delay in blogging, I’ve been traveling the world again.

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 at speeds well in excess of what is typically seen on an FPGA-based prototype.

Of course designers have been using PCB traces for years and like my late grandfather they are very stubborn. Unless you provide them the raw data which proves the assertion they never change their minds on what they perceive as the best solution. This blog is designed to provide the data to let a designer make up their own mind on the effect of a cable vs. PCB direct trace based interconnect architecture. Warning, it gets pretty technical from here on…….

There are two influences of FPGA-Based Prototyping performance that must be discussed separately. One is signal quality and data rate, which affects the transmission speed of signals over a High Speed Time Domain-Multiplexed link. The other is latency, which affects globally synchronous performance.

First signal quality:
All PCB traces suffer from crosstalk. Crosstalk can be reduced by routing all traces as micro-strips with lots of space around each trace, and surrounding GND planes on both sides of a signal (A GND-sig-GND stack). The other problem with PCB traces is attenuation. It can be countered by using wider traces, which takes more room and also imposes even larger spacing between traces to keep the crosstalk down. The sheer number of signals in an FPGA packages prevents a designer from using such technologies for the bulk of the signal routing. To reduce the number of planes in the PCB, it’s possible to use GND-sig-sig-GND stacks, which will introduce crosstalk between signals on adjacent layers. This is unavoidable if you want to route more than a hundred or so signals between FPGAs on a reasonable PCB.

The cables Synopsys uses are high performance ribbon coax cables. They have excellent performance data (see above), with superior characteristics in terms of crosstalk and signal velocity (length of signal path versus latency). There is no question about this, the raw data cannot be argued. Our HapsTrak 3 connectors add some impedance discontinuities and very little crosstalk. So wide on-board micro-strip traces without connectors could have performance on par with the cable, but without the flexibility. (Fixed direct connects can’t be tailored to your design partition). Also, there would likely be much fewer such high performance traces than cable traces, due to PCB constraints mentioned earlier.

Even so, measurements and simulations show that our connector-cable combo will in outperform the FPGA anyway, so direct PCB routes won’t pay off in significantly higher data rates, because the FPGA sets a hard upper limit.

Now latency:
Our 25 and 50 cm cables have latencies of around 1400ps and 2500ps. Add this to the trace lengths on the FPGA Modules, which are around 1500ps (between FPGA and connector). This gives about 4-5ns of trace delay between FPGAs. In comparison, you could perhaps make at least some direct PCB traces that are 2ns long (optimistically), shaving 3ns off the trace length.

But the total clock cycle time is not only constrained by the trace length:

• Clock skew and uncertainty is ~1ns.
  Clock-to-out of the FPGA is at least 2.5ns.
  Setup time is ~1ns.
• So the absolute minimum clock cycle time is:
  • 5+1+2.5+1 ns = 9.5 using cables (realistically)
    2+1+2.5+1 ns = 6.5ns using traces (optimistically).

The difference could still seem significant at a first glance, but hold on, there’s more:
The calculation requires all FPGAs have flip flops on the edges, which implies that all partitioning cuts are made between pairs of flip flops in the design (unrealistic). It also assumes that signal multiplexing isn’t needed. Say that signal multiplexing isn’t needed, but add an optimistic 10 ns of worst-case user logic path to the equations, and you get 19.5 for cables vs. 16.5 for PCB traces. The difference isn’t that big anymore. And for less optimistic user logic timing, the difference will be even smaller.

If you use globally synchronous multiplexing of signals (traditional signal multiplexing), the additional latency will affect the mux’ing frequency and will eventually kill performance. But if instead use the Synopsys HAPS HSTDM, the mux’ing frequency will be decided by the max data rate, where the cable excels, and you will get much more capacity out of the interconnect at a given system frequency.

Proof, there is no “order of magnitude difference” in performance, signal quality or latency between cables and PCB traces. PCB Traces as we know are good and cables provide the higher flexibility that FPGA-based prototypes need in order to be customized to specific design requirements.

UFC Cables Vs. PCB Traces Winner: Synopsys High Performance Coax Cables

So, anyone like to challenge this data?

One of my motto’s is “never let good whiteboard art go to waste” which prompted this blog posting. I should note that I am well known for my graphical skills, actually my lack of color matching skills has resulted in eyes burning and people running from my presentations screaming. (Honest, no joke!)

A couple of weeks back I posted how you created a bussed connection with the HAPS-70, http://blogs.synopsys.com/breakingthethreelaws/2013/02/direct-route-or-take-the-bus/ This method is very flexible as you can create a bussed chain to as many FPGA’s as you like and as wide as you like. I recently drew a representation of what this would look like across 12 FPGA’s or three HAPS-70 S48 systems. (Click pic to see full sized image)

This represents a bus of 48 bits as it’s utilizing one cable connection. To create a wider bus just replicate the connections across multiple HT3 connectors. See what I mean, super flexible. Also, this is one of my better whiteboard arts, I even cleaned off the whiteboard before I drew it.

Last week I also managed to upset Neil Songcuan, PMM for HAPS as I posted a link to Angela’s web seminar and not his. Neil presents a full introduction to the HAPS-70 solution covering the following topics. (Click pic to see full size image)

Neil’s web seminar recording can be found by following this link: https://event.on24.com/eventRegistration/prereg/register.jsp?eventid=557195&sessionid=1&key=8030E1505D0294AACFFB3843118D09E8&cmp=WEBR-fpga100203-HPW

Cheers !

This week, I have mostly been eating sushi.

Did you notice my blog title rhymed, SNUG and FPGA Debug, I thought that was pretty catchy.

 Alert, SNUG Silicon Valley is approaching fast, March 25^th – 27^th. http://www.synopsys.com/Community/SNUG/Silicon%20Valley/pages/default.aspx I’m personally not going to be able to make it down this year so I need you, my readers, to attend and then tell me all about it. There is a dedicated FPGA-based prototyping track and an FPGA implementation track.

 FPGA-Based Prototyping Track Highlights

• FPGA-Based Prototyping: My BFF FPGA-Based Prototyping Solution: Better, Faster, and Flexible
• Bring-up and Debug of FPGA-based prototypes: Pest Control, Hunt Down Bugs Like the Experts
• Hybrid Prototyping 101

 FPGA Track Highlights

• Designing with Xilinx 7 Series FPGAs: The Essentials for an Integrated Synplify-Vivado Design Flow Targeting Xilinx 7 Series FPGAs
• Maximizing Productivity on Large FPGA Designs: Methodologies and Techniques for Maximizing Productivity on Large FPGA Designs
• Synthesis Methods for FPGA-Based Prototyping

While I’m unable to go to the SNUG Silicon Valley event I’m planning on making a special appearance at SNUG UK.

On another note, did you miss the recent live web seminar on “10 ways to debug your FPGA design”? Well if you did don’t worry, the recorded version is available here: https://event.on24.com/eventRegistration/prereg/register.jsp?eventid=579541&sessionid=1&key=1319D5CFF949C3FDAA3F860D951BE1F1&cmp=WEBR-fpga100204-HPW I highly recommend it and it’s presented by Angela Sutton who is an expert in the field.

Yummy sushi picture just for fun.

I’m working on a deep technical blog posting for next week. Well when I say working on I really mean I’ve got an idea for one I just need to formulate my thoughts. Lets see if I can wrangle them by next week.

Over the last couple of weeks I’ve been chatting about the various capabilities of the HAPS-70 solution and how it directly improves the FPGA-based prototyping experience. Now have a look at the system hardware and software in this short video introduction to the HAPS-70.

http://www.youtube.com/watch?v=Iagwzdsgtm8

I’ve also blogged a lot about the HAPS-70 S48, our 48 million ASIC gate solution but not much on our smaller S12 and S24, 12 million and 24 million ASIC gate solutions. The S12 and S24 utilize the same modular and flexible architecture, UMRBus capabilities, supervisor software and software tool flow chain.

If we look at the S24, above, I’ll remind you that there are no embedded traces between the FPGA’s. This is a huge advantage for the S24 as the typical use case for such a system is a processor subsystem in one FPGA and the DUT subsystem in the other FPGA. With such a setup many signals need to be past between the FPGAs and this is of course where the flexible interconnect architectures strength is. An example of this is say we have a setup that requires ~300 IOs for daughter boards, which is six HT3 connectors, the remaining 17 are free to use for inter-FPGA connections, that’s 816 (17 * 48) raw IO’s. On its own that’s a tonne (I’m working in metric today) of signals. Now factor in the use of HSTDM at say a ratio of 8 and you can support 6528 ( 816 * mux ratio of 8 ) signals between FPGA’s. That’s HUGE.

In other cases the prototyping design is external IO intensive but the actual DUT is pretty small compared to a complete SoC project, enter the HAPS-70 S12. The S12 includes 23 HT3 connectors providing the maximum IO available for daughter boards, external IO and connectivity to other systems. Picture a small subsystem being modeled, the S12’s IO can support the use of multiple daughter boards such as SRAM, DDR3, Flash, UART, custom application specific daughter boards, DesignWare PHY test chip boards and more. All these plus a connection to Ethernet, SATA or PCI Express via the available MGB connector accessing the on-FPGA transceivers.  Oh and lets not forget that you can still utilize the UMRBus connection with it’s zero pin overhead to monitor and interact with the prototype.

The S12 is also a key building block for the “cloud” systems. Buzz word alert !!! The HAPS-70 systems can be chained to create higher capacity systems. The chaining is done utilizing a simple supplied cable we call the CDE, Command and Data Exchange cable. This chains configuration and synchronizes clocks so that while physically you are linking multiple systems the cloud of systems acts and is seen as one unified prototyping project. Partition the design across the multiple FPGA’s just like they were all in one unit. Below are the form factor cheat sheets describing the base systems as well as the cloud systems. I should note that the S144, 144 million ASIC gate system is missing just because I could not fit it all nicely into one page.

Funny, I had originally thought I was only going to blog the HAPS-70 introduction video… wow I got wordy this morning…. Oh, ate chicken salad at the Hilton Garden hotel in Mountain View CA, very nice J

I snapped off the picture of the HAPS-70 system below at a recent customer meeting and it gave me the idea for this blog. Other than the fact that the systems look “well sexy” (Yes, usually a term you do not hear used to describe hardware) this picture also highlights the flexible nature of the system interconnect architecture with the high performance coax cables and recommended usage.

The two rows of Hapstrak 3 (HT 3) connectors down the center of the systems have been used for inter-FPGA interconnection. Utilizing these connectors minimizes the cable lengths. As the interconnect architecture provides bank, super logic region and connector 1:1 mapped all trace & delay length matched, timing closure is simplified. It also keeps the systems looking neat and tidy.

The external connectors are used for mounting of daughter boards or for interconnections between multiple systems. This is the recommended way to utilize the highly flexible interconnect architecture of the HAPS-70 systems

Happy Holidays, this is my last blog post for the year. If you have suggestions for Blog Topics for 2013, send me a note with the suggestion