Very important point and one difficult to do in practice. How many tools actually document (in detail) what the tool will do or not do. I find I need to do small example designs and look over th output of the place and route tool to figure out what is going on. Widh the vendors did this for me!
Anyone else have tools with detailed enough docs that they can tell ahead of time what is being done?
I remember the first time I synthesized an FPGA design for a real product. The synthesizer automatically came up with a one-hot state machine coding. Everything simulated fine. Unfortunately, this particular design did not have a well-formed clock when connecting or disconnecting the input signal, which would cause it to lose the one-hot code occasionally when reconnecting. Switching to a manual state coding that automatically recovered from bad states fixed the problem -- and saved logic cells in this case.
Lesson 1: Don't trust automatic state assignment. Some synthesizers make it hard to turn off automatic state assignment, but it's worth the effort.
Lesson 2: Don't trust simulation. It only simulates theoretical models, not the real world.
Lessons 1+2 combined and generalized: Know the limitations of your tools.
Remember when we had to do many of the FPGA tricks by hand? Register retiming, one hot state machines, if then else to mux conversions? Now the synthesis tools do all this for us. Hopefully tricks like the multiply by a constant will get folded in too. Just depends on how common the need is for these tricks I guess.
Maybe there should be a 'list' of tricks that users suggest would be good to put into synthesis tools. Perhaps via a discussion thread on Programmable Logic Design Line?
@Kris: Pretty cool math...I wonder whether they teach something like that in vlsi classes...
I'd be interested to knwo that myself -- but I fear not. When I started out, everyone knew and "swapped" tips and tricks like this -- it was key to making programs run as fast as possible when you were limited in terms of memory size, clock frequency, and the fac tthat CPUs too multiple cycles to do anything.
Magazines like BYTE were always publishing stuff like this... I love this stuff
@Brian: There's some nice material about constant division on the companion website for "Hacker's Delight"
I was going to mention that book Hacker's Delight -- it's a great book -- lots of useful tricks in it. I just now found there's a second edition (the link above) -- I have th efirst -- I'll have to add this second edition to my wish list :-)
A Book For All Reasons Bernard Cole1 Comment Robert Oshana's recent book "Software Engineering for Embedded Systems (Newnes/Elsevier)," written and edited with Mark Kraeling, is a 'book for all reasons.' At almost 1,200 pages, it ...