I’ve come to a checkpoint in the construction of the AMBA IP library that’s packaged with MiniTB. After some part-time development over the last couple months, I have read/write support for ABP and basic read/write support for AHB (you can see the full list of supported features here). These are open-source masters and slaves that I developed using MiniTB.
Next step is AXI, which I’ll start later today. But before I go there, I wanted to share some lessons learned…
- I’ve said it before… and I’ll say it again: MiniTB is fast. For the AHB, I currently have 85 unit tests that run in under 3 seconds. I can run those tests several times a day – basically whenever I want – and I hardly notice the time it takes. Running tests sequentially within the same executable is far more productive than the 1 sim/test most are used to. Even if you’ve got a giant server farm, 3 seconds is probably less than the scheduling time.
- Even simple BFMs can have many different corner scenarios. So following my borrowed rule of “every test should fail for exactly 1 reason”, I wrote a MiniTB test for every corner scenario I could think of. I’ve found writing focused tests in MiniTB for every corner scenario to be an excellent way of thinking through the design of the BFM.. and discovering more corner cases :).
- With the AHB master, I started with an approach that eventually came to a dead end when I discovered I couldn’t handle pipelined reads. I chose wrong and the AHB required a redo. That’s the bad news. The good news is that I had roughly 60 passing unit tests at the time I had to start again. That meant I could change the implementation while along the way, I could run the unit tests for immediate feedback that the rewritten code was correct. In effect, the unit tests were an executable specification for the re-write. Not an ideal scenario, obviously, but having unit tests in place made for far less pain.
- People have asked me before why I don’t use assertions within MiniTB to do my checking. I’ve realized my answer: assertions are useless until they’ve been verified. If my intention were to build a set of protocol assertions, then I would unit test those assertions. If my intention were to build assertions and the BFMs, I’d probably build the assertions first, then use them in the BFM unit tests. But my intention was to build APB and AHB masters and I found validating behaviour with directed unit tests to be the most productive way to do that.
- I’m much more productive with TDD than without so that’s how I built the AHB and APB masters. While it’s not mandatory people use TDD with MiniTB, it still supports TDD nicely for those interested.
- MiniTB completes with a PASS/FAIL status but it doesn’t tell you how many tests you have. That got annoying once I had enough tests that log file was longer than my monitor is tall. Adding a N/M passing stat is now on the todo list.
In related yet unrelated news, I got an unsolicited email this morning from someone trying MiniTB on windows. He sent me some scripting updates that make that possible. Just in case he’s reading along… thanks Alan!
If you want to try MiniTB and build your own lessons learned, head over to the Getting Started page for details.
Now on to AXI…