10-01-2018 03:42 AM
I am trying to come up with a verification method, and I have to choose between two methodologies: one is MyHDL, a python based verification, and the other is UVM based. We are also open to other methodologies, preferably ones that are not so different than the ones above.
I know UVM is a standard, but from what I hear - python based verifcation is gaining popularity (mainly due to the simplicity and the comfort that python offers) - and also - the MyHDL open source library is well maintained.
We have done similar projects with both methodologies. We do FPGA design (not chip design). We do numerous projects, that might not be so different.
Mostly we use 3rd party simulators - I didnt get the impression that the vivado simulator supports any of the methodologies (does it?).
10-01-2018 07:30 AM
You can use scripted flows with Vivado Simulator including UVM as per User Guide 900.
Also there is the following example that was included in a prior forum post.
Check out the following post:
10-02-2018 11:22 AM
@amaccre thank you for the quick reply.
Mainly I wished to hear about advice regarding the choice between the two methodologies - as we are trying to come up with the best solution to our team.
I'll add the following - lately we have found ourself in a situation of a relatively high turnover, but so far we manage to successfully teach new employees the methodology we needed at the time.
thank you in advance.
10-02-2018 08:27 PM
As you notice that UVM is standard and MyHDL is still growing.
There is one forum where you can get help on MyHDL "http://discourse.myhdl.org/".
I personally used MyHDL a lot; and with the help of the forum created a webpage https://myhdlguide.readthedocs.io/en/latest/. While creating this webpage, I notice that they have certain admin-issues (which you can see the forum posts) which does not allow to fix the issue immediately. You may need to tweak the MyHDL in your local repository as you proceed with it; otherwise MyHDL is a very good choice as we have all the power of Python.
Also, in MyHDL we can convert the code into VHDL and Verilog easily. Note that, MyHDL does not generate modules but the complete code in a file.
Lastly, UVM is a standard methodology.
10-03-2018 03:56 AM - edited 10-03-2018 03:59 AM
Given that, in your previous post, you said your team is currently a VHDL based team.
Have you looked into any VHDL Verification Methodologies? such as UVVM or OSVVM?
Both of these would require some learning, but wouldnt require the complete re-training you would need for SV, or the Mammoth task you would need for UVM (I would suggest getting someone in who understands UVM, rather than trying to do it all yourself from scratch as beginners)
MyHDL may be good if you are all willing to learn Python (which might not be a bad thing anyway). I have not used it in anger, but have seen others use it solo within teams. The problem with this is their work tends to get lost and unless others understand it, will suffer bit rot. You probably need everyone on board to get decent usage out of it.
PS. VHDL Can be used to create some of the useful features that SV has out of the box, with a little work (like Queues, linked lists, dynamic arrays etc - but dont expect to be able to do it in Vivado).
10-06-2018 08:44 AM
I have a few questions:
1. Do you really think that using a verification method based upon the language you know is that much of an advantage? And if so - why? To me it sounds like the time it knowing and working with more than one HDL is not that big.
2. We all have some experience in both SV (design and verification) and VHDL (not VHDL for verification - just for design), as well as python (for verification). So we are right now trying to come up with the very best methodology for the next few years, and stick to that.
3. We mostly use the vivado simulator (which we are very happy with) for quick TBs during system integrations.
Having said that - and based on your experience:
What are the advantages of SV verification methods over python (or even VHDL)? I got the impression that UVM is an industry standard, and I'm wondering why. To me it seems that using python is a big advantage, with all of python's capabilities, and ease of picking up, which makes methods like cocotb or MyHDL preferable. I should mention that we preferably use python for automation, which makes cocotb and MyHDL look easy to integrate with different automation environments.
10-06-2018 12:04 PM - edited 10-06-2018 12:17 PM
Before I go to the questions, lets first go back away from deciding on a specific language and just talk about verification as a concept. Verification can be done in pretty much any language, by anyone. The best verification is done when you plan for verification at the start of the project at the same time, or before you do the design. From a top level, you should know what the system needs to do, so you should also be able to work out what verification environments are needed. When Verification is done as a secondary task, it inevitably slips are there will be time pressures to get a project finished, so tests wont always be defined, regression jobs wont be created and the pressure to just "get it on hardware and fix it later" will mean you'll spend all (or more) of your "verification time" inside chipscope just getting the thing working. And then in 6 months time some corner case will pop up that needs you to drop everything and get it fixed, but you dont have the testbenches ready to go, and you end up back in chipscope.
In my engineering career, the projects that have worked the best (ie. least hardware debug and least bugs returned) have been when we have had a dedicated verification time working alongside a design team. This way they are both involved from the start, the design team do their usual thing, but the verification team design the tests and treat the design as a black box. So they can set all the environments up before the design is ready and can start testing the moment any design is ready. This doesnt replace designers writing testbenches (blocks shouldnt make it to the verification without some testbenching first), but it certainly helps catch corner cases and gives a 2nd pair of eyes over the design specs.
The problem with the above is that it often costs more in man hours and project time up front. But it does make it easier to plan and less likely to slip. Usually, when verification isnt planned in at the start, the project will slip and debugging is slow, being done in chipscope, and will usually slip further than you would have had with up front verification.
With that in mind - it doesnt matter what langauge you go with - what is most important is that the whole team, including management, have bought into this, knowing that project planning will have a higher up front engineering cost in either later delivery date or higher man hours.
As for the questions:
1. It helps because it is less to learn. You forget what you dont use. With my experience above with separate verification team (using SV/UVM) and design team (using VHDL) I know that most designers really hated trawling through the layering and abstracting you get with SV/UVM. They werent writing even synthesisable SV on a daily bases so often had forgotten the basics. You then have the problem when the members with the SV skills leave, your verification expertise may also go with it. It will depend on how you have the team set up.
2. Its hard to say exactly. But I went on an SV course when I had a lot of experience with VHDL design and verification. It took me 6 months to be fully comfortable navigating around the existing UVM testbenches, but I wouldnt have wanted to set one up from scratch. We had libraries of local verification libraries (etheret, SRIO, AXI etc) already written. This would be a huge undertaking for a virgin UVM team. I had support from very experienced verification engineers. Without this support, I have no idea if Id have got as far as I did.
3. Vivado simulator has very poor VHDL 2008 support, struggles with a lot of SV and no Python support. Whatever verification path you take, you're going to need 3rd party simulator licences. If you're designing in VHDL and verifying with SV you'll need mixed langauge, then for SVA and UVM, you'll need more expensive licences again. Using something like OSVVM or UVVM you could stick with a single language licence (these both require good VHDL 2008 support). I am now personally using OSVVM. I work in a small team of VHDL engineers. There is little verification experience, but OSVVM is a bit like a tool box that can be added a little at a time to existing tests. UVVM is kind of a whole methodology that has to mostly be taken in one go (its an attempt to copy UVM methodology in VHDL - I feel if you wanted UVM, why not just use UVM). Both are open source but are maintained and tought by training companies (SynthWorks and BitVis).
I think UVM is industry standard only because it has been around so long (the things it is based on go back to 2001). So its built up a following and has been used mostly for ASIC verification until the last few years. But while it is full featured and extremly capable the licences are expensive, as are the engineers that use it and it can be very heavyweight to introduce for smaller tests. Hence why those looking for smaller jobs have come up with different methodologies (some of which can actually cover most, if not all, of what you can cover with UVM). Going back to the start of this post, verification is all about proving that the design meets the specification, which can be done in many different ways.
I have very little python experience, so cant really comment on MyHDL or CocoTB directly (other than seeing others "having a go" with them).
I would say go with what everyone is happy to go with. Unless everyone is happy there will be resistance that will hinder you in future.