Breaking The Three Laws

 

“ . . . and some have prototyping thrust upon them”

It was the eminently quotable William Shakespeare who wrote some are born great, some achieve greatness and some have greatness thrust upon them.” The quote comes from Twelfth Night, by the way.

Do we find ourselves performing FPGA-based prototyping in the same way? Do some of us run prototyping projects which are born to succeed, or do we achieve success only by a lot of hard work and valuable time. Worse still, do we have a prototyping thrust upon us late in an SoC project and with no preparation so that we are almost destined to fail?

Most of us know the expression “By failing to prepare, we are preparing to fail” (that one is Benjamin Franklin – oh, come on! How many blogs feature both Shakespeare AND Franklin?!).

FPGA-based prototyping projects require good preparation, and the best time to do that is right at the start of the SoC project. We need to assess the design flow and the design itself as early as possible and foresee challenges for the prototypers. We can then make changes or mitigating actions in order to save effort and time when it comes to prototyping.

Another important early preparation is to pre-empt the needs for FPGA hardware and debug tools. We also need to audit any pre-existing RTL or IP for portability to FPGA or external test hardware. In that way, when is RTL mature enough to prototype (see earlier blog post)) we don’t have any nasty surprises.

One valuable result of such early dialog is the adoption of standard wrappers for target-specific elements, such as our memory example above. As seen in the diagram, the implementation, be it on-silicon, on-board or in-FPGA, can be deferred by using a wrapper.

(btw, much more detail on wrappers will be given by my colleague Peter Calabrese and I during a tutorial at the Boston SNUG in September – please pardon the blatant plug).

As for a project, so for the engineer.

I’ve met a lot of successful prototypers, and hope to meet many more. A common characteristic of the successful prototyper is the mutual trust and respect between them and the rest of the SoC team. An SoC team that consults with the prototypers early and often will reap many rewards; that’s what we call Design-for-Prototyping around here.

SoC teams that adopt a “how hard can it be, really?” attitude to prototyping may have been reading the wrong marketing brochure; prototyping really is not push-button (unless you only want to run nearly as slow as an emulator). SoC teams that chuck the RTL over the wall and hope that it lands FPGA-side-up are doing the whole project (including themselves) a great disservice.

What are the other characteristics of the successful prototyper? FPGA expertise is a basic requirement, of course, but what extra layer of knowledge is required on top of that base, and how do we obtain that knowledge?

Mostly we learn attending tool training sessions; by asking our colleagues and tool vendor’s support people; by using our own inspiration and by a great deal of trial and error. We wrote the FPMM book (free download from www.synopsys.com/fpmm ) partly in an effort to short-circuit some of that trial and error and give folks a head start in prototyping. However, that is only the start. Another major aim of the FPMM project is to allow prototypers to assist each other in the wider industry; providing another source for prototyping best practices beyond colleagues and vendors.

It’s been a slow start and I don’t see very much traffic on any of the online sites related to FPGA-based Prototyping, including our own FPMM forums. So, here’s an idea; let’s get together with our fellow prototypers in groups around the world, to share solutions and achieve an overall higher level of knowledge and productivity. I think that idea has legs, watch this space.

Be prepared and don’t just have prototyping thrust upon you.

Doug – Summer Solstice 2011

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