Archive for the 'FPGA-Based Prototyping' 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 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.

I used to own a Ford F350 truck and it was huge with the long wheel base, full bed, extended crew cab measuring a length of about 25 feet (8 meters). The problem was that it came installed with a cloak of invisibility. I didn’t know it had a cloak of invisibility when I purchased but soon after while driving it down the freeway (motorway) a small car merged into the side of me. Unsurprisingly I won that battle and when I asked the other driver how it happened they responded “I didn’t see you”. Wait a second my truck is 25 feet long and that day I was towing a 25 feet long fully enclosed car hauler meaning I was over 50 feet long. How do you not see that…….. That’s when I realized that this truck came with the unadvertised cloak of invisibility option.

So what has this got to do with Jim Hogan you all ask….. well read on and find out.

The cloak of invisibility must be an undocumented feature of the HAPS product line as Jim Hogan wrote a complete article on emulation with mention of prototyping and managed not to mention HAPS once (well ok, once but that was in a table and that was the only mention). I should state that I do not know Jim personally and hold nothing against him. Jim’s article was pretty good but I am afraid I have to personally doubt the credibility of the data when the highest quality and most well-known FPGA-Based Prototyping product, HAPS, didn’t get a proper mention. Jim what were you thinking!!!!  Jim’s article focused on emulation but draws reference to FPGA-Based prototyping a number of times which is why I think HAPS should have been included in the article.

I have to believe that this omission was due to the undocumented HAPS cloak of invisibility. Jim; contact me and let’s solve this mystery.

What also got me all riled up was the following;

• All FPGA-based solutions are “Emulators”

Not so! Jim included FPGA-based prototypes in the discussion – referring to them as “low-capacity emulators” (and never mentioned HAPS). Emulators focus on Verification providing a high level of automation and debug.  FPGA-based prototypes focus on Validation providing the high performance needed for software development and system validation with real world IO. I’ve blogged about the differences in the past (here).  Below is a recap of that incredible blog with simple graphics

I love the above analogy. You own both but depending on the task at hand you pick the right tool for the job.

The following simplifies the difference between Verification and Validation. While they both start with the letter V the goals are very difference which is why both emulation and prototyping play an important part of an SoC’s development.

Oh, I should also apologize for being tardy on my blog post this time around. I’ve been traveling a lot and when weighing up either writing a blog or sleeping, sleep always won.

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

Over coffee this morning I found myself thinking about virtual prototyping. Blasphemy you say, Mick is hard core FPGA-based prototyping and he would fight till the death and his cold lifeless body was rotting on the battlefield. (Yes, this blog is 18+ Rated today). The reality is that virtual prototypes, such as Virtualizer, are complementary to FPGA-Based prototyping.  

Virtual prototypes are not reliant on the availability of RTL so can be used far, far, far earlier in the design cycle. Much software is independent of physical implementation so you get a huge advantage from developing a virtual prototype enabling software development to start early. Because you model the system at a higher level of abstraction you get high performance as well.

On the flip side, virtual prototypes don’t use the physical RTL so it’s only a close representation of the target system, not the system itself. This is the value of FPGA-based prototypes, such as HAPS, they utilize as much of the actual RTL as humanly possible. The FPGA-based prototype is as close as you can get to the real system. Some say (incorrectly) that partitioning and pin multiplexing adds a level of complexity and error. The fact is with new automated techniques offered by tools like Synopsys’ Certify the partitioning and insertion of pin multiplexing logic is transparent to the user and error free.

Then sitting in the middle is Hybrid Prototyping, merging the best attributes of both technologies.

Both technologies play a critical part of the design cycle.

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.

Don’t forget SNUG SJC

http://www.synopsys.com/Community/SNUG/Silicon%20Valley/pages/default.aspx

Mingle with over 2500 over engineers just like you (But of course you are the best)

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?