Highlights from ShowStoppers event at CTIA

Skype showed their VOIP app running on a variety of smart-phones. Couldn't figure out the human (female) billboard though. I mean... Yes it got attention, but What was that getup?

Slacker radio (slacker.com) provides "unlimited" free radio for mobile
phones. Competes with pandora app on iPhone?

GoTV (gotvnetworks.com) shows plugin for Facebook: share user media
(pics, vids, audio) from cell phone or PC.

Vanu (vanu.com) developed Software-Defined Radio (SDR) to enable multi-
standard configurability and multi-carrier sharing of basestations.

Alcatel-Lucent also showed a web-based app for personal media sharing
with members of your social network, merging your contact lists.

More on "rich media" sharing... Smith Micro showed software to enable
carriers to provide merged voice, chat, IM, SMS, file sharing, etc.
in a single integrated client.

-Mike

Sent from my iPhone

WiFi in a SD memory card: Eye-Fi

The guest speaker at tonight's meeting of the IEEE Santa Clara Valley Consumer Electronics Society meeting was Ziv Gillat, Vice President of Business Development and Founder of Eye-Fi.

If you (like me) are a serious amateur photographer who gets frustrated with USB-2 transfer speed after shooting a bunch of pics, you should definitely check out the Eye-Fi product. I had heard of DSLR cameras adding WIFi connectivity, but it turns out that Eye-Fi has a solution that you can add to almost any digital camera. They have figured out a way to add an Atheros WiFi chip to a standard format 2GB SD card.

Ziv passed around a sample of the Eye-Fi card, showing the Samsung flash memory, Atheros WiFi, and Hyperstone memory controller, along with a few other support chips. If you want more of the parts breakdown, there is even a Wikipedia page with the details.

The cool things about the Eye-Fi are not just the technology, but also the infrastructure, service and business model that make it a complete solution. Ziv has setup relationships with online photo sharing sites such as Flickr, Kodak, Facebook, etc. so that you can essentially stream your pictures live directly to the internet - as long as you are within reach of a WiFi hotspot. During the meeting, Ziv shot some pics and they automatically uploaded to Flickr and Facebook while he was talking. He also has arranged a relationship with Skyhook Wireless, which enables automatic geo-tagging of your pictures based on the location of the nearest WiFi MAC address. That part's kinda scary, since Skyhook apparently drives around (like Google street view) and sniffs out locations of wireless routers to build their location reference database.

The demo worked surprisingly well, given that the camera used for the demo was a high-end Nikon which has a metal case, and the SD card was inserted in a compact flash (CF) card adapter. The Eye-Fi business model offers tiered pricing, starting at $49.95 for the Eye-Fi Home edition, which only works with your home computer. That's still cheaper than the 1st 2GB CF card I bought for my Canon EOS just a couple years ago. The 2GB Eye-Fi Share adds the direct online upload capability for $59.95. A 4GB Eye-Fi Explore card adds Wayport hot spot access and geo-tagging for $99.95.

So... I want one! But first, I have to get my CF card connector fixed. Yep... I was in too much of a hurry shooting my son's High School Hockey Championship game on Sunday, when I blindly attempted to switch cards at half-time. Ugh.. bent the pins. The bad news is that I couldn't shoot at all in the 2nd half. But the good news is that Scotts Valley won.. 12-1!

-Mike

Update on requirements for AMS assertions

In today's Accellera Requirements Gathering Group meeting on AMS Assertions, Jim Lear of Zarlink shared his perspective from in the trenches of complex AMS verification. I think that it was very eye opening to move the discussion up from the details of language requirements (i.e. the proposed solution) to stop for a moment to examine a real-world example of the problem we are trying to solve.

Jim expressed a concern that a focus on assertions would not solve his problems, which may be better represented by referring to the concept of transactions. In his company's designs, verification is based on performing tests of AMS circuit properties such as THD, linearity, etc. Many of these properties require analysis through frequency-domain transformation on time-domain data.

