Category Archives: Engineering

Tool switches

@boldport asked:

What are your #FPGA design space exploration techniques?

which he expands upon:

“Design space exploration” is the process of trying out different settings and design methods for achieving better performance. Sometimes the goals are met without any of it — the default settings of the tools are sufficient. When they’re not, what are your techniques to meet your performance goals?

Yet again, the 140 character constraint leaves me with things unspoken….

Working where I do in the automotive market means that it’s not good enough to miss timing by a few picoseconds and say “it’ll be fine, ship it”. If you miss timing, you /have/ to make it pass.

My experience with tool tweakery is that it gains you a 2-5% timing improvement – which can be enough to meet timing when you just missed.

The downside is that usually, when you go and change the design (due to the requirements changing yet again), you find yourself with a slightly different 10ps timing violation which maybe this time the tools can’t get around. Or maybe with a change one of the seed parameters, it will, after some trial runs.

So, I’ve given up on that approach as being too variable. It’s much harder to give estimates of when something will be ready when timing closure is a “tweak the knobs a number of times and see”.

What I do now is rework things until it meets timing easily. That way, it’s likely to stay that way.

Techniques include:

  • Pipelining – adding registers
  • Constraining unconstrained integers – occasionally, the synthesiser doesn’t figure out the range an integer variable or signal can take on, so needs telling. This is happening less and less as synthesis tools get cleverer.
  • Simplifying algorithms

This give me a much more predictable build process. It’s seen me fine, even for a nearly full Spartan3 device with some logic running at 160+MHz DDR.

Of course, if you are right up against the limits of the device speed and you’ve pipelined and constrained and everything else, then tweaking tool parameters is all you have left – anyone in that position has my sympathies!

FPGA Q&A area on stack exchange

For those who don’t know Stack Overflow, I recommend having a look round. Web Forums (Fora?) done right. A sensible and easy way of rating questions and answers and questioners and answerers. For the right subjects, a goodly group of knowledgeable people answering them… But mainly on a software theme. Sadly (for me :) FPGAs and HDLs only come up occasionally (but I try and answer when I can). Enter Stack Exchange:

The best place (IMHO) for FPGA advice currently is Usenet. comp.arch.fpga and comp.lang.vhdl have a group of experts who are happy to help with well-asked questions. But the signal:noise ratio is dropping of late. My guess is that this is because new users tend to go for web forums which tend to be single vendor and don’t have the variety of experts that the newsgroups do. And, for some reason, they seem to attract poorly phrased questions.

Stackoverflow and its sister Stack Exchange are designed for the web forum generation, and do it well.

There’s a group up for creation on stack exchange related to FPGAs, but it needs a bunch more people to express interest before it can come into existence. I’d like to see it flourish, and if it comes to reality, I’ll be checking the questions regularly, and maybe posting a few of my own.

(Mind, I’ll always hang out on comp.arch.fpga as well though)

Executable comments

Comments in code are very useful. But not as good as executable comments…

I write image processing code at work. One of my FPGAs has a piece of code which generates a signal which has a hard-coded number of clock cycles that it is low for. This is fine in the application – it never needs to change, it just has to match what the camera does, and the software programs that up the same every time.

So, in the (detailed) comments for this module, I made a note that this was the case. However, recently, I needed to change the value that the software sends to the camera to give a bit more time for the processing. So I changed my VHDL tests so that the represented the new value the camera would be using, and ran my regression suite. No problem, all works fine.

We pushed the code into the FPGA and tried it on the bench. All works fine except that this particular signal doesn’t match the camera any more. And my testbenches don’t model the chip at the other end of the link in that level of detail. What I should have done, as well as writing the comment was add some code to check that it was being obeyed.

If I assert something must be true in the comments (ie This signal should match this other signal timing) then I should add some code to tell me off if I make it untrue! The word assert is key – use a VHDL assertion to make sure that the two signals match:

process (clk, camera_sig, mysig) is
  variable camera_low, mysig_low:natural:=0;
begin — process
  if falling_edge(mysig) then
    assert camera_low = mysig_low
    report "Camera sig timing doesn’t match mysig timing"
    severity error;
  end if;
  if rising_edge(camera_sig) then
    camera_low := 0;
  end if;
  if rising_edge(mysig) then
    mysig_low := 0;
  end if;
  if rising_edge(clk) then
    if camera_sig = ’0′ then
      camera_low := camera_low + 1;
    end if;
    if mysig_low = ’0′ then
      mysig_low := mysig_low + 1;
    end if;
  end if;
end process;

The key assert is at the top of that process. The rest simply counts clock ticks while the relevant signal is low. You could also do it without the clocks and capture the time at the start and the end of the pulses to compare…

And that’s an executable comment!

How many languages does an engineer need?

Much of an electronic engineer’s life is spent in front of a screen. And much of that time is creating and debugging designs using some textual format or other. Arguably, even humble Excel falls into that category of “tools”. At some point many electronic designers will end up performing schematic capture and maybe PCB layout – but much of the design is already done by then.

So, what languages are used?

Having no knowledge of C programming will hamper one’s ability to bring up new board with a microprocessor of any description included on them – and it’s a rare system which has no micro at all! [Forth][] has several vocal proponents, but it’s definitely a minority language.

If you do logic design then either VHDL or (System) Verilog is a must – very few schematic tools exist in this space. And the tools with which these designs are developed, tested and debugged tend to be controlled by the tool control languageTCL. TCL is a weird language – to me it feels dominated by the form of the source code, woe betide anyone who puts a brace on the wrong line, or omits a space after what (in most other languages) would be a separator charactre in its own right.

Personally, I’d rather use Python if writing scripts, and indeed I use Python frequently throughout my various roles, for quick hacks of data analysis through to a prototype stereo-vision algorithm. Perl is another good choice for quickly hacking together the tools that you need. I find it too easy to write unmaintainable code in Perl however, which is why I have moved to Python.

Matlab is another must for engineers who have to deal with numbers (like signal processing!). Or one of its free competitors Octave or Scilab. comp.dsp regular Vladimir Vassilevsky is fond of ironically saying “Matlab does all thinking for us” when a request is made for help implementing a system which has been designed in Matlab without thought for the real world. However, in the right hands, Matlab is a powerful tool for investigating engineering trade-offs very quickly. I’m fond of using Matlab to investigate algorithmic possibilities, always keeping in mind what the end implementation might look like (in software or hardware). Once I have a good algorithm prototyped, I can then create Matlab implementations which are degraded in various ways to emulate how my real implementation will look. For example, using limited bit widths rather than double-precision numbers. Or approximate square-root algorithms rather than numerically precise answers. If the degraded algorithm differs too much from the golden starting point, I need to undegrade it some! Once this is done, it is then useful for testing my real implementation. If it differs from the prototype degraded algorithm, I’ve done something wrong in the implementation somewhere.

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!

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