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.