In Taxonomy of analog properties, which I published in Sept-08 on Analog Insights, I described requirements for verifying this type of cumulative signal property in AMS circuits:

Signal properties II: cumulative temporal properties

This type of property includes behavior that requires many measurements of multiple signals, sweeping over time and-or voltage/current in order to test. Examples are dynamic differential and integral linearity in an analog-digital converter, jitter, eye-width in a SERDES bit stream, etc.

Signal properties III: frequency domain properties

This could perhaps be included in the type II signal properties, but I break out separately the type of AMS circuit properties that are derived through frequency domain transformations. Anything to do with harmonic distortion, signal-to-noise ratio, filter cutoff frequency, etc. falls into this category.

The taxonomy has now been integrated into the Working Draft of Requirements for Analog Assertions. In the current version of the draft document, Type II properties are included in our scope as "Required", while the Type III properties are currently listed as "Low Interest".

Keep in mind that, in the language of System Verilog, an assertion is nothing other than the test of some property of a circuit or system. Here is an excerpt of the semantics defined in SystemVerilog 3.1, Accellera’s Extensions to Verilog®:

assert property ( property_spec ) action_block

Jim emphasized that rather than being simulator-language centric (i.e. System Verilog assertions), what he really needs is a library of test functions that can be applied to a design, and then transferred for use in the lab or in production tests of real silicon. This reminded me of a proposal that I wrote in "Followup to Comments" on my Analog Insights post on AMS assertions… a violation of “the 10 commandments”? in November of last year.

In that article, I suggested that AMS assertion-based verification could better be developed by allowing analog simulator vendors to develop their own proprietary implementations of analog property checkers, which could then be instantiated (i.e. asserted) from within a System Verilog testbench. This would allow solutions to be built upon tools which analog engineers employ today; such as measurement description languages and waveform analyzers, rather than attempting to fit an analog problem into a digital framework. The problem then, from a language extension perspective, would be limited to defining the interface.

Here is an excerpt from my November 19th, 2008 post:

My proposal is this: create an “AMSproperty” command to complement the current digital “property” functions in SV. Consider this…

• Just as Verilog-AMS supports analysis-dependent functions: analysis (analysis_list)
• Similarly, we could have analysis-dependent assertions: AMSproperty (property type);

I believe that this approach could really move things along much faster towards achieving the objective of helping Analog Meet Digital in complex AMS verification.

Your thoughts?

-Mike

Notes from Silicon Valley SNUG-09

I attended the opening session of the Synopsys User Group Meeting this morning, then returned in the afternoon for two sessions related to Open Access and custom design. I hope to expand upon some of these topics later, but here is a quick dump of my notes:

• Attendance in the morning session looked to be way down from previous years, but picked up quite a bit in the afternoon.
  
• Aart gave another rendition of the "Techonomics" speech that he previously gave at DVCon last month. It's a (surprisingly) analog schematic of the economic mess we are in, complete with amplifiers and feedback loops. Apropos of credit default swaps and the cause of the meltdown; during the lunch break the AIG story was covered very well on the local NPR outlet KQED's Fresh Air.
  
• The big "What's New" announcement was about the "Lynx" (digital) flow manager. You can't beat Harry.. the ASIC guy's coverage, but I do have a few thoughts on the subject.
  

  If you have read my blogs for a while, you know that I have called for more focus by the EDA companies on flows – but not as "products". In my opinion, EDA companies could better serve their customers if they structured their operations according to the flows that their customers must employ. No EDA company does this. Products are developed in separate silos. Regarding attempts to "productize" flows, I have some experience as an observer of similar attempts by Cadence which inform my thoughts on the Lynx announcement:
  

  • It's difficult to get people to pay for flows. The big customers have built their own and want a customized flow, and the small customers can't afford the price.
    
  • As was the case at Cadence, the Lynx flow was developed to drive a service offering, and is being launched as a product by the services and IP group. Rolling out a flow that is not "owned" by the business units that develop the constituent point tools can be a problem. The individual BUs have their own product roadmaps, and the interfaces between tools cross over to multiple BUs. Coordinating, synchronizing and influencing the roadmaps and release schedules to support a flow as product is a big challenge.
    
• Though I see no mention of it in any Synopsys press releases, the "What's new?" in verification announcement was for "Custom Sim". Custom sim is the "unification" of the NanoSim, HSIM and XA Fast-SPICE products. I believe that this means there will be interchangeable licenses for the three generations of simulators, not that the engines are unified from a functional point of view. Each of the Fast-SPICE engines now supports the "direct-kernel interface" (DKI) for mixed-signal simulation with VCS.
  
• Tom Quan of TSMC gave an interesting presentation of "What TSMC's Open Innovation Program (OIP) Means for Layout Designers". This relates to the session on Open Access which followed, with the key point being that TSMC is developing a system based on one technology file for all tools at any point in the flow, rather than the old system of qualifying multiple tools with unique tech files for each vendor. TSMC and customers both potentially benefit from reduced time to develop and qualify tool support, reduced maintenance and enhanced interoperability.
  
• The "Advantages and Experiences with an Open Custom Design Environment" panel discussion was interesting. Panelists were:
  
  • Jim Wilmore – Intel
    
  • Jeff Berkman – Priva
    
  • Tom Quan – TSMC
    
  • Scott Chase – Synopsys
    

  The discussion provided an interesting counterpoint to a recent Cadence blog post, which criticized interoperable p-cells, claiming that they are "the lowest common denominator". Tom showed results from a recent 65nm RF-CMOS kit development, where Open Access PyCells were compared to Cadence p-cells. The feature comparison showed the two to be equivalent, and most interesting – PyCells were "plug compatible" with p-Cells. Hmm.. lowest common denominator? How ironic that Cadence is the sole development member of Open Access in Si2.
  

There's more, but that's all for now.

-Mike

AMS Verification at DVCon – Part III

This year's DVCon session on Mixed-Signal Design and Verification included three presentations:

1. Validating WiMAX OFDMA Using SystemVerilog and VMM
• Albert Chiang, Wei-Hua Han, Synopsys, inc.
• Bhanu Kapoor of Mimasic
2. A SystemVerilog Approach for Analog/Mixed-Signal Verification
• Shyam Rapaka, Tapan Halder
• Verification Group, Synopsys Inc.
• Vikas Chandra ARM R&D
3. Get to ASICs Faster - A Novel Mixed Signal Design Methodology
• Dr. Greg Tumbush
• Tumbush Enterprises
• William Gonnason, Dustin Griesdorf , Alaa El-agha, Gareth Weale, Marc Matthey, Andreas Drollinger
• ON Semiconductor
• Holger Meiners
• holger_meiners@yahoo.de

Paper #3

The subject of the last paper in the Mixed-Signal Design and Verification session at DVCon was a methodology for RF/mixed-signal ASICs that was applied to a hearing aid design. The critical goal of the methodology was shortening the design cycle by developing a complete “executable specification” in System-C that could link to the RF/analog simulations that were performed with Agilent’s Advanced Design System (ADS).

For the RF/analog portion of the design, nothing new was introduced beyond a standard application of ADS. However, by adopting System-C for the digital subsystem, the overall level of abstraction was moved up in the design hierarchy such that a complete (executable) architectural model could be constructed. This was contrasted with what the author’s referred to as a “traditional” design flow, where executable models did not exist until the block-level design phase consisting of VHDL/Verilog and analog schematics.

ADS provides the circuit to architectural behavioral modeling capability for the RF subsystem, along with support for co-simulation with System-C. That capability allowed architectural tradeoffs to be made in RF front-end, resulting in a model that then served as the testbench for the digital subsystem.

Focusing on the AMS side of this RF/mixed-signal design methodology, it is significant to note the number of manual steps that still exist in the verification methodology compared to the digital flow. These are the holes that the EDA industry must address to make AMS verification as robust as digital. For example, the authors stated that the “RF front-end model was refined based on feedback from the circuit designers”. This is not the first time I have heard of the lack of automated circuit-behavioral model-checking. It takes an experienced team of modeling engineers and designers can pull this off, but the process is still error prone.

Another factor limiting RF/AMS model checking is simulator performance. The authors noted that “the VCO noise cannot be simulated in the Cadence environment because of the length of simulation time required”. It is unknown whether any attempt was made to employ a “analog Fast-SPICE” simulator to overcome this obstacle. As is always the case, the choice of abstraction level came down to a tradeoff “between confidence level in the model and simulation speed”.

In the full-chip simulation, only digital Verilog models of basic analog behavior were used for critical functions. Again, the “correctness” of each model relied on signoff by the analog designer in charge of that component.

-Mike

AMS Verification at DVCon – Part II

This year's DVCon session on Mixed-Signal Design and Verification included three presentations:

• Validating WiMAX OFDMA Using SystemVerilog and VMM
  
  • Albert Chiang, Wei-Hua Han
    
    • Synopsys, Inc.
      
  • Bhanu Kapoor of Mimasic
    
• A SystemVerilog Approach for Analog/Mixed-Signal Verification
  
  • Shyam Rapaka, Tapan Halder
    
    • Verification Group, Synopsys Inc.
      
  • Vikas Chandra ARM R&D
    
• Get to ASICs Faster - A Novel Mixed Signal Design Methodology
  
  • Dr. Greg Tumbush
    
    • Tumbush Enterprises
      
  • William Gonnason, Dustin Griesdorf , Alaa El-agha, Gareth Weale, Marc Matthey, Andreas Drollinger
    
    • ON Semiconductor
      
  • Holger Meiners
    
    • holger_meiners@yahoo.de
      

Paper #2

The authors of "A SystemVerilog Approach for Analog/Mixed-Signal Verification" go well beyond the application of System Verilog (SV) features in Paper #1, by showing an example implementation of an SV test bench with a SPICE DUT for true mixed analog-digital verification.

A four-bit flash ADC, which may (deceptively) appear to be the simplest form of analog-digital converter, is used as an example AMS circuit in this paper. In actuality, testing a flash ADC is much more complex than the example shown, but the concepts used are interesting nevertheless. (Self-serving advertisement: For more on real test and verification procedures for flash ADCs see my book "High-Speed Analog-to-Digital Conversion". J).

The Synopsys methodology is based on a mechanism they developed "for interleaving SystemVerilog and SPICE with direct connections using ports". Previous authors have described using SPICE-Verilog co-simulation to send real values over wires through PLI 2.0, but the authors claim that their approach is superior, since it enables SPICE subcircuits to be directly instantiated in SV testbenches. SPICE subcircuits can also instantiate SV checker modules, allowing the use of SV assertions.

SPICE circuit nodes can connect to either wires or real-valued ports. As in all Verilog-AMS implementations, analog connections to digital wires require automatic insertion of converters at the digital/analog
boundary. Driving and sensing of SPICE node voltages is enabled through direct connection to real ports. SV checker modules can then contain both real and wire ports. This appears to be a proprietary implementation, and several questions arose regarding the use of wreal, which is not supported in SystemVerilog.

In the ADC example, SV provided the input stimulus for V_in and CLK, and an analog clock was generated specifically to trigger SV monitors of the ADC outputs. An SV initial block is used to generate piece-wise constant (not PWL as the authors claim) inputs. In referring to the use of SV to define the stimulus, the authors also erred in asserting (excuse the pun) that there "is no such provision in SPICE to represent such recurring patterns in a succinct manner". It may be a matter of taste, but the SPICE PWL function is pretty succinct in its use of time/voltage pairs to define transitions. SPICE also provides for the specification of transition time, which SV cannot easily do without the use of finer granularity through many delay statements. Further, HSPICE and other SPICE simulators have the 'R' repeat parameter as part of PWL sources, which is quite succinct.

The more interesting aspect of the SV-SPICE example is in the use of checker modules, where expected behavior of the ADC comparators is tested using SV assertions.

assert (((cmpOut > 0.9) && (Vin > Vref)) ((cmpOut < 0.9) && (Vref > Vin)))

A compiler directive is used to display messages regarding Pass/Fail conditions during simulation. In many respects this example is similar to the use of Verilog-AMS "assertions" that has been proposed by Henry Chang and Ken Kundert at Designer's Guide. (see Top-Down Design and Verification of Mixed-Signal Circuits). The SV-centric approach would be a good fit with "digital on top" verification, and obviously is a better fit with current digital verification methodologies. (Though discussions of the merger of SV and V-AMS are underway).

This paper is also interesting for the limitations and challenges it reveals when one considers how to bring continuous-time analog behavior in to a discrete-time digital verification environment. I think the most important question is, after you adapt to make analog fit into digital (see Square Pegs and Round Holes), is the verification worth doing? The example shown in this paper would show us that yes, we have a 4-bit ADC and it is hooked up right. There is certainly some value in that, but it's still only one small piece of a full AMS SoC verification where a circuit like this might be used. Those challenges are being address by the Accellera AMS Assertions Requirements Gathering Group. You can follow the link to check out the latest status of the discussion on the group's twiki site.

-Mike

AMS Verification at DVCon – Part I

This year's DVCon session on Mixed-Signal Design and Verification included three presentations:

• Validating WiMAX OFDMA Using SystemVerilog and VMM
  
  • Albert Chiang, Wei-Hua Han
    
    • Synopsys, Inc.
      
  • Bhanu Kapoor of Mimasic
    
• A SystemVerilog Approach for Analog/Mixed-Signal Verification
  
  • Shyam Rapaka, Tapan Halder
    
    • Verification Group, Synopsys Inc.
      
  • Vikas Chandra ARM R&D
    
• Get to ASICs Faster - A Novel Mixed Signal Design Methodology
  
  • Dr. Greg Tumbush
    
    • Tumbush Enterprises
      
  • William Gonnason, Dustin Griesdorf , Alaa El-agha, Gareth Weale, Marc Matthey, Andreas Drollinger
    
    • ON Semiconductor
      
  • Holger Meiners
    
    • holger_meiners@yahoo.de
      

Paper #1

The first paper on "Validating WiMAX" was presented by Synopsys, with a focus on features of System Verilog rather than describing a complete verification methodology for WiMAX transceivers. At the recent International Solid State Circuits Conference, several WiMAX designs were presented for fully integrated single-chip SoC designs in RF-CMOS (see Highlights of ISSCC 2009). The complex RF and analog portions of these designs require rigorous verification at the transistor level. While the authors make brief mention of this in the text of the paper, saying:

"… it is important to ensure that the design is simulated not only at the individual block-level but making use of a high capacity, transistor-level simulation engine to simulate the entire design including all post-layout parasitics that can have a detrimental effect on the front-end performance."

no mention of how this was performed was included in the talk.

In verifying the complete design of RF-AMS SoCs, the major challenge is how to verify the analog-digital interface to ensure correct functional behavior for the entire SoC. It is unfortunate that, while this paper was part of the "Mixed-Signal Design and Verification " session at DVCon, the presentation was completely focused on a digital functional verification problem. SystemVerilog classes were applied to model WiMAX frames, consisting of "zones" and "bursts" of data from the OFDMA transmission, in order to make use of constrained randomization techniques.

It appears that the authors of this paper employed a "divide & conquer" verification strategy, with separation of analog and digital into their own domains. A brief mention is made at the end of the paper, regarding use of Verilog-AMS to model the behavior of the RF front-end. The example of a VCO model is strictly Verilog-A however, with no digital co-simulation or connection to mixed-signal blocks. Such an approach could be error-prone, as it is dangerous to assume that the proper digital symbols were received or transmitted in the RF-AMS front end.

-Mike