Wednesday, 28 December 2011

Domain name at last

I've finally bought the domain name Links using the old blogspot address will redirect to

Making EE Times more readable

I enjoy reading some of the technical articles on the EETimes website. This is the best site I have found for professional electronic engineers (excluding the IEEE). Unfortunately, reading anything on the EETimes website is excruciating. There are so many adverts and flash videos that even on a fast computer the pages take ages to load, and scroll latency can be measured in minutes. Sadly, this means I quite often put off visiting the site, even though I'm sure there are interesting articles to be found.

Earlier this year I learned about Readability

I downloaded the app and now find reading EET articles far more inviting and a lot quicker. Here is an example of how much of a difference Readability makes

Try reading this:

Now try making it readable:

I know neither of these concepts are novel, but for anyone else that was put off reading EETimes by its crappy website design, hopefully this might change your mind.

Sunday, 11 December 2011

Replacement sky for overcast photo

Having recently stayed at the magnificent Down Hall I wanted to take a photograph which did the house and its surroundings justice. Unfortunately it was overcast so my photos were all a bit dull. This was the best I could get:

I wanted to do two things. Remove the tissue from the front lawn and replace the sky with one more fitting. Apparently this is trivial in Photoshop, but I only had access to GIMP. So I found this well written tutorial and followed it. After about half an hour of playing around I produced the following result.

It is a little bit rough and I'm not sure the brightness/contrast of the sky matches the photo too well, but I'm pleased!

Sunday, 4 December 2011

Asynchronous behaviour of synchronous counter

I've written before about performing timing analysis with Altera's FPGA design software, Quartus II. I find Analysing timing for a complex FPGA project far from easy. Distinguishing which timing violations are important and which ones are the result of poorly constrained paths can be tricky. Sometimes a path in your design may report negative slack, but you don't care, because you only latch the signal on every other clock, or perhaps because that path's timing just isn't important to your design.

That being said, once you've identified that a timing violation that does concern the performance of your design it can be tricky to understand what the Timing Analyzer is saying. Typically all you have to go on is a source and destination 'node' in your design and the corresponding clock domains to which the violation concerns. Earlier this week I came across a timing violation which at first glance didn't make any sense.

The analyser flagged a negative slack time from the q[] output of a counter (marked as 'source') to the register 'reg' marked as 'dest' in the diagram below:

This didn't make any sense. There is no combinational logic joining the source to the destination. At least it looks that way on first inspection.

If you consider the behaviour of the synchronous counter, the cout output is dependent upon the direction of the counter. When counting upwards, cout goes high when the counter value is '1111..11' however when counting down, cout goes high when the count reaches '0000...00'. This implies that cout is  directly, and combinationally dependent upon updown.

The reason for the timing violation now makes sense, the combinational path joining source to dest now includes 'path_a' and 'path_b' in series, it is as if the path continues from the updown input through to cout output of the counter.

This path includes quite a lot of combinational logic, hence the failure to meet timing requirements. It is these sorts of subtleties that make resolving timing issues far from trivial.

Source: "lpm_counter Megafunction User Guide", Altera, 2007, retrieved 4th December 2011, URL: