Tim Davis's blog

Hit the Road(map) Jack

Tim Davis — Sat, 17 Mar 2018 01:25:29 +0000

First, with apologies to the awesome Ray Charles and his hit song, Hit the Road Jack, from which I borrowed this blog's catchy title, I want to introduce the idea of creating a roadmap for your next FPGA development project as a simple way to keep every project team's eye-on-the-target(s).

Now some will immediately respond with, "We have a formal project schedule that defines our roadmap". Just as quickly, I offer my snappy response, "Your project schedule reaks of greatness. Congratulations on producing it but can you show me the roadmap in it?"

Really, a project schedule does not replace a roadmap. (And certainly not vice versa!) But how can this be?

FPGA Development Roadmaps and Schedules

According to Merriam-Webster, a "road map (n)" is a detailed plan to guide progress toward a goal. I could not disagree more. I also do not want to incur the overarching process behind a technology roadmap. The Webster definition invokes more of a schedule connotation especially in regards to detail.

A schedule gives every task, duration, resource and dependency all in one handy Gantt chart. ~~The~~ A problem with a Gantt chart stems from the requirement for some poor soul to be pretty good at Microsoft Project to make changes to the project data and the distinct possibility that doing so is only allowed by one person who controls the document. It captures the exquisite detailed planning for reaching some goal, deliverable, or outcome. As the dictionary definition alludes, it is beautiful but delicate. So, not something you want to mess with lightly.

An FPGA development roadmap (just roadmap from here on), only requires experience with paper and pencil, a white board or perhaps Microsoft OneNote and does not have the rigidity and delicatness of a full on project schedule. Instead it strives to communicate where your FPGA design will potentially end up many releases in the future. Perhaps it is more like Horace Greeley's exultation, "Go west young man" -- which was less about an exact geographic destination then a suggestion of where success could be found.

The roadmap is the place where you deposit your ideas about features, capabilities, bug fixes, and in general any future modification of the design. It innoculates agains the ever present feature creep virus by providing an outlet and storage location for great ideas. It is the chilling air that keeps the current development effort frozen and therefore focused on a fixed set of features.

It should not be a place where ideas are discarded. Using the road map in this way promotes team unity by explicitly valuing all ideas as keepers.

The roadmap contains multiple parts:

Prototype Design
Past Released design(s)
Frozen Development Design (in progress)
Future Design(s)
Idea Pile
Codename List

Each page (yeah you only get one) in the roadmap contains the codename for the design, the version number string, the short descriptive goal of this design and an ordered list or table of features. I use the term feature generically here -- they could be bug fixes, enhancements to functionality, possibly removal of unused capabilities, you name it. The feature ordering is by rough priority the further down the list of roadmap pages you are. However, the Frozen Development Design page should have a very formal priority. Items at the end of the list are fair game for movement at the last moment into the next-in-line Future Design pile.

Rules for Adding Features to the FPGA Development Roadmap

New ideas are always placed in the Idea Pile prior to roadmap discussions. They need to age there for a time prior to movement into any of the Future Design pages.
The Frozen Development Design page needs to have the names of all the participants and principles recorded on it to signify their acceptance of the frozen state.

Prototypes

Freezer

Often times FPGA projects suffer from feature creap or scope creap.

The urge to fix things that are not broken yet.

Future

Idea Pile

Codename List

I like project codenames. They help to associate an easily discussed name for what is probably a complicated set of features.The name probably has nothing even remotely remenisicant of the actual features so the arbitraryness may seem like an empediment. In actual practice I have found it easy to use when a roadmap document is present to help qualify the features associated with the name. Also, if you choose a name set with ascending, alphabetically sequenced names, you add a simple sense of history for where you are at.

"Hafnium was a total failure, but Iodine has saved the day".

There are probably good name sets and bad based on ease of pronunciation and length in characters. Here are ones to consider:

Flowers (21 unique letters) Some are hard to pronouce though.
Elements of the periodic table (23 unique letters)
United States (19 unique letters)

Summary

An FPGA development roadmap helps you to document and agree upon a nice evenly sequenced set of design milestones. It helps prevent feature creap by acting as a respository for ideas which do not all require implementation immediately. It provides a discussion vehicle as everything is written down. It can help non subject matter experts (nSME) like managers get a grip on incremental progress milestones.

Postscript

As to whether, roadmap or road map is the proper sequence of characters, I defer to history but prefer roadmap for its memory saving footprint.

The Transistor Effect

Tim Davis — Fri, 02 Mar 2018 05:20:18 +0000

Who knew that transistors would have such a transformative power over our daily lives? We carry billions of them around in our pocket, on our wrist, in our computers. They are ubiquitous but also invisible.

Gordon Moore, the co-founder of Fairchild Semiconductor, established the observation that number of transistors in integrated circuits doubles about every two years. They call it Moore's law.

To reach the monumental number of transistors packed into our every day lives, engineers, scientists and visionaries had to cook up new ways to make the little devils. And they are devilishly difficult to produce in such large quanities on those very perfectly concocted slabs of purified beach sand called silicon wafers.

All from the observation that when you cross a wire over a specially doped area of silicon you get a small electronic switch. Hook those transistor switches into a logic gate, assemble those gates into CPU's and you get a revolution.

A revolution that eventually brought us to the Field Programmable Gate Array.

Bugs? Not in my schedule please.

Tim Davis — Fri, 24 Feb 2017 17:44:00 +0000

I have rescued a few designs during my 25+ years at the helm of Aspen Logic's FPGA/ASIC contracting business. Reasons abound for the causes of the failures but there are three areas that need consistent focus:

Designers give little up front thought to logic reset which leads to insidious, hard to find bugs
Management typically assigns a cost of $0 to bugs because FPGA devices are re-programmable so no time is allocated in the schedule for squishing them
Lack of a road map for features and fixes which makes decision making on large design efforts difficult

Reset Logic

#1 just requires an up front process to recognize the significance of this rather boring chore followed up by design review coverage. Pay special attention to 3rd party intellectual property cores and ask your vendor how their block is reset. If it contains a mixture of asynchronous and synchronous resets along with multiple clock domains -- run for the hills, pick a new vendor or demand to see a detailed explanation of how those are all implemented!

Zap Zap Zap (Go the Bugs)

Most of this post covers #2 as it requires zapping project management to wake them up. You like the idea of zapping your ~~boss, task-master, Voldemort~~ project manager (PM) but not necessarily getting fired am I right?

A quick way to zap is to insist on adding line items to your next project plan for fixing bugs and then assign outrageous $$$ signs to them. For example, tell the PM to budget for removal of 50 simple bugs, 20 hard bugs and 5 wicked bugs. (Scale the numbers with the complexity of the project). Make each wicked bug take 40-80 days to solve, hard bug 10-15 days and simple bug 1-2 days. Explain that wicked bugs occur because of requirement creep impacting the implementation with no way to regression test new feature code, poor or non-existent design reviews and schedule driven code creation with little or no up front design effort. Hard bugs occur when engineers do not get time for writing block/module/unit test benches. Easy bugs occur because engineers race to meet artificial deadlines, miss simple details and make bonehead mistakes. (This is just a concrete way of starting a discussion -- bugs are a result of many things including the items mentioned.)

Note that every project manager on the planet prohibits bug removal as one big line item in their schedules because the duration is impossible to predict and therefore their delivery date becomes impossible to predict. Writing HDL code delivers something concrete they can measure so schedules are always built around those tasks with a fixation bordering on mania.

Many could not write a line of code to save their mothers but they know, conveniently, it will only take you 11.5 days to code (meaning design, write HDL, test, debug, document) block #1! After checking off the coding tasks, everybody is goosed to delivery a bug free design through long hours and overtime which unfortunately just makes for tired engineers and more bugs. PM's always assume free overtime effort will cure any schedule deficiency and frequently state, "By the way, I thought it was free to re-program FPGAs. Isn't that why we bought them?" :-)

Do not fall into the gaping maw of this trap. Insist on predicting bug killing time up front, and separately from design, then you can have a ~~fist fight~~ discussion how to spend time and money effectively to reduce (but not entirely eliminate) it. Negotiate the time needed to fix bugs, but not the number of them, by insisting that design, verification and review will reduce the severity of each class of defect. Educate them that controllability and observability are key to defect diagnosis and that having the proper tools (hardware and/or software) and resources (50% unused LUTs/memory/routing for internal FPGA logic analyzers) are critical so they must be considered early in the budgeting process.

Road Map (to salvation)

Lastly, from now on, I am insisting that customers prepare configuration management plans up front that contain a malleable road map document which identifies the build versions that will contain new features and bug fixes. That keeps the pressure and the creep down as people can at least sit in a room and make rational decisions about the costs and priorities based on a written, high-level plan that evolves as the project progresses. Try these ideas on your next project and let me know how they go.

Verifying Validation and Validating Verification

Tim Davis — Fri, 22 Oct 2010 04:22:00 +0000

People (I guess we classify engineers as people) have always talked about verification and the "testing" of a piece of hardware to see if it works as the "same thing". Unfortunately for us there is a movement within international standards bodies (dating back centuries) to have us believe that there are really two types of testing: verification and validation.

Is your head spinning?

Validation is often defined as "checking if you built the right thing". Verification, in just as catchy a way, is defined as "checking if you built the thing right."

What is the right thing? Why that is the thing the customer wanted. So I can go with that. Who wants to build stuff the customer doesn't want? (Frequently many companies do this and go out of business. Others build things the customers don't want but convince them that they want it anyway -- that is worth a whole blog!)

If people don't know what they want, no development process -- no matter how exact, how clever, or how efficient -- will satisfy them. And that's why we do requirements work -- so we don't design systems that people don't want.

Boiled down: The right thing is the requirements!

My argument is that requirements exist everywhere in a system, at every level of abstraction and between every component. The customer is not just the entity that "buys" your system but is anybody or anything that express a requirement. You must satisfy the requirement then verify that you did so. The entity responsible for the requirement does not factor into the equation so I believe the distinction between "validating" and "verifying" as used in international standards is just confusing. (I see this all the time in the work I'm doing right now. The documentation is rife with confusion w.r.t. the usage of these very similar "v" words.)

Also, the idea of checking if you built (past tense) the right thing seems economically tenuous at best. Why build something then ask if it is the right thing? That seems awfully expensive. So, really what needs to happen is to validate the requirements themselves before the race starts, before the chicken hatches, before the horses get out of the barn, etc., etc., etc.

In my dictionary I would define validation as the art and science of confirming, checking, testing, and verifying that the requirements are correct. Correct in the sense that you know they properly specify what is needed. If you build the requirements right, the right thing will get built -- not as cute and catchy but a better statement of what needs to be done me thinks!

So, I require the phone number of the ISO President, Secretariat General, or head dude so I can let him in on the secret. If you have it drop me a line. Thanks!

FPGA Mezzanine Card (FMC) Standard

Tim Davis — Fri, 05 Mar 2010 09:48:00 +0000

You of course know it by ANSI/VITA 57 since you are an engineer. Or maybe you do not get regular updates from the VMEBus International Trade Association and just know that Xilinx and their board makers, like Tokyo Electron Device, use FMC connectors.

But what's in it for me?

For starters you get a high performance interconnect standard that supports up to 10 Gb/s transmission with adaptively equalized I/O (think Xilinx RocketIO) and singled ended | differential signaling up to 2 Gb/s.

Secondly the connector supports a wealth of connections. The standard connector, organized as 40 columns of 10 rows, populates with 400 contacts (HPC - high pin count) or 160 contacts (LPC - low pin count). The standard specifies Samtec brand connectors (or equivalent) with a variety of stacking heights from 10mm down to 8.5mm.

There are other features of the standard that are interesting: double width modules, conduction cooled thermal interface, ruggedized modules, etc.
Fixed supply voltage pins
I2C based card identification and geographical card addressing
JTAG pins
Dual reference voltage supplies for BANK A and BANK B signaling standards.
VADJ (adjustable means user selectable) voltage pin, 3P3V and 12P0V and 3P3VAUX supplies
Fixed pin assignments for clock distribution (from carrier card to module and from module to carrier card) with defined skew specifications
10 pairs (tx + rx) multi-gigabit transceiver pins (40 pins total) plus two gigabit I/O reference clocks (one for each direction -- carrier to module and module to carrier)
User defined pins: 34 pairs of differential I/O on LPC bank A, 24 pairs diff I/O on HPC bank A, 22 Pairs diff I/O on HPC bank B.

Wow! So what's in it for me?

Investment preservation - both engineering effort and money. Now, that expensive evaluation board you bought for project X-Factor has usefulness on your next project Y-Phase. Simply remove the mezzanine card (daughter card) and replace it with one useful for project Y-phase.

Board vendors have caught on. For example, inrevium evaluation boards from Tokyo Electron Device, like the TB-6S-150T-IMG, sport multiple HPC and LPC connectors.

Their Consumer Video Kit (CVK) leverages this with mezzanine cards that provide DisplayPort, HDMI, LVDS and V-by-1 interfaces. However, if you bought the card for video algorithm experimentation today, you can use it for audio next week with a different set of mezzanine modules -- from TED or any other vendor.

So, "what's in it for me" is answered simply as flexibility and cost savings. Talk your boss into an FMC solution and your own bottom line will be improved!

Copyright © 2010 Aspen Logic, Inc. All Rights Reserved.

A Font Of Wisdom For You

Tim Davis — Wed, 18 Nov 2009 08:41:00 +0000

If you have a penchant for reading intense journal quality articles at the cutting edge of new research then the Cornell University Library e-Print archive @ arXiv.org is for you. From Physics to Biology to Computer Science -- it is all covered.

The computer science section alone has dozens of interesting categories including:

ASIC Prototyping: Is it design or verification?

Tim Davis — Wed, 11 Nov 2009 04:37:00 +0000

Why does the ASIC developer need ASIC prototyping? Is it to learn how their existing design will function with a new interface -- say to DDR3 memory? Is it to completely verify their ASIC design prior to tapeout?

The wiktionary provides one definition of a prototype: An early sample or model built to test a concept or process.

The idea that the prototype is early suggests that ASIC prototyping is part of the design activity when the design space is being explored.

Yet, if a prototype is built primarily for testing (verification) then how will you track coverage? I can see the manager, newly trained in understanding the significance of coverage metrics asking, "Did you test everything in the ASIC prototype?" Simulation seems to rule in this area but how long will the simulation take for a big SOC? (My first ASIC prototyping experience was with a wire-wrapped mass of TTL dips on 4 very large prototyping cards soldered together at the edges and held in a very large oak frame. Decidedly unsophisticated versus today's standards but effective.)

Considering the complex environment that ASICs operate in perhaps the prototype serves the purpose of an at-speed bus functional model to be used with the surrounding system hardware. For example, such a model could provide meaningful interaction with PCIe driver firmware on the host prior to the availability of the actual device.

What ever the underlying goal I'm sure that ASIC prototyping is necessary. It just isn't clear to me how it is defined. I don't know of a formal definition of the term. But when I find it I'll publish it at ASICPROTOTYPING.COM.