Archive for the 'Tips and Traps' Category

I’ve talked about the Hapstrak 3 connectors a number of times but I don’t think I have directly compared the Hapstrak 2 with the newer HapsTrak 3. A little history, Haptrak 2 was backwards compatible with the original Haptrak 1 but the new Hapstrak 3 took a leap forward to provide greater performance and interconnect flexibility.

The HapsTrak specification and the right to purchase Hapstrack connectors is open to all HAPS system users enabling them to quickly build custom daughter boards tailoring the HAPS systems to their desired function. The Hapstrak specification and connector design was developed by Synopsys specifically for use with the HAPS systems.

This is the picture of the original Hapstrak 1 connectors mounted on the HAPS-50 systems

This is a picture of the Hapstrak 2 connectors (with pcb riser) mounted on the HAPS-60 systems

Finally a picture of the Hapstrak 3 connectors mounted on the new HAPS-70 systems

The Hapstrak 3 connector is an off the shelf connector with a customized pin out to meet the specific requirements of FPGA-Based Prototyping. If you are a HAPS user then Synopsys is happy to provide you the Hapstrak specification. We also provide a complementary review service for HAPS customers designing their own daughter boards. This courtesy service includes a review of the form factor, design of HAPS specific capabilities and general checking of PCB design for high performance.

As a reminder the Hapstrak connectors mounted on the HAPS-70 systems are bank and Xilinx Super Logic Region (SLR) matched enabling high performance from the daughter board to the Xilinx part or interconnect flexibility when connecting multiple FPGA’s. Hapstrak 2 was 119 IO’s per connector while Hapstrak 3 is 50 IO’s per connector, higher granularity means less IO waste. The new Hapstrak 3 has over double the performance of the previous connector making it easy to interface at high speed to daughter boards and other connectors via the HAPS interconnect intelligent cables.

Let me know if you want more information on Hapstrak or anything HAPS based.

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 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?

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.

Last week’s blog was on direct interconnect density and the effect it has on pin mux ratios. The example focused on using HSTDM but one of the readers correctly pointed out that interconnect density effects any pin muxing scheme, not only HSTDM. The rule of thumb is the greater the density of interconnect routes the lower the possible mux ratio can be. This is a HAPS-70 hardware strength as the interconnect can be tailored to create greater route density just where you need it.

So that’s direct interconnect routes but what about busses? Take a typical SoC as below

The SoC infrastructure defines a logical partition which could be mirrored on the FPGA-based prototype. In its simplest form you would assign each block to an FPGA and mirror the interconnect. The HAPS-70 flexible interconnect architecture again enables you to tailor the system to match the SoC specific interconnect. Of course in reality you would combine multiple blocks into each FPGA. Regardless there are occasions where busses (sometimes known as multi-drop connections) are required.

When first looking at the HAPS-70 the conclusion could be drawn that all connections are point to point and that busses are not supported……… Well of course that conclusion would be wrong. Enter the breakout board !

The breakout board plugs into the HAPS-70 system HT3 connector and connects that single HT3  to two HT3 sockets. Basically it creates a “Y” connection. This simple concept enables a bus to be routed around as many FPGA’s as you like. The example below shows how you create a bus of 48 IOs across four FPGA’s. (Bought to you via my amazing whiteboard skills)

It’s easy to see that with the use of a third breakout board and high performance coax cable that the bus could be extended to five FPGA’s and so on for more. Creation of a wider bus just requires the use of more breakout boards and cables. The bussed connections have matching timing characteristics due to the fact that the HT3 connectors are 1-1 bank matched with both the Xilinx IO bank and the SLR region of the 2000T device. Uniform timing as you are not crossing banks or SLR’s.

On a random topic I used to eat chicken wings everywhere I travelled to. Over the course of 18 years of business travel I ate spicy wings at almost every dinner. I wish I had written a book about it. Not a boring book rating how good the wings were (or bad) but about the quest itself. I would have called it “Wings around the world” catchy title right! I had a lot of fun on the drives, walks, trains and busses while on the quest for the wing. Well that era is now over, for some strange reason I gained 30 Lbs over the last years. Maybe, just maybe, the wings had something to do with this. Anyway it’s lean chicken and salad from now on. Can anyone make up a catchy title for the book that I won’t write on my new quest for the salad?

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

Traditionally ease of use for FPGA-based prototyping was all about how long it took to go through FPGA synthesis and FPGA place and route. Easy was defined as faster through the flow. With advances in Synopsys’ Certify and Synplify tools adding incremental compilation methods, multi-processing & fast synthesis specifically for FPGA-based prototyping the impact of “bit” file turn-around has been dramatically reduced. With that part of the problem solved the term “ease of use” is now used to represent more than just the implementation tool flow. The ease of use phrase has been extended to include the complete usage flow from first bring up to deployment for HW/SW Integration, System Validation and SW Development.

With the introduction of the HAPS-70 systems Synopsys now offers a new System Query and System Check capability which improve the ease of use of the solution.

The HAPS System Query jump starts the creation of a prototyping project based on a specific physical configuration of the HAPS system. The example being you already sort of know how many systems will be used together, how many and what types of daughter boards are needed and the sort of interconnect topology that is best suited for your design. With the new HAPS Query you can “build” the physical system placing the daughter boards and cables on the system and then via the UMRBus have the HAPS tools build you the prototyping project template based on the physical implementation. This template is then used as part of the Certify multi-FPGA prototyping flow to jump start the activity. Super easy right.

The HAPS System Check is targeted at the deployment stage. I’ve heard so many horror stories of remote teams taking weeks to become productive as they had been debugging a problem which was caused by an incorrectly configured system or incorrectly placed daughter board. No joke, I was told that one team took almost two weeks to bring up a system as no one noticed that a daughter board had been placed on the wrong set of connectors. The engineer was looking at the picture of the system basically upside down.

 The HAPS-70 systems include a System Check capability. The use mode of this capability is to validate the physical connectivity and performance of the system interconnect BEFORE you load your user design. In essence system check is a set of debug capabilities targeted at ensuring the system has been setup according to your project and that everything is operating correctly. If the system passes these checks then you can be assured that you are debugging your design and not the FPGA-based prototype itself. System check will identify where daughter boards are located and check that the voltages have been applied correctly. System check can validate the cable interconnect topology and run a performance check to ensure that all connections are electrically good and meet the requirements defined in the users project. These system check capabilities can be interactively run via a GUI or scripted.

 IMO this makes the systems not only easier to use but assures stability which is essential in a production project environment.