Monthly Archives: February 2010

How much hierarchy do I need?

When building a large FPGA design, there comes a point when you have to decide where to put the dividing lines between modules. Deciding where to draw the boundaries is a bit of an art.

You don’t want too much hierarchy as then each module does only a tiny task and it’s hard to get a big picture view on the functionality. If you put everything into one big blob then you get lost amongst it all, there’s no opportunity to reuse code, and it’s a nightmare to test and debug.

Another consideration is the number of signals you have interconnecting modules. If those signals also dive deep into the hierarchy, then each time you add a signal to one of the module interfaces, you have to replicate it and wire it up in each container module on the way down.

Pushing signals around

In terms of routing signals around, records can help with that: if you want to push an extra signal down the hierarchy, you just add it to the appropriate record and recompile. However, make sure you package things together sensibly – by function is often good. Not just “all the signals to this entity go in one record” as then you can end up with all the signals in the design in one big record!

A more modern approach is presented by Sigasi who have developed the Eclipse IDE into a VHDL development environment. This (as I understand it) allows you to drill signals through the hierarchy semi-automatically. I say “as I understand it” as when I tried the tool in its beta phase, it couldn’t copewith some of the apparently unconventional (but legal) HDL I write!

Testing

Testing is a huge part of the effort of any design, and this presents quite a useful way to ascertain where to split things up. “Things that are easy to test” is a good boundary in my experience.

For example – say you want an image processing system which does an “edge detecting” function, then does a “peak detecting” function on the results of that and then a “assign (x,y) coordinates to each peak we detected” function.

You could stick all of that into one big block of code, but when you get the wrong x coordinates out of the far end, you have no idea which sub-function went wrong.

Instead you design three blocks, one for each of the functions, and test them individually. You can get each part right in isolation.

Then when you wire them all together and test it, and it doesn’t work first time (!), you only have to look at the higher-level integration to see what’s wrong.

It may sound like more work this way (writing testbenches doesn’t feel like productive work, especially when you’re starting out). But once you get proficient (which means practicing, just like playing your scales on the piano :), you can do the testing very quickly because each individual test is fairly simple. And you can push your design to all the corner cases, which is much more difficult when testing the whole thing all together.

Scales for engineers

If you’re a professional (or even proficient amateur) musician, you practise your scales, and other exercises daily. This keeps your muscle-memory alive for the basics of how they will move when playing pieces of real music.

What’s the equivalent for engineers?

Maybe mouse and keyboard exercises to keep our hands as productive as possible? Or mental exercises to ensure that the critical facts we need to know are to the fore. I can’t imagine not being able have instant recall of my multiplication tables for example.

And of course this changes over time as more and more mundane stuff is done for me by my computer. A couple of decades ago, a logic designer would have been using Karnaugh maps on a daily basis. I remember “using” them at university in coursework, and I got better, the more I did them./ But I haven’t used them in the real world, despite doing logic design for well over a decade!

Update:
And I’ve found someone with (at least) one answer

About…

This site contains my ramblings on a variety of subjects. No doubt much of it will relate to the design of electronics, especially FPGAs. There’ll likely be some music related items and some mention of Linux also.

You can read a bit about me and engineering in my [interview with EEWeb].(http://www.eeweb.com/spotlight/interview-with-martin-thompson)

You can contact me by email if you like.

Music

At primary school, I learned to play recorder (along with most of my generation). I learned by descant and treble recorders, which have slightly different fingerings (or rather the same fingering produces a note which is a fifth higher on one than the other). This stood me in good stead for the clarinet, which I picked up at secondary school – this usees treble recorder type fingering in the “lower register” and descant type fingering in the “upper register”. There’s a few weirdo fingerings in between (sometimes called the “middle register”), but they weren’t hard to pick up. After that I got a tenor saxophone, which made great noises, but was way too loud to practice in the house! So now I play a wind controller…

You blow down it and it sends messages like “play a C at half breath”. Then the synthesiser picks this up and models the physics equations of whatever instrument you set it to and out comes some sound. It allows me to practise with headphones, which is good for all concerned. And to play a variety of instruments – we’re short of a bass player at church, so I often play bass guitar or cello on it. Which can be a bit of a challenge, as neither of those instruments needs lungs normally, so you tend to run out of breath quite quickly. I’m getting better at snatching breaths in between phrases.

The windcontroller I play is a Yamaha WX5, talking to 2 VL70ms, one of which has the Patchman Turbo ROM in it, which sounds much better than the default sounds.