Archive for October, 2007


On the Importance of Micro-Architecture

October 24, 2007

This post will be a bit different. I will try to tell you about my philosophy on how to approach a design, hopefully I am able to convince you why I believe it is right, and why I believe this approach makes one a much better designer (at least it worked for me).
So if you are looking for special circuits, cool tricks or design tips, you won’t find them in this post.

Back in the 1990s, when I started in ASIC digital design, I used to get a task, think about it a bit and then wanted immediately to rush, code and synthesize the thing. My boss back then practically forced me to write a micro-architecture document. This in essence meant to give a precise visual description of all pipeline stages, inputs, outputs and a rough idea on the logic in between (one need not draw each gate in an adder for example).

I hated it big time. I thought it was so obvious and trivial. Why the heck do I need to have a list describing all inputs and outputs? it’s anyways in the code. Why do I need to have a detailed drawing of the block with pipeline stages, arithmetic operations etc? it is also in the code. Well I was wrong, very wrong.

Only when working on a large project you understand how much the time invested in writing a micro-architecture document pays off. Doesn’t matter how proficient you are in VHDL or Verilog, it is not easy understanding what you did 3 months ago, it is easier looking at a diagram and getting the general idea in a blink. uArch also helps aligning different designers within a big project. It will help you optimize your design, because you will see all pipeline stages and you will get an overview on the block. you will see where it is possible to add more logic and where it must be cut. If you are experienced enough, you could often detect the critical path before even synthesizing your code.

This is the main reason why you see mostly diagrams on this blog and not code. HDL code is a way to describe what we want to achieve, some people confuse it with the goal itself. In my humble opinion it is extremely important to make this distinction.

Bottom line – most will think it is time spent for nothing. From my own personal experience, you will actually design your blocks faster like that, with less bugs and other people could actually understand what you did. Try it.

On the next post I will give a rough template on how I think a uArch document should look like and what it should contain.


Null Convention Logic

October 11, 2007

It is extremely rare in our industry that totally new approaches for Logic circuit design are taken. I don’t know the exact reasons and I really don’t want to get into the “fight” between tool vendors and engineers.

Null Convention Logic, is a totally different approach to circuit design. It is asynchronous in its heart (I guess half of the readers of this post just dropped now).
It is not new and being currently pushed by its developers in Theseus Research.

They published a book, which I really recommend reading. It is not very practical with the current mainstream tools and flows but it is a very interesting reading that will open your eyes to new approaches in logic design.
You can get a good introduction to the book’s content by reading this paper. It is fairly technical and would need a few good hours to digest and grasp the meaning behind, especially given the fact that it is so much different than what we are used to – forget about AND, OR and NOT gates…

Book link here.


Pre-scaled Counters

October 8, 2007

It is obvious that as a normal binary counter increases in width its maximum operation frequency drops. The critical path going through the carry chain up to the last half-adder element is purely combinational and increases with size. But what if our target frequency is fixed (as is usually the case) and we need to build a very wide counter? Here come to the rescue a variant of the normal binary counter – the pre-scaled counter.

Pre-scaled counters are based on the observation (or fact) that in the binary counting sequence, the LSB will toggle in the highest frequency (half that of the clock when working with the rising edge only). The next bit in line will toggle in half that frequency, the next with half of the previous and so on.
In general, the n-th bit will toggle with frequency 2^(n+1) lower than the clock (we assume that bit 0 is the LSB here). A short look at the figure below will convince you.


We can use this to our advantage by “partitioning” the counter we wish to build. In essence we make the target clock frequency of operation independent of the counter size! This means that given that our clock frequency enables us to have a single flop toggling plus minimal levels of logic, one could in theory build am extremely wide counter.

If you really insist, the above statement is not 100% correct (for reasons of clock distribution and skew, carry collect logic of a high number of partition stages, etc.) , but for all practical reasons it is true and useful. Just don’t try to build a counter with googolplex bits.

The basic technique for a 2-partition is shown below. We have an LSB counter which operates at clock frequency. Its width is set so it could still operate with the desired clock frequency. Once this counter rolls over an enable signal is generated for the MSB counter to make a single increment. Notice how we also keep the entire MSB counter clock gated since we know it cannot change its state.

The distance between the filtered clock edges (marked as “X”) of the MSB counter is determined by the width of the LSB counter. This should be constrained as a multi-cycle path with period X when doing synthesis.


The technique could be extended to a higher amount of “partitions” but then we must remember that the enable for each higher order counter is derived from all enable signals of all previous stages.

An interesting variant is trying to generate and up/down counter which is width independent. It is not so complicated and if you have an idea on how to implement it, just comment.