With all the requests by scientists and the government for money lately, here, finally, is something you can get from the government… for free. Yes, that’s right, applicable scientific and engineering tools that are the result of NSF funding that your taxes paid for and that you can actually use… today… really! If, like many engineers, you find yourself in need of the functionality Mathematica provides, but you’re reluctant to ask your boss for the money to purchase a license, sagemath might be for you. Sage provides a lot of the same functionality that Mathematica does, and you don’t have to pay for it. You can even use this Python based tool without making an install, with a cloud based version of Sage. If you’ve ever played with Python, then you’re already most of the way to using Sage.
Functional Verification and Software Development, Brothers from a Different Mother
Verification Process Advise In Disguise as a Software Development Forum
Do you need better insights on improving your verification processes? Are you running into issues like these?
- Revision control nightmares
- Blindingly and debilitatingly fast feature changes from marketing
- Difficult to follow information trails on code verification history
- Days and hours spent fixing broken designs after “No one changed anything” or only added “Correct By Design” fixes
As it turns out, the software industry had all these problems and beat the functional verification automation gang to the punch by several years. While there is an ever growing cadre of EDA tools available to cure the above woes, there are also simple process steps, identified by the software folks, (as well as my own humble offering along with Shankar Hemady and a host of industry luminaries), that you can take to improve things now. One of the beautiful things about the software industry is that lots of its denizens love to share. Checkout http://programmers.stackexchange.com, a forum that regularly discuss project management, debug, and code refactoring, (known as ‘garshdarned feature creep’ in our lingo). As I was writing this, a question appeared on the board:
Develop in trunk and then branch off, or in release branch and then merge back?
Sound familiar? Don’t let the name of the site fool you. It’s not about how to program, it’s about how to be a programmer. In addition to revision control, you’ll find posts about how to best change code, without destroying the code around it, and, equally importantly, with the advent of UVM, questions about design patterns, (think factory pattern). Don’t worry about having to share in kind. Stackexchange seems to have realized that your design, and or processes may actually be unique and beautiful snowflakes, in which cases, they’re quite happy with folks ‘just’ reading.
In the same vein, Coverity, a software verification company regularly publishes a software testing blog. If you remember to squint your eyes, and say to yourself, ‘hardware systems’, or ‘embedded systems’, everywhere the blog says ‘software systems’, there are many good tricks and processes just waiting there for the taking.