delay so
Fine. ASCII, preferably.
Ick! Too much chance for screw-up. A simplified OO approach is far safer.
Agreed. State machines are simple. A common structure helps even more.
Explain?
Ick! Reuse is important to me. Once I have a module correct I can concentrate on other things.
Ick! (see above) How do you do FPGAs? Single file? I try to limit VHDL to 1000 lines. If a module is over that it's not designed well enough. Assembly I limit to about two pages, a quarter of which tends to be header/descriptive comments.
I like MAKEs, though I've been converted to CVS, and the like. I'll likely fight it for my next project though.
Again, macros, functions, procedures, etc. are not only good for reuse, they're important for organization and readability.
Agreed! It's hard enough to keep documentation and code in step when they're in the same file. External documentation should be in the form of a high level functional spec rather than implementation. Where this breaks down is in very large designs, though the concept still holds, just pushed further down the food chain.
This si fine for very simple tools. It gets much harder with FPGAs and impossible with ASICs. The larger the project the harder this is to do. How do you handle schematics (one reason I favor VHDL over schematics, BTW)?
Agreed! Mostly so I remember what I did the next week. ;-) I also do the high level comments and flow (written in the header) before the code so I can organize the work to be done in that module.
Not sure I follow exactly what you're saying here. In general, manufacturing puts the boot loaders on the boards when they're made. The functional code is flashed at final assembly (during ICT, ideally).
Nothing is wrong with the end. I don't agree with all of your means to that end. Your process certainly WOULD NOT work in a large project. Though I've had my fill of large projects. As an engineer, they suck.