Array
(
    [content] => 
    [params] => Array
        (
            [0] => /forum/threads/can-we-think-beyond-system-verilog.2955/
        )

    [addOns] => Array
        (
            [DL6/MLTP] => 13
            [Hampel/TimeZoneDebug] => 1000070
            [SV/ChangePostDate] => 2010200
            [SemiWiki/Newsletter] => 1000010
            [SemiWiki/WPMenu] => 1000010
            [SemiWiki/XPressExtend] => 1000010
            [ThemeHouse/XLink] => 1000970
            [ThemeHouse/XPress] => 1010570
            [XF] => 2021770
            [XFI] => 1050270
        )

    [wordpress] => /var/www/html
)

Can we Think Beyond System Verilog.....?

Nitish

New member
Is "SYSTEM VERILOG" the "Destination"? Sometimes i think that why we all are stuck at a thought of System Verilog. Is that we cant think beyond this?or are we limited to thinks what all EDA companies wants to make us think?

As time window is shrinking day by day in semiconductors all EDA vendors are providing the ready made and delicious environment for verification as per our needs. But by all this are we satisfied by our verification, can we say we are 100%?

As the major part of this Industry is working with already done work. means major part focuses on those IP's which are already done with design and Verification. Don't you think its waste of time and resources. we are again and again verifying those design's or IP's which we have debugged in prevoius Projects. Now the question arises WHY SO? reason can be in new projects the specification and scenarios changes, but not as much as we spend our time and resources. Traditionally, we have created the environment according to the industry based projects (Automobile, Entertainment etc). Yes in such case SV has given a potential improvement in Verification Methodology.

But if we talk about Design we have a lot more to do in this world irrespective of SIZE. Yes the Size Matters, but not in all cases of Semiconductor. for Example if u got a Cell phone whose size is equal to your watch, is this be comfortable for you to use it. I think "NO". So we have to understand Size has a limitation, and we should not go beyond that. We have to give more Focus on Newer developments not in Advancement of what has done.

Similarly this can also be applied to the Verification Process that we all follow. Now the time has come to thinks beyond the traditional flow or to improve this traditional Flow. Time has come that we should understand the practicalities of this world where Semiconductor is involved. We again have to give a thought that what we want, What we are Verifying, and What we are getting.

We have to go for some Revolutionary Development in Verification Methodology as well as in Semiconductor Industry. We have to think about all this costly and critical EDA resources.

" This world is the result of your Thinking, if you want to change the World Change the Thinking"

<script src="//platform.linkedin.com/in.js" type="text/javascript">
lang: en_US </script> <script type="IN/Share" data-counter="right"></script>
 
Last edited by a moderator:
I can think well beyond SystemVerilog. It has a bunch of problems that are pretty much unfixable with the current committee process, so I'm envisaging a C++ based flow that leverages open source tools as an alternative.

Http://parallel.cc

The complete lack of analog support in SV means that it completely misses power and thermal issues, and most stuff outside that is logic that should be verifiable with formal methods.
 
Hello Daniel,
I am working on Both of the things Design and Verification Flows, and giving my new ideas and thought to it. But still i am not with the result.
Might be in couple of weeks ill let u know about my thoughts.
 
Simguru,

What about Real Number Models and SystemVerilog?

I could write code in assembly language instead of C++ if I wanted, but it's not usually very productive. The real number modeling stuff is mostly a bad hack/work-around for an HDL not supporting something properly.

Wreal in Verilog-AMS is similar in that what you want is to just use the same syntax as the analog context e.g. "V(wr) = vltg;" with the same type checks and an obvious meaning (and the ability to swap views). As it stands the simulators view wires as either analog or digital rather than just wires with analog and/or digital stuff attached, and as such cannot work properly.

Basically the EDA companies are either clueless or not interested in combining the tools into a seamless mixed-signal environment (maybe due to their licensing model), so dealing with this stuff is way more complicated than it needs to be.

SystemVerilog is also a syntactic and semantic mess with a language reference manual bigger than C++'s, and there's no sign of a cleanup crew.
 
Verilog (A|D)MS?

Actually, almost all major EDA players are now spending significant energies in Mixed Signal promotion, in particular DMS (Verilog+Wreal). The real matter is that, even more than ABV, when it was a hot topic, MS demands methodology behind, as allocating resources for modeling in your system is not that straightforward at all, in particular when in absence of a proper verification-driven system decomposition.

Using a higher level of abstraction, in this field, has proved not to be handy, as you need to trim the abstraction level w.r.t. the degree of desired precision [think about synthesizable SystemC, Ouch!], and --furthermore-- the burden of keeping the high level and low level worlds "aligned and speaking" is really challenging when you get out of regularly supported language fields [is already quite troublesome even when you stay in, specially in the early days].

Sure enough you might play with extra fancy interfacing conventions, with PLI/VPI, reflexive and introspective code, using lots of nice patterns (singletons, factories, etc.) but it will be you and yourself in there (well, you may actually start something that way... :) ), when we should reckon that Verilog-A natures and disciplines are already a quite powerful mechanism, if used properly; curiously, I haven't found that many /useable/ theoretical supporting works in this field; few-digitals-in-sea-of-analog, or rather much more appealing: single-analog-in-sea-of-digital batteries of verification runs may be used, if not to imply, at least to give evidence that if the whole set of simulations with just one analog sub-subsystem at-a-time works fine, then /probably/ the whole analog subsystem might as well. It would be a matter of defining under which /minimal/ conditions on signal representation that approximation might work...

Lots of work ongoing there, and lots of work to do still. Try asking Cadence, Synopsys, or Mentor, or ...

Cheers,

Andrea.

PS: Currently, for at least one of the products I worked with, it is necessary to keep SystemVerilog and Verilog-MS separated, from a compilation perspective; this makes the whole thing slightly more complicated, but still pretty manageable.
 
Last edited by a moderator:
Actually, almost all major EDA players are now spending significant energies in Mixed Signal promotion, in particular DMS (Verilog+Wreal). ..

PS: Currently, for at least one of the products I worked with, it is necessary to keep SystemVerilog and Verilog-MS separated, from a compilation perspective; this makes the whole thing slightly more complicated, but still pretty manageable.

Promoting and fixing are two different things. The "wreal" stuff was always a bad hack.

There is no technical necessity to separate simulation code from different source languages unless your developers are clueless. The fundamentals of Verilog-AMS were published ~ 20 years ago and I have since shared with the technical committees on numerous occasions how to generalize the approach.

In particular the piece-wise linear modeling in Verilog-AMS is actually a discrete representation that can easily be handled in a digital simulator, the only "analog" part is the math modeling in the analog blocks/processes. We could have supported it in SV as part of the user defined types additions, but the folks responsible for that went out of their way to ignore Verilog-AMS and added "interconnect" instead (which is likely to be unusable in practice).
 
Back
Top