On Thu, 2011-05-05 at 09:54 -0400, Martin Darwin wrote: >=20 > On May 5, 2011, at 7:22 AM, V G wrote: >=20 > >>=20 > > You could say the same for C. The whole point is to hide the low level > > stuff generated by the compiler. All I'm saying is, personally, I need > > to know what's being hidden so I can truly understand what's going on. >=20 > You will need to do lots of reading & experimenting then. =20 >=20 > With HDL you have to put trust in the synthesis tools to give the right o= utput. Understanding all the ways it optimizes your logic would be difficul= t. So what I write in hdl might look very weird in gates because of all the= optimizations. That said, sometimes the tools optimize in ways you don't w= ant so you have to constrain them. Post-synthesis simulation & verificatio= n is required to make sure the tools didn't make a mess.....i have this iss= ue right now!!! Lots of work to figure out the problem on large designs. Very true, in fact a common optimization that catches ALOT of users is state machines. State machines are rarely encoded the way the code states. The reason is there are various ways to encode a state machine that increases speed, reliability and area (grey coding, one hot, etc.). This USUALLY isn't a problem. But say you're working on a design that you can't simulate, for whatever reason (happens often enough on big designs). Those that use either explicit (compiled in) probes, or those that use a post synthesis probing tool (such as chipscope) will bump into the fact that the STATE variable will likely have ZERO relation to the code in question. For Xilinx users you can look at the report produced by the synthesis tool to determine what remapping was done. But if you forget this, things can get very confusing. FPGAs sure can be fun!! TTYL --=20 http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist .