Aspen Logic's Blah Blah Blog

My head is spinning.

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!)

In the book “Exploring Requirements Quality Before Design” by Gause & Weinberg (ISBN 0-932633-137-7 (C) 1989)  a particularly brilliant comment is expressed in the preface:

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!

Copyright (C) 2010 Aspen Logic, Inc. All Rights Reserved.

You of course know it by ANSI/VITA 57 since you are an engineer. Or maybe you don’t 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.

Have you ever opened a WISH shell and run a script doing a long calculation with embedded put statements to display intermediate results? Ever scratched your head when you wait for a while then get the last few results output to the display in that scenario?

Try this in both WISH and TCLSH shell windows:

for {set i 0} {$i < 10000} {incr i} {
  puts $i
}

Notice the difference now? In the TCLSH you get a continuous stream of output. In the WISH shell only the last few appear after the calculation is completely finished. (If you scroll back you see everything — just not as it was happening.)

This behavior has confused me for a long time. But I recently discovered the solution: use the TCL update command.

The update command was part of TK until the event loop (being such a useful thing) was moved from TK into TCL in the Tcl 7.5/Tk 4.1 release.

Display updates only occur after all other events have been processed in the event loop. This is significant because the WISH shell is a Tk window (subject to the event loop) while the TCLSH window is just an operating system window.

The script above prevents entry into the event loop so it never gets to the point where it can respond to display update events. The solution?

Those clever Tcl architects created the update command for this purpose. It forces entry into the event loop where events can be processed (in particular the ones that force the display to change.) Try this:

for {set i 0} {$i < 10000} {incr i} {
  puts $i
  if {$i % 1000 == 0} {update idletasks}
}

Running this in WISH will yield ten updates. You won’t see anything different in the TCLSH window.

Of course there may be some speed advantage in NOT updating the display but typically, with put statements anyway, you want to see them as you run the script.

Another typical use involves a Tk application where you need to be able to stop a calculation in progress. If you have a button for this (which sets a variable to some “stop” value) then you could poll the variable during your algorithm at good stopping points. However, your script will never see the variable change because the button click event won’t be seen! Your script needs the update command. However, in this case you want just the naked update command with no idletasks option.

The naked update command ensures that all events are processed by the event loop — not just the ones handled during idle time. So it permits the processing of buttons, keypresses, and all the other possible events.

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

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:

• Logic in Computer Science
• Programming Languages
• Distributed, Parallel, and Cluster Computing
• Neural and Evolutionary Computing

and many more.

I found the article arXiv:0911.2034 on expressing the behavior of concurrent systems interesting.

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

Xilinx just announced their EasyPath-6 cost reduction solution. There is only one reference to the word ASIC in the PR Newswire press release about EasyPath-6:

Unlike other approaches, EasyPath-6 FPGAs are neither an ASIC conversion
nor a routing-hardened FPGA.

Altera calls their Hardcopy solution an ASIC (and I believe is considered a structured ASIC in industry terms.)

Since the EasyPath device is not an ASIC nor a route hardened FPGA what is it? I still don’t know after reading the EasyPath-6 white paper (wp356.pdf). The white paper says the silicon isn’t changed yet the diagram on page three shows a standard Virtex-6 die and a different picture for the EasyPath-6 die. Clearly the silicon for EasyPath-6 is different. In fact that seems to be the whole point of the paper.

The redundancy in the standard FPGA design is removed (presumably based on the customer’s logic design) resulting in a smaller die. Smaller die means better yield and lower cost. Yeah I get that. But what about the bitstream?

It is still required. The EasyPath device still needs a companion memory device (or host programming capability) to initialize it.

Maybe that isn’t such a big deal but an ASIC doesn’t require it.

An ASIC uses significantly lower power as well.

An ASIC is cheaper in high volumes.

So if you want lower cost why not use a Spartan part? I thought that was the whole point of the Spartan devices — high volume = low cost.

Maybe I’m just easily confused by marketing speak. What am I missing here folks? Is cost the only important driver for ASIC designs?

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

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.

Copyright © 2009 ASPEN LOGIC, INC. ALL RIGHTS RESERVED.

If there is one thing that I always enjoy doing it is writing apps in TCL/TK. Since John Ousterhout wrote it to support the MAGIC VLSI layout system I’ve always felt a particular connection to it as an electrical engineer. Today though it has seriously out grown its original roots and spread to a wide spectrum of application domains. But I use it for scripting in Modelsim mainly and the occasional home grown app.

Yesterday I was figuring out how to pass a list of keys into the ‘dict’ command. Dict allows your scripts to setup easy, fast, ASCII databases for use in your applications. It is based on a key-value pair system that looks (and acts) very much like a regular TCL list. On the inside however, there is a powerful internal representation of the character strings that makes access very quick.

What is it used for? Think about how you would store a list of signals associated with various levels of your hierarchical VHDL/Verilog code that you want to have displayed in a simulator wave window. The dict data structure is ideal for that use. Here is a hand coded dictionary (with indenting for clarity):

top {ctrlr
       {counter {up down clr}
        fsm {state1 state2}
        mux {sel d1 d2 d3 d4 out}
       }
     dsp { ... }
    }

The dictionary is hierarchical because each value in the key-value pair can itself be a nested dictionary!

To access that hierarchy you need to get access to those lower level nested dictionaries. The syntax for the set sub command permits that:

dict set dictionaryvar key [key ...] value

The ability to specify multiple keys (as a variable number of arguments) allows the coder to descend down multiple levels in the dictionary hierarchy without calling the dict command multiple times.

To add another set of signals for a new block mem using the example dictionary above you would code:

% dict set SIGNALS top ctrlr mem [list addr rnw datain dataout]

Unfortunately, my requirement was to pass a (variable sized) list of keys to the dict set command. How do you flatten them out? You can’t just do something like this: (Warning blatant self promotion coming…)

% set keylist [list "ASPEN LOGIC" SKILLS]
% dict set SKILLS
$keylist "VHDL Verilog FPGA Design Xilinx
{{ASPEN LOGIC} SKILLS} {VHDL Verilog FPGA Design Xilinx}

That only passes one key to the command. Note that in the result there is only a single key-value pair and the key is {{ASPEN LOGIC} SKILLS}. Also, ‘FPGA Design’ isn’t one keyword. How to fix all that?

The eval command comes to the rescue. Let’s try this:

% set keylist [list "ASPEN LOGIC" SKILLS]
% set value [list "VHDL" "Verilog" "FPGA Design" "Xilinx"]
% eval dict set SKILLS $keylist {$value}
{ASPEN LOGIC} {SKILLS {VHDL Verilog {FPGA Design} Xilinx}}

Now we can see the desired hierarchical result. {ASPEN LOGIC} is the top key, “SKILLS” is the next lower level and it has {VHDL Verilog {FPGA Design} Xilinx} as the associated value. And, the list command has correctly wrapped the skill FPGA Design as a two word list {FPGA Design}.

You might have noticed the {$value} on the eval command. Why does the dict argument need to be in braces? This is slightly complicated but worth understanding. The eval command does a concat operation to flatten EVERYTHING on its command line. Without the braces the $value gets substituted and the contents then get flattened by concat. That would have the undesirable effect of making some of the words in $value become keys on the dict command line. By using braces around $value, which is the value part of the key-value pair, it remains as only a single argument.

You can do it all inline as well:

% eval dict set SKILLS [list "ASPEN LOGIC" CONTACT] janitor@aspenlogic.com
{ASPEN LOGIC} {SKILLS {VHDL Verilog {FPGA Design} Xilinx}
               CONTACT janitor@aspenlogic.com
              }

I hope you find a good use for the dict command in your synthesis, simulation and embedded development tools.

Copyright © 2009 ASPEN LOGIC, INC. All Rights Reserved.