tag:blogger.com,1999:blog-3669809752172683097.post6082462228704773264..comments2024-02-08T04:04:28.385-08:00Comments on Cyclopedia Square: A Quick Look at svlibBryanhttp://www.blogger.com/profile/11394436715172971234noreply@blogger.comBlogger7125tag:blogger.com,1999:blog-3669809752172683097.post-52245377538792082202014-05-12T05:55:35.961-07:002014-05-12T05:55:35.961-07:00Trying svlib is easy. It is available on EDA Playg...Trying svlib is easy. It is available on EDA Playground: <a href="http://www.edaplayground.com/x/Uk" rel="nofollow">http://www.edaplayground.com/x/Uk</a>Anonymoushttps://www.blogger.com/profile/07007512505288807060noreply@blogger.comtag:blogger.com,1999:blog-3669809752172683097.post-29888124751049811532014-05-12T05:53:49.304-07:002014-05-12T05:53:49.304-07:00This comment has been removed by the author.Anonymoushttps://www.blogger.com/profile/07007512505288807060noreply@blogger.comtag:blogger.com,1999:blog-3669809752172683097.post-29805628289352338842014-05-12T05:52:57.895-07:002014-05-12T05:52:57.895-07:00This comment has been removed by the author.Anonymoushttps://www.blogger.com/profile/07007512505288807060noreply@blogger.comtag:blogger.com,1999:blog-3669809752172683097.post-24355170409654058892014-05-06T12:50:59.381-07:002014-05-06T12:50:59.381-07:00It's nice to see more momentum building up in ...It's nice to see more momentum building up in the SV open source landscape. I for one hope for more now that SV 2012 is out and getting more popular.<br /><br />Having the new "implements" and "interface class" features opens up the door to a rich collection of libraries the likes of Java's or C++'s. Hopefully there will be no more need for huge monolithic libraries like UVM that try to do everything...<br /><br />Libraries could be more focused and users would be able to use the right one for the right job. UVM could then focus only on core verification aspects instead of on providing container objects, file handling, message processing, etc. (basically what they've been working on for the 1.2 release).Tudor Timihttps://www.blogger.com/profile/11244280196830233694noreply@blogger.comtag:blogger.com,1999:blog-3669809752172683097.post-31100566091045207582014-05-05T16:29:25.891-07:002014-05-05T16:29:25.891-07:00Great comments, Jonathan. This is exactly the kin...Great comments, Jonathan. This is exactly the kind of dialog that we can all benefit from that I was talking about in my reasons for putting this on bitbucket or sourceforge or whatever. It's always great to hear engineers explain *why* they did something the way they did (and concerning if they have no reason why...).<br /><br />I completely understand not wanting to open up the development to the general public until you get it cleaned up a bit. I wouldn't call that arrogance, but maybe, taking pride in your work. Just don't spend *too* much time trying to make it completely perfect before going public :-)<br /><br />On why you haven't seen much interest yet, here's my story. About a year ago I wrote 346 lines of SystemVerilog code for printing out a nice ascii-art table of debug information with columns that adjust width according to the information that is in each column. The output is beautiful (if I do say so myself) but the code to generate it is...tedious. I have a feeling that svlib's String methods would have made that a whole lot easier and I'd love to try rewriting it to find out. The problem is, it works and I have other things to get done now. Someday soon I'll have a good excuse to try svlib (I'm pretty good at coming up with excuses to try new things), but it just hasn't happened yet.Bryanhttps://www.blogger.com/profile/11394436715172971234noreply@blogger.comtag:blogger.com,1999:blog-3669809752172683097.post-50541989025854397792014-05-05T15:40:11.589-07:002014-05-05T15:40:11.589-07:00Bryan,
First, thanks a ton for taking the trouble...Bryan,<br /><br />First, thanks a ton for taking the trouble to look at svlib and to raise these interesting issues. I really appreciate it; svlib was created in response to my own frustration with SV's inflexibility in certain areas, and I had hoped that others would find at least the core concept attractive, but there's been (to me) surprisingly little response.<br /><br />In essence you raise three key points. I'm quite sure that if you were to start picking over the details you would find much more to take issue with - there's plenty in there that I'm less than proud of - but let's stick with your specific comments at this stage.<br /><br />First, you suggest that the project should be opened on sourceforge or the like. Verilab has put a number of projects on bitbucket in the past, and we aim to do the same with svlib in due course. Open collaborative development is a fine aim. But I, personally, am not ready for it yet. I have some very strong opinions about the shape such a library should take, and I truly don't know how to shepherd or manage a collaborative project without jeopardising that vision. As soon as I have a <i>design</i> of svlib that I'm truly happy with, I will be more than willing to open the development to others who are likely to be far more skilled in implementation than I. This position probably sounds arrogant or selfish, and you must form your own judgment about that. The reality, though, is that I (foolishly?) committed to publishing svlib at DVCon in March, and I ran out of time to complete the specification to the level of maturity that I wanted. I have promised to make a much more mature release before very long, and as soon as that is done I shall open the whole thing on bitbucket.<br /><br />Second, you raise the old problem of wildcard package import. This question (and other closely related problems) exercised me mightily as I was planning svlib. In principle, in the abstract, I totally agree with you. However, svlib's avowed aim was to provide the most natural possible API for typical SV users. The use of the suffix "_pkg" to denote a package, for example, is now a very deeply ingrained SV idiom, legitimized by many published packages such as UVM. Fighting that idiomatic usage would have been a lost cause for a small minority project such as this. In a similar way, I recommended wildcard import in the notes because it is easy and familiar; sophisticated users are always free to use fully qualified names if they prefer. I have no defence against the accusation that this was a feeble capitulation, but sometimes pragmatism (and sensitivity to the mindset of one's target audience) is appropriate.<br /><br />Finally, you question the decision to put everything in a single package. Clearly this decision gives rise to problems of scale, and (like the package naming and import problem) it's a question that cost me quite a lot of sleep as I planned svlib. However, I believe I've at least partly alleviated the problems by coralling most of the interesting functionality in classes, using static methods where appropriate. This decision means that users who care about such things can, for example, do all their regex processing by importing only the Str and Regex classes from svlib if they so wish. My hope was that this architecture could go some way towards alleviating Chris Higgs's complaint about namespace pollution, which concerns me too, while also admitting a use model that will be more familiar to typical SV users.<br /><br />So, after all that somewhat defensive prattle, the executive summary is: guilty as charged, but I'm not trying to change the world; I'm just aiming to make it a slightly more comfortable place to live. I'll leave the crusading to others who are better qualified and more articulate about it.<br /><br />Once again, thanks for your interest and I hope I'll be able to deal with at least some of your concerns in the upcoming release (which I'm afraid I can't give a date for just yet, the day job somewhat getting in the way!).Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3669809752172683097.post-3309058400610464272014-04-30T07:42:00.371-07:002014-04-30T07:42:00.371-07:00Pretty much a +1 for all your feedback points from...Pretty much a +1 for all your feedback points from me.<br /><br />The industry <a href="http://stackoverflow.com/a/11235185/579887" rel="nofollow">"best-practice"</a> of habitual namespace pollution <i>really</i> irks me. The mindset also seeps into <a href="http://forums.accellera.org/topic/1725-uvm-12-feedback-required/#entry6581" rel="nofollow"> software written by HW engineers</a>!Chiggshttps://www.blogger.com/profile/13152037842428001898noreply@blogger.com