chrisspear Posted September 12, 2013 Report Posted September 12, 2013 I just saw a presentation on UVM tips and it recommended to NOT use the uvm_field macros. Several companies have come out and said that these generate large, cumbersome methods that are hard to debug, and that you should write the methods yourself. IMHO, this seems like bad advice. Having written these methods for VMM, I find it error prone and a waste of time. Why spend 10-20 minutes creating these when the macros do it automatically? Once you waste an hour debugging the copy method when you leave out one variable, you stick with the macros. And how slow are these automatic methods? They never show up on the simulation profiler. This reminds me of when I used to change the oil on my car, and then left a rag on the engine that caught fire and cost me $200 to replace the O2 sensor, and could have ended up much worse. How much was I saving? It is your time that is the most valuable thing. Use the macros to save coding time and debug time. Spend your time on something creative like understanding Flits! Annossyenudge 1 Quote
chrisspear Posted September 12, 2013 Author Report Posted September 12, 2013 So what is your advice on what to use in UVM and what to avoid? Is uvm_do the best thing since sliced bagels, or Satan's spawn? (BTW - one of the leading reason for emergency room visits is sliced hands from trying to cut a bagel. It's trickier than it looks!) Chris Quote
lisakb1963 Posted September 12, 2013 Report Posted September 12, 2013 Chris, Here is an articleof "Why Macros Are Evil" & wait ... This wasn't the #1 article when I goggled "why macros are evil" (which I thought was pretty specific.) This was the 11th hit... http://verificationhorizons.verificationacademy.com/volume-7_issue-2/articles/stream/are-ovm-and-uvm-macros-evil-a-cost-benefit-analysis_vh-v7-i2.pdf Quote
Logger Posted September 12, 2013 Report Posted September 12, 2013 I think the performance issue have largely been addressed since that article was written. Probably still room for improvement though. My biggest problem with the macros is tracking down the source of compile errors. Practice has made me a lot better at divining the source of the macro based compile errors. And I do mean divining in the divining rod sense. I still end up commenting out large blocks of code and doing a binary search occasionally, because the error message says something like "UVM is from Venus and Engineers are from Mars". That said, I think I'm still saving significant time by using the macros. I've been pushing on my vendor to add UVM compile time linting that checks for proper macro usage. Some simple sanity checks like making sure the class name passed to the utils macro actually matches the class name, would pretty much eliminate any hassles. Quote
uwes Posted September 13, 2013 Report Posted September 13, 2013 hi, i fully agree with chris. we (cadence) do recommend to use the macros and have the verification engineer's brain focus on the "business logic" rather than on the creation of boiler plate code. It's important to note that macros and manual implementation do not contradict each other - one can start with the macros since they will lead to a fast creation of the env ... and if (and only if) the implementation isnt fast enough one could switch to a manual implementation of the particular slowdown problem. why do we have the macros in UVM? Just because they provide lots of code which cant be wrapped away in a different way in SV - think other languages dont have macros at all. So IF the underlying language would provide a path to capture the functionality hidden behind the macros today without using a preprocessor then i would rip out the macros due to the downsides they have. so essentially its a tradeoff today: implementation speed+maintenance cost vs runtime speed+macro-handling-downsides >Why spend 10-20 minutes creating these in addition this is not a one time shot. the manual implementation needs to be maintained ... and another side: the assumption that macros are slow because they literally expand into lots of generic code isnt necessarily true. the macro's expand into code because sv doesnt have another way to express this and yet they can serve as starting point for an optimization :-) /uwe Quote
chrisspear Posted September 13, 2013 Author Report Posted September 13, 2013 So what do you feel about uvm_do? These six little letters, the shortest UVM macro name, conceal the most complex code that generates and schedules transactions. It is a great way to hide these details from new users, and even experienced users can eliminate many lines of code with this tried and true macro. Think about it: every line of code you write is one more opportunity for a bug. Back in the days of the methodology wars, some vendors poked fun at VMM because it had 6 macros. Then OVM came out with over 200 macros and UVM has even more. Here is a useful one. How about a factory create macro to replace: drv = my_driver::type_id::create("drv", this); with just: `uvm_create(my_driver, drv); Quote
bhunter1972 Posted September 13, 2013 Report Posted September 13, 2013 I agree wholeheartedly. The advice to avoid the macros in 2011 was based on run-time and compile-time performance issues that were somewhat true with OVM and are less true today. By using the macros then, users are able to benefit from their incremental performance improvements over time without having to re-write large swaths of code. Even still, run-time and compile-time are important, but they are far less important than environment design and debug times. Here's my equation on their relative importance: DEBUG TIME > DESIGN TIME > RUN-TIME > COMPILE-TIME As for `uvm_do, it is important to know what each of the sequence-creating macros does and use the appropriate one. Use `uvm_create* and `uvm_send* when you don't need to randomize the sequence. Quote
dave_59 Posted September 13, 2013 Report Posted September 13, 2013 Hi Chris, To use macros or not is likely to invoke a language war along the lines of OOP vs AOP' strong vs weak typing, code indenting, and variable naming rules. There are good arguments for both sides, and I think it is important to understand both sides, and that there are extremes where one way clearly outshines the other. When I first looked at the code that was being proposed fro the OVM, there were the macros `vf, `vt, `f, `t, `ef, and `et. There were there because someone didn't like typing the extra characters for a virtual function (and I'll leave it to the reader what the other macros stood for). To me, use of those macros was clearly wrong. They obscure the code for the uninitiated reader, and you must understand the underlying keywords anyways. Plus, there are many IDE/template generators that will fill that out for you. You must remember that the majority of engineers writing UVM code today are new to it as well as new to SystemVerilog. And there is also a large number that go months without writing any code and have a tough time getting back into it. The `uvm_do macros are a mixed bag. Yes they do save you some typing, but you need to understand what is behind them to be able to choose the correct 1 out of the 16 variations of that macro anyways. Maybe one or two variations of the `uvm_do macro will save you some time, but you will loose that productivity trying to look them up in the reference manual to remember what the the others do. And the time you would save typing the 5 basic statements to send a sequence_item is inconsequential compared to the amount of other code you need to write in the sequence. The performance of `uvm_field macros have greatly improved since the OVM, but they are still not acceptable in my book. Most testbenches will easily make up the 10-20 extra minutes to enter the code over their lifetime. And there are IDE/template generators to cut the code creation time down as well. When used improperly, the field macros are as difficult to debug as not using them, just different kinds of bugs. And I can't tell you how many people forget that only certain kinds of fields, and only when used in an uvm_component do the auto-configuration. P.S. I hope your emergency room factoid was not from a recent trip to one - I know you've had more than your fair share of trips there. Quote
chrisspear Posted September 14, 2013 Author Report Posted September 14, 2013 Hi Dave and others, One thing puzzles me - everyone keeps mentioning having to debug the method generated by the field macros. Why? I have built the habit of adding variables to the field macros whenever I add them to a class, and have never had to step through the inner workings of these methods. Chris P.S. And thanks for your concern, but I have not broken anything in months! Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.