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?

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

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?

One of the “Breaking The Three Laws” is that your SoC partitioned blocks typically have more signals than physical IO’s on the FPGA. Technically this is not one of the three laws but it should have been and as I own this blog I can make one more up. Welcome to the Breaking The Four Laws blog. During a recent engagement for the HAPS-70 the user wanted Synopsys to create a demonstration proving the HAPS High Speed Time Domain Multiplexing, HSTDM and Certify tool automation capabilities. The challenge; Create a design which passed 1800 signals between four FPGA’s using less than 200 physical IO’s.

As you can see from the block diagram above the 1800 signals would be passed between FPGA’s and compared at each point proving that the transmission and receive of data was valid. This was an easy design to replicate for Synopsys as we create similar designs to qualify the HSTDM operation. Based on the users constrains we were able to achieve the following results

• System: HAPS-70 S48 (-1 speed grade)
• #Signals multiplexed per set: 1824
• HT3 connectors used for signal set: 4 (200 IO’s, 96 differential pairs)
• HSTDM Ratio: 24
• HSTDM Frequency: 1.1 Gb/s
• Resulting System Frequency: 17 MHz

We successfully implemented four fully independent HSTDM channels between four FPGAs, Multiplexing 1824 design signals across four HapsTrak 3 connectors. The user required the use of only four HT3 connectors this results in 96 differential pairs available for HSTDM. Based on the requirement of transferring 1800+ signals this results in a required HSDTM ratio of 1824/96 = 19. HSTDM supports multiples of 8 so a ratio of 24 was used. As stated, using a HSTDM factor of 24, we achieved a design system clock frequency of 17MHz.  HSTDM transfer clock rate is 1.1 Gb/Sec and this is fully operational on the -1 speed grade HAPS-70 S48 system. Due to the use of the HSTDM ratio of 24 we have un-used HSTDM channels in the current implementation which could be used for other purposes if needed.

But wait !!!!!        The HAPS-70 systems has far more available IO and the rule of thumb is the lower the mux ratio the higher the overall system performance. Each HAPS-70 FPGA-module has 23-user HapsTrak3 connector available, if we were to increase the number of connectors and cables used by 1, so a total of 5 HT3 connectors for this (1800-IOs) data exchange, we still have 18 more connectors available.

Our recommendation was that by simply increasing the number of HT3 connectors used per link will result in far higher system frequency. By using one more HT3 connector, so a total of 5 per link, the HSTDM ratio will be reduced to 16. So we implemented it and below are the results

You can also see that we also proved that by using more HT3 links that the mux ratio could be reduced even more, down to 8 resulting in a system frequency of over 24 MHz.

This example shows the advantage of the flexible interconnect of the HAPS-70 systems combined with the HAPS HSTDM technology with the result being one very happy user. For those of you doing FPGA-Based prototyping, are you able to get similar results?

This week I’m visiting one of our R&D teams based in Erfurt Germany. I took the opportunity to take some photos of the HAPS-70 development systems along with a number of the off-the-shelf daughter boards which are available from Synopsys as part of the solution.

First let me introduce Andreas Jahn, R&D Manager pictured above with the HAPS-70 S48 (far left), HAPS-70 S24 (right bottom) and the HAPS-70 S12 (right top).Note that the HAPS-70 S12 is connected to the Universal Multi-Resource Bus, UMRBus, by the blue Control and Data Exchange cable. The UMRBus enables the system to be access remotely. This is a key capability enabling global accessibility which is important to Synopsys as we have both local teams and remote teams working with the development systems. Just like Synopsys, many customers have globally located teams handling all sorts of tasks such as hardware validation and software development. The UMRBus enables the HAPS systems to be globally accessed meaning that locally based hardware is not required.

Below is a picture of one of the HAPS-70 S48 systems in use for SRAM daughter board testing. The SRAM daughter boards are located on the left side of the system, multiple are installed and a number are stacked up on top of each other.

Tests were being executed against these SRAM boards, again, all controlled via the UMRBus. The Identify team were using these SRAM daughter boards to continue development of the HAPS Deep Trace Debug, HDTD, capability.  HDTD provides off chip storage for debug sample data meaning that you are not reliant on FPGA devices on-chip memory. HDTD enables a large window, 100x or more when compared to on-chip memory, of debug data to be stored. On the same system you can see that many links have been configure with the high performance coax cables. This system was setup to mimic a customer design and their expected interconnect between the FPGA’s. This was setup to prove that many thousands of signals could be passed across a very low number of physical interconnect IO’s utilizing the HAPS High Speed Time Domain Multiplexing, HSTDM. As HSTDM is automated as part of Certify it was easy to setup a design and validate the HSTDM operation for this specific example.

Finally above is a zoomed in picture of the Multi-Gigabit, MGB, riser and adapters for both PCI Express and SATA. The HAPS-70 enables direct access to the Xilinx devices native transceivers. As part of the solution Synopsys offers a set off-the-shelf MGB daughter boards which link the transceivers to a standard connector. Nice view of the user panel which houses the SD Card which is used for standalone boot configuration. This mode is liked by the software developers as they can quickly load the new build images from their hardware team. Just load the SD card and plug it into the system.

If you spot anything else in the pictures that you want to know about ask the question via the comments