If you have read and studied enough in Micro Electronics and VLSI technology, you must have heard of Nick Tredennick. Nick Tredennick is the most important dude in VLSI technology. He was part of the design team which came up with Motorola 68000 and IBM System/370. Fortunately, I was able to read one great book written by him during course work on VLSI Architectures during ME in BITS, Pilani. The book is called Microprocessor Logic Design: The Hardware Flowchart Method. I mentioned about this book previously too. This book is my favourite book with respect Micro Processors. I read this book, re-read it and even based on it, designed a micro processor with three of my other friends. I keep referring to this book time and again because everytime I experience some situation @ work, I completely relate to a topic discussed in this book.
Recently, my colleague was impressing upon me about the importance of getting an all pass certification for the HDL Logic I wrote, from the different tools we use. My question was simple “I am proving it to you through boolean algebra that it works, then why are you pushing me to fix those little variable naming and readability warnings?”. His answer was the most regular answer “because the tool must give zero errors and zero warnings for your code!”. After a long and horrible discussion, I had to do it because it is a rule! Immediately after the discussion, I opened my copy of Nick Tredennick’s book and read the part about DAs.
Heres what Nick has to say about Design Automation:
Eventually, you will enter your design into computer files. Lots of people have tried to make this part “easier”. These people are called Design Automation (DA) experts. Designers work on designs and DA people work on automating design. As a designer, my view is that DA should support design, not be design. After I have designed something, I think “Boy, it would be nice if this part (of the way I design) were automated in this particular way.” But sometimes, I think DA people automate things and want designers to design in terms of inputs and outputs to their design tools. You may feel frustrated when you ask a DA person “Why doesnt your program let me do this?” and the response is “Why are you doing it that way?”
Imagine this: You start a new job at a company and on day 2 they say “Heres where you enter your logic – in our Humongous Design System (HDS).”
Surprised, you say, “But I’ve only had eight courses in digital design principles. How do you actually design a microprocessor? I mean … come up with the logic for something that complicated …. in an organized way?”
“Well, you partition the problem into manageable pieces,” they reply.
Stubbornly you ask, “But how do you know what the right pieces are?”
Perspiration is forming on your brow. They’ve found out. You were supposed to have learned this in one of those courses. But your host merely replies, “Oh, that’s easy, you just piece the logic together in structures that are good for this technology. They’re right here. See, here’s a sixteen-way NOR, and here’s a three-input NAND and ….”
You dont hear much of the speech. You have no choice : You must use HDS because it automatically verifies your logic; selects, places, and writes the circuits; and generates test patterns using a fault model that has been accepted countrywide. Besides, output from HDS is the only output manufacturing will accept. Period.
In case like this, designers start thinking of solving problems in terms of how to express the solution in a particular notation. They structure the solution out of only the conceptual constructs supported by that notation. (If the tool deos not support pass gates, guess what – no pass gates in the design.) In this way, DA becomes design.
This book is partly in response to the growing presumption that computers are an essential part of the design. They are not. I want to describe here the essence of logic design method.
Computers are not an essential part of this flowchart method. I think of computers as an expensive and awkward alternative to pencil and paper. Even so, I dont think all DA is bad. Where DA’s good, its very very good, but when its bad, its horrid.
This is taken from the Chapter 1 – Heres the deal of the book! Brilliant, isnt it? Very straight forward and elegant. The whole point is if you look at chip design companies today, they ask designers to design according to conditions put by the tools instead of making the tools work according to designer’s constraints! The continuous insinuations I hear in terms of writing tool compliant logic really would have made me go crazy, thanks to this book, I laugh about those insinuations and out of office, for hobby work, I still follow what Nick prescribes because tool is a tool, job could be done, albeit slower, without the tool!