• 11111111 Himyanshu Anand
  • 01111111 Kenneth Bakalar
  • 11111010 Prabal Bhattacharya
  • 01111011 Eduard Cerny
  • 11101110 Scott Cranston
  • 11011101 Mike Demler
  • 00000000 Surrendra Dudani
  • 11100000 John Havlicek
  • 11100011 Kevin Jones (RGG Leader)
  • 11111101 Scott Little
  • 10100000 David Sharrit
  • 00000001 Jim Lear
  • 00000001 Murtaza


Action Items:


JL: Zarlink is a telephony device maker. Over the last 10 years, developed the Mixed Signal Verification methodology. A lot of analog control, protocol communications that sit on top control systems.

KJ: Split from the main group about 2 months ago and decide where we are. What we need to be able to support in the analog assertions. We need support both the features - arbitrary precision and extension of System Verilog. We are at the point where we will be producing examples and use the working set to determine whether this is sufficient.

JL: We have concerns on language centered around assertions. Our latest chip has 50 delta sigmas on it and software for low frequency. These complex systems are almost impossible to verify. The verification needs to be continued even after silicon. We need a system of verification that can lead into labs. The concern is that these assertions will be simulation centered and not lend itself to lab. Production tests (ATPG) are different from simulation flow. Object Oriented type agents which do signal analysis and with these tools we have created a pseudo assertion language. It is more of a transactional layer rather than an assertion layer. But it lends itself to be reused in the lab. Are these alternatives feasible rather than a language centered thing.

KJ: We have a lot of discussions on the scope. Much of what you say resonates with what I have observed. If we can define an assertion language which is useful for AMS verification that is an ambitious first step.

JL: The checks we do or the assertions we do tend to be transactional. We tend to apply transactions (just like to a network processors), we will do a linearity test and the linearity would come out correctly on the other side of the data. Having these low level assertions I can see it used in a very limited functionality. I don't see the dificulty of changing these assertions into transactional layer checks. I would like to see some signal processing capability built into Verilog-AMS library.

KB: When you say transactional do you mean time domain properties.

JL: You have to limit yourself to time domain but most of our checks are in the frequency domain. RF simulators are a pseudo AC pattern simulation. A lot of our checks are in Spectral domain but our simulation is in time domain.

KB: We talked about this last time we met. You can think of DC checks as check at a particular time - time zero. The higher level functions that you are talking about is inherent in open-verification methodology. What we are builing here is a low level capability which will be used in higher level verification enviornment. The transaction says let me what the frequency response is at the current time. I want to make some decision and record some data. In my view this is a primitive mechanism which allows you to code the transactional assertions.

JL: Maybe we got most of the capability already in the language. What kind of support do we need for Object Oriented programming. One or two sine layers on the channel and what filters would be and configure the channel randomly. The checks look like crude assertions and we tell check this at time 0, check that the harmonic is within the range at time 't', etc.

MD: I want to point that we have discussed this kind of property in frequency domain, currently in our document this is low interest.

JL: We may need to achieve a DC response and can we go from this DC time to that DC time, is the rise time correct?

MD: The difference between this and frequency domain analysis. We are not talking about frequency domain simulation.

JL: We would issue a digital side stair step transaction and on analog side we do a linearity check, all done within a time domain.

HA: Can you not use assertions as building blocks of your transactions? As I understand your transactions are built from small checks.

JL: They could be built. But we do stimuli generation and check that with monitors. The sampled points need to be synchronized.

HA: I would assume stimuli generation would be different from monitor checking and for synchronization you can use your clocks, posedge or cross statements.

JL: Our external clocks are different from internal clocks and we have to do the synchronization.

SL: A comment was that we can do a lot today with what we have today with Verilog-AMS or VHDL-AMS and the term you used is poor-man's assertion. At least my understanding is to develop assertions and move away from monitors so that you have a formal notion of what is being checked. A subset of the language may be used to create measurement like functionality.

JL: 2 drawbacks of assertions. At the the transactional level how easy is it to write an assertion? Are people still using monitors for that. And the second is, can these assertions be translated into the lab once the silicon comes.

HA: How does the current system allow for that transition from simulation to Si.

JL: We have a specialized equipment which allows us to do that with a push button for wire telephony.

SL: You designed your checks with test equipment in mind. Is there something that will not allow the assertions to be used in the same way.

JL: I don't know if that is not possible. The lab equipment goes on transactions. If we are going to do assertions then the semantics can be mapped into lab enviornment without the language.

MD: Just curious what tools do you use for this transition.

JL: Slow spice, basic spice. We caught several bugs using this methodology.

KJ: Can you write some representational examples on what you want and we can see how far away we are from your requirements.

JL: My a little unhappy with the language. My temporal expressions are really crude.

KJ: How dense is the time domain? What is the resolution on time?

JL: Because we have digital signal processing, those are generally the limits of our time step. If we have asynchornous then we get FFTs that are very hard to analyze.

MD: I was wondering if we have not talked about these things in the past. You can have a library of these tests and then you have this library be used in a simulation or in lab equipment. Think of just what needs to be done and not how its done.

KB: In general its true that procedural languages provide all the artifacts that you can use to write assertions. But, assertions provide a compact way of defining the same.

JL: There's a class of analog engineers that tend to operate in the enviornment that "I have all the tools that I need in the schematic enviornment". I have mixed reception for the tools that I have.

KJ: One of the assumptions that we have been making is that this is intended for verification engineers and not the analog engineers.

ED: If you look at System Verilog checkers, more encapsulation has been provided. You can package pre-defined objects/checkers and they have much more flexible way of doing checkers. The assertions are not parameterizable but the module can be parameterized.

JL: These assertions can be incorporated into the higher level blocks. I don't disagree with any of that stuff.

KB: There is a notion of sequences, scoreboard, but what we are talking about is at the bit level.

JL: There are certainly some library type of components, signal analysis type of things, FFT, etc which would be useful is available in the language.

-- AnandHimyanshu - 31 Mar 2009

Topic revision: r1 - 2009-03-31 - 13:56:40 - AnandHimyanshu
Copyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback