Following on from our intro to wrappers, and the excellent discussion both here and on LinkedIn groups, I’d like to go into more detail on how we can use wrappers for memories.

As a recap, when mapping SoC RAMs into FPGA it is necessary to adapt the RTL so that the FPGA tool flow can map them into the appropriate resource. We can do this without changing the existing RTL, but instead, we add extra RTL files to act as adaptors; we call these wrappers.

Basic concept of a wrapper, showing two memory instances (From FPMM book, page 197)

The diagram form the FPMM (above) shows the basic arrangement, in this case of two wrappers used in the same level of hierarchy. Notice that the SoC physical memory is not instantiated directly into the RTL, thus keeping that RTL clean (i.e. not target-specific). The physical memory for the target, usually a generated memory cell for the SoC, is written into the lowest level of hierarchy only. The logical memory instantiation should be chosen to be as generic and reusable as possible.

A naming convention for the logical memory and its ports could be adopted within a project or even across an entire company. Once such an in-house standard is in place, it is easier for prototypers to have a ready-made FPGA or board-level equivalents to fill the wrappers in place of the physical memory.

If a wrapper is not used, and the target-specific physical memory is placed directly into the SoC’s RTL, then it will appear as a black box in the FPGA flow. The prototypers will still need to fill that black box; only now the top-level boundary of the black-box has the names and ports of whichever target-specific physical memory was instantiated, including BIST ports and all. In those cases it is more difficult to understand exactly what memory function is required and less likely that the prototype team will already have an FPGA-ready version, e4specially is your company uses memory cells fomr different library vendors.

As pointed out in your comments to previous blog postings, a sophisticated approach to swapping the contents of wrappers is to use an IP-XACT description for the wrapper, so we can automate the use of different fillers. A simpler approach is also available in VHDL by the use of Configuration statements, which control the choice between different Architectures for the same Entity. Whichever method is used to control the use of an FPGA or SoC filler for the wrapper, the FPGA version still needs to be created.

I find that the good way to start creating a wrapper is to copy the component/module declaration from the SoC RTL and paste into a new RTL file. This ensures that the boundary of the lower level matches the higher-level instantiation.

Naming can be adopted as standard. for example, in the FPMM workshop labs, we used parameterized memory wrappers with names such as M64X14H1M8S00_wrapper. The M means memory, 64 is the depth in words and 14 is the width of the word, and so forth. Here, we are following the naming scheme used for Synopsys’s own memories (previously Virage logic) but you can adopt any suitable naming style of your own.

We then have to find the equivalent memory for use in the FPGA. The best way to do that (for internal memories) is to let the FPGA synthesis tool infer the memory from an RTL description. An excellent script is available, created by my friend Peter Calabrese, of Synopsys Boston, which parses the wrapper names and creates RTL from which the FPGA tool can infer the necessary rams. If you want to adopt an in-house wrapper scheme, then this might be an easy place to start. Please comment below to email me at fpmm@synopsys.com to let me know what you think.           

Doug

A colleague and I were having a lively argument about the difference between Validation and Verification and it got me thinking. What’s the difference anyway? What do we mean by these terms and do you and I mean the same thing?

Winning the argument seemed pretty important to me at the time, so I did some deep and extensive research (oh, alright, I Googled it) and found the Wikipedia definitions, as follows . . .

• “Verification is a quality control process that is used to evaluate whether a product, service, or system complies with regulations, specifications, or conditions imposed at the start of a development phase.”
• “Validation is a quality assurance process of establishing evidence that provides a high degree of assurance that a product, service, or system accomplishes its intended requirements.”

These definitions appear to say the same thing but if you dig into the semantics there IS a difference. A friend at ARM put it very nicely in a presentation to a DVClub Conference in the UK late last year. He said the difference was highlighted in the two questions . . .

What we infer from the questions are the following. . .

Verification is a matching of results to specification. It is a methodical process of proving something does what you asked for, and nothing else. The specification is taken as golden. The aim; a proof that the design meets the specification.

Validation, on the other hand, is the exercising of the design to check that it is fit for purpose. It is a subjective process of using the design, perhaps in situ, definitely with the embedded software, to see if it does what you need. The specification is NOT golden and in effect is under test along with the design. The aim: a proof that the design AND the specification meet purpose.

So where does FPGA-based Prototyping come in? Well, here’s what you told us. In answer to a question in the FPMM download survey, nearly 2000 users kindly shared the following data about their reasons to use FPGA-based Prototyping. . .

Wait a minute; this says that people use FPGA-based Prototyping to “Verify” the RTL, or to “verify” the hardware and software co-design. So, is FPGA-based Prototyping a verification technology? Clearly, looking at the most popular answer, prototypes do expose RTL bugs that sneak through the normal verification process. How is that possible?

A Safety Net for Verification?

Verification is impacted by the classic speed-accuracy trade-off. We can have high accuracy in an RTL simulator and even go to the gate level, but speed is so far below real-time that some tests simply take too long, even on an accelerator or an emulator. On the other hand, high-level modelling in SystemC and other virtual prototypes gives us much better performance but we no longer have cycle-accurate results. Only FPGA-based Prototyping offers the unique combination of high-speed AND cycle-accuracy, allowing longer and more complex tests to be run on the prototype than in a Simulator, catching otherwise unseen RTL bugs.

So, Is FPGA-based Prototyping a verification technology? No;  It lacks the necessary observability, controllability and determinism required for the objective testing of RTL, however, we could quite rightly consider it as a “safety net” for verification.

Objective vs. Subjective

Because Verification is an objective comparison of results against the specification, there is massive scope for automation, for example as in the UVM and VMM methodologies. Validation, however, is more subjective and so less easy to automate, relying more on the expertise of the prototypers themselves. Prototypers need to see the system running, in the real environment actually performing the task for which the specification was created. We may also choose to exercise the design outside of the specification’s envelope in order to explore further optimisation, or to improve upon the specification. There is an emphasis on debug skills and in-lab investigation.

FPGA-based Prototyping is a Validation Technology

Looking back at your survey responses, we see that “System Validation”, “System Integration” and “Software Development” are also popular uses for FPGA-based Prototyping. These use modes are definitely in the validation camp. Here we are using the FPGA-based Prototype as a substitute for the first-silicon and in effect, we are running early acceptance tests on the design and its software. Once again, we are taking advantage of its unique combination of high-speed and accuracy.

In many cases the FPGA-based Prototype is used as a real-world platform upon which to exercise the software, especially software at lower (physical) levels of the stack. Of course, we may find some RTL bugs when we run the real software at speed (kudos indeed to the verification team if we don’t!) and this is an excellent by-product, however, that was not the prototype’s original purpose. Simulation and Emulation are better for verification while FPGA-based Prototyping is better for validation. Virtual prototyping also falls into the validation camp, with emphasis on the higher levels of the software stack and pre-RTL stages of the design.

If finding RTL bugs is your purpose, then simulation and a good verification Methodology will be your best bet. If exercising software and validating the system is our purpose, then prototyping is a far better choice than any verification technology.

In the end, most SoC teams will use both and value the contribution of each equally.

Doug

*** ENDS ***

Most, if not all, chip design teams will work to a given RTL style guide but we wonder how many of those style guides include steps to avoid FPGA hostility. We don’t need the design to include specific FPGA elements or features but at least it should allow us to make use of those in our prototyping efforts without too much extra effort. One sure way to do this is to use wrappers.

What is a wrapper?

The term “wrapper” may mean different things to different people, but we think of a wrapper as an RTL construct that keeps technology-specific design elements from “contaminating” the surrounding RTL. For example, as seen in figure 1, if the chip design calls for the instantiation of a specific leaf cell from the silicon library, then we do NOT write this directly into the RTL. Instead, we declare a new module in the RTL where we need to make the instantiation, and then write the leaf-cell inside that new module (preferably in a separate file). The new module is called a wrapper.

Figure 1: Wrapper contents changed to suit RTL target

This simple step of creating a module sub-hierarchy for the instantiation means that we can change or remove its contents )in this case the particular leaf cell) without having to change the surrounding RTL. It also means that the surrounding RTL is kept technology-independent i.e. is not “contaminated” by the leaf-cell instantiation. After all, it only takes one leaf-cell to make the whole of the RTL at that level technology-specific.

Consider a simple case where the chip design requires that we add a voltage level-shifter on a signal. The designer should NOT instantiate the level shifter cell into the RTL directly, but instead place it in a wrapper and use that wrapper in the RTL. Later, the content of the wrapper could be replaced, for example with a new level-shifter for a different silicon technology i.e. the RTL is already more portable. More importantly from the point of view of a prototyper is that we don’t need level shifters during prototyping, and it is trivial to replace it with a pass-though wire. It is also possible to automate this replacement, and some sophisticated users even have a file-list generation tool which will reference different files with their different definitions of the wrapper module depending on the target technology.

Are wrappers essential?

Figure 2: Certify creates sub RTL for library leaf cell

If you are not lucky enough to receive such nice portable RTL but instead our example leaf-cell is instantiated directly in the RTL, then the work around is to create a new definition for the cell for use during prototyping. You will need to do something anyway, because the FPGA tool chain will otherwise treat the leaf cell as a black box. The good news is that if you have the source .lib file for the silicon technology library which includes the leaf cell definition then the Certify tool from Synopsys will automatically reference the .lib file. Certify will then create functionally equivalent RTL for the leaf-cell and use it in the rest of the FPGA tool flow, as shown in figure 2.

So much for leaf cells; the real power of wrappers comes when we can agree an internal style and naming policy and can start to automate the content creation for prototyping, based on the boundary names. etc. In the next blog post we will explore that and go on to look at the much more interesting case of using wrappers for instantiating memories.

We hope it helps!

Doug and Mick

. . . especially those who are trying hard to complete a milestone in their projects before Christmas.

Most of us have probably been there; when the SoC project started months ago, that “get it done by Christmas” deadline seemed a piece of cake, didn’t it? So, where did all the time go? Why do we sometimes find ourselves working long hours in the run up to Christmas (or any other deadline) to get stuff finished?

We think it comes down to the good old setting of expectations. If we have all the data, skills and tools, and others meet their commitments then we can set expectations (and deadlines) which are realistic but fit within the project timescales, even if those timescales itself have to be expanded to allow it. The skills in this case are that extra layer of expertise required to be REAL prototyper. What we mean is, we can take an FPGA expert from any bench and put them into a prototyping project but they will need to add an extra layer of expertise in order to be able to complete projects repeatedly and on time.  That extra layer of expertise gets honed by experience and makes the world’s few thousand prototypers into very valuable, indeed essential, members of any SoC design team.

But it’s not just about skill and experience.

 Make no mistake, good tools or bad tools and make or break a project. Unreliable, under‑performing or late hardware can also waste vast amounts of time. Prototypers can then find themselves in all sorts of bother because they underestimated the work or overestimated the ability of so-called automated tool flows. Blindly believe those seductive promises of a push-button flow here, or exaggerated performance claims there, and you won’t get home for Christmas. By the way, it’s also not much fun for the support guys at the tool vendors who have to back up such claims either.

So how can first time prototypers (and others) avoid setting the wrong expectations and struggling to meet deadlines? The answer seems obvious but I’ll write it anyway. They should talk with the experts.  Seek out others in this very specialist field of FPGA-based Prototyping, even to the point of hiring some consultancy time. Read the FPMM manual, especially chapter 4; “Getting started”. Ask your chosen hardware or tool vendor for examples and check their track record; post questions on public fora, including our own FPMM Forum . After a while, you will be answering such questions for others and helping them set their expectations.

Finally, spare a thought for a person with the toughest deadline of all at this time of year, and that’s Santa Claus (or Father Christmas as we Englishmen call him). Even if only half of us have been good, that’s still billions of deliveries!

We hope he finds you all in time and meets your expectations, but most of all, we wish you and your family joy, health, love and peace, now and for the New Year.

 See you in 2012!

Doug and Mick

p.s. please pardon the Microsoft Office clipart; we didnt have time to license new stuff (tough deadline).

This post is about the added challenge of partioning non-sequential logic.

What’s that I hear you say? “We should partion only at block boundaries and all of our blocks have FFs at the ins and outs”. If so then you won’t have any combinatorial bondaries to worry about; you can advance to GO and collect £200 (or $200 but that’s not as much). I’m betting that there are others, however, who receive less optimal RTL and need to get the design onto the board any which way they can; am I right? For you, dear reader, here’s a couple of thoughts. . .

First, let’s answer the Partition Poser from the previous post because it is related; we don’t just throw these blogs together, you know (grin). As Minh-Duc Doan of Lantiq posted, the best solution is to split the Mux into three smaller muxes, as shown in the digram below.

This reduces the number of IO pins and traces between the FPGAs by around 2n (where n is the width of the mux). As it happens, our own Certify tool split muxes  like this automatically (along with the associated control logic). Drop me or your friendly Synopsys prototyper a line if you’d like to learn more.

As Keith at Octera pointed out though, we still have the problem of constraining the combinatorial paths. How might we do that, not just for this example but for any combinatorial bondary in general?

A first pass approximation is to half the clock period of the destination FF and apply that as an IO constraint. this is very rough but at least its better than nothing (nothing is interpretted as a WHOLE clock period when it comes to synthesis and P&R, which is obviously not valid). Of course, much better is to know how the combinatorial path delay is shared between the source and destination FPGAs, and set IO contraints accordingly.

Timing budgeting provides more accurate IO constraints for P&R tools.

The timing engine in Certify estimates the components of the path delay in the source and destination FPGAs. If provided in the board description, it will also use the on-board flight time.

Consider the example below . . .

In this example, the estimates have been calculated as shown; 22ns in the source FPGA and 5ns in the destination FPGA. There is also 3ns allocated as on-board flight time. The timing constraint for the whole FF-to-FF path is given as 40ns in this example. We can see, then, that the total path delay of 22+3+5= 30ns meets the overall 40ns constraint. So far, so good, but what IO constraint should be passed on to the P&R tool runs for each FPGA?

If we were to use a half-clock default mentioned above, i.e. 20ns, then we will be over constraining the path in FPGA A but dangerously under-constraining the path in FPGA B.

Time budgeting, instead, has the ability to estimate timing in the whole path while it is still in the partitioner (in this case Certify) . Not only does this warn if the overall path does not meet the 40ns constraint but also  the IO constraints can then be allocated according to their proportion of the overall path delay. So in this example, we forward annotate to the P&R for FPGA A an IO constraint of 29.3ns. We can then allocate the remainder of the clock constraint, minus the on-board flight time, to FPGA B. So, in this example, that is 10.7ns slack from FPGA A minus the 3ns on-board flight time = 7.7ns.

So now both FPGA A and FPGA B have reasonable IO constraints which if met during the individual P&R runs will allow the overall path to meet the system-level timing constraint.

I’m sure you would hate to do this manually so look for tools that can use time-budgeting to do this during partitioning and forward annotate realistic IO constraints to P&R as a result.

That’s all for now.

As ever, we’d love to hear from you with your experiences of these issues.

Cheers,

Doug and Mick, Dec 2nd

This is an excellent goal but one that we can not always reach.

We often need to partition combinatorial paths across FPGA boundaries and then we need to ensure good time constraints for the synthesis and, especially, for the P&R for each end of the path. Don’t forget, when implemented in the individual source and destination FPGAs, each part of the path is considered in isolation. The synthesis and P&R tools have no knowledge of the other end of the path and will assume by default that the signals on the stub that they can see have an entire clock period  to propagate (minus set-up or hold for the FF). In reality this is never the case and so we need to apply good timing constraints for these stubs. This is achieved by time budgeting the path to allocate an appropriate portion of the full path propagation delay to each stub. This is automated in tools like the Certify tool that I know and love. When the path runs across three or more FPGAs with the middle FPGAs possibly acting only as feedthroughs then the task becomes really tricky.

We can talk about time budgeting of combinatorial paths in a future blog but in the meantime, I have a poser for you around the best way to partition an example of a inter-FPGA combinatorial path.

 The simplified example in the diagram below, with a mux feeding multiple sources from two source FPGAs into a separate destination FPGA, is not as uncommon as we’d like to hope. After all, many bus standards used in SoCs are actually complex mux’es, and bus sources and destinations are often partitioned into different FPGAs.

Here, then, is a good example of how partition has happened at a multiplexer. We can see that the sources for the mux are in two seperate FPGAs and the destination is in a third. The next task is to assign the multiplexer. The question for you is; where is the best place to put the multiplexer, including how and why?

Please use the comment box below to give us your replies.

I’ll explain my favourite answer in our next blog in any case.

All the best,

Doug

In the sessions, we were privileged to hear from some prototypers who presented about what prototyping has done for them. We heard from some very well known names and aim to post their stories on this blog in the coming weeks. In the meantime, I am very happy to share with you a video created by one of our in-house prototypers, Torrey Lewis, which we shared at some of the recent workshops.

Torrey is based in the Synopsys labs in Hillsboro, Oregon, where he works on proving the latest IP titles using FPGA-based prototypes. The video runs for 15 minutes and shows the flow for configuring IP titles for simulation and prototyping before Torrey takes us into the lab to see the HAPS-51 and other hardware in action. We then switch to seeing the design debugged remotely using the Identify RTL Debugger and a LeCroy PCIe Analyzer.

Having experts like Torrey in the Synopsys team is mutually beneficial. The Certify, Identify and HAPS teams get first-hand feedback on product performance while the IP team don’t have to create their own FPGA boards anymore. In fact, it’s the industry in microcosm, and a relationship that’s repeated many times in labs around the world.
We look forward to sharing more “Meet the Prototypers” stories with you over the coming weeks, in the meantime, I look forward to meeting more of you at forthcoming FPMM Workshops as they come to a city near you.
All the best,
Doug

We are in the thick of our FPMM workshops. Thanks to all those who have come along to their local workshop and given us such excellent feedback. glad you’ve foubnd the book and the workshops so useful. Let’s keep in touch!

In the meantime, we thought you’d appreciate seeing a real world prototype in action. Our Synopsys colleague, Eric Huang, loves to put video on his blog, which has the brilliant name “To USB or not to USB”.  There’s a great video of the use of a HAPS-based protoype running at USB 3.0 speeds. This video was taken at the Intel Developers Forum (IDF) last autumn (look for new videos of the most recent IDF soon!).

We will have other videos here from time to time and also many FPMM workshop attendees are signing up to be guest bloggers, so look for more “Meet the Prototypers” posts soon. There’s nothing as inspiring as other’s success, is there?

Happy prototyping!

Doug and Mick

The FPMM was released worldwide in March 2011 and already over 2,500 paper and ebook versions of the FPMM have been taken by prototypers worldwide. The feedback has been really encouraging so many, many thanks to all our readers!

As another way to bring prototypers together in order to further share best practices, FPMM originators, Synopsys and Xilinx, along with new prototyping partner National Instruments, are running a series of FPMM workshops. These workshops have already started and will take place at major locations throughout the world until February 2012.

Agenda items of note include . . .

• Keynote: “Best Practices in Design-for-Prototyping”
  • Why FPGA-based prototyping methodology is important to your success
  • The latest technologies and tools for FPGA-based prototyping
• User experiences and discussion
• Hands-on lab: advanced scripts and methods to improve prototyping
• Live demos of prototyping technology from National Instruments, Synopsys and Xilinx
• Integrating prototyping more closely within SoC project aims

For me, however, the most important thing is that prototypers get a chance to network and share ideas and best practices; starting a conversation that we can continue online at the FPMM forums and here on the blog. I look forward to meeting many new prototyping friends at every FPMM workshop, perhaps at one near you. Your fellow prototypers will be grateful for your participation.

During the hands-on portion you will have the opportunity to put a proven FPGA-based prototyping methodology to work, focusing on design manipulations and useful scripts for prototype management. You will be using Synopsys tools but no prior experience is required.

Go here to learn more and to register. Numbers are limited by the number of workstations available at each venue so, as they always say, “register now to avoid disappointment”. No, I really mean it.

See you at the workshop!

Doug

If you would like to learn more about the FPGA-Based Prototyping Methodology Manual, or to download a copy visit www.synopsys.com/fpmm

Answer: With an FPGA-based prototype of course!   

http://www.bbc.co.uk/blogs/researchanddevelopment/2011/07/dvb-t2-lite-profile-tech-stand.shtml

The link takes you to the British Broadcasting Corporations (BBC) R&D Blog where they talk about test transmissions of the new DVB-T2-Lite standard.  They started live transmissions within days of the standard being approved by developing prototype transmitter (modulator) and receiver (demodulator) designs. 

Justin Mitchell of the BBC with the prototype modulator (Look closely, there is Synopsys HAPS FPGA-based prototype systems in the enclosure)

The BBC were key contributors to the FPMM and their success with the DVB-T2-Lite go live clearly endorses their expertise in both the digital broadcasting and prototyping fields.

For those interested the new T2-Lite profile is designed to make use of the same reliable features we are familiar with from DVB-T2, but by a careful selection of a sub-set of modes, allows for receivers to be implemented using much smaller and more efficient silicon chips. So T2‑Lite will efficiently deliver TV and radio to mobile devices such as phones and tablets (for which power consumption is an important issue) and in-car at the same time as providing services to existing fixed receivers.