comp.lang.vhdl

"Andy" <jonesandy@comcast.net> wrote in message news:68c74a06-bdd3-49c8-934a-9166d8b2e68b@w34g2000hsg.googlegroups.com... > On Nov 14, 12:31 pm, Mike Treseler <mike_trese...@comcast.net> wrote: > > I use variables for one main reason: they behave like the code reads: > they update immediately. Signals turn sequential code into "pseudo- > sequential" code, and I don't like that. There, I said it. > OK. Generally I don't like that variables change their meaning (because they've been assigned to and update immediately) when they are assigned to in several places in a long hunk-o-code with all kinds of paths through it. Of course nobody writes such code ;) My bigger gripe is the lack of history though. >I tend > to use source level debuggers and self checking features (assertions) > more than waveforms, but that's just the way I do it. I can certainly > see that if you rely on waveforms, and want to see past history, > variables can be a liability. Assertions don't tell you the root cause of what is wrong, just that a particular bad something has occurred. Many times one can tell simply by looking at what assertion failed and quickly deduce the root cause of the problem, but many times it's not so simple to see what incorrect logic led to the assertion having failed. In any case, the information that one needs to debug the failed condition lies in the past (i.e. the simulation history up to that point) not in the future so stepping through code or really anything other than analysis of the prior state of (possibly) everything in the design and testbench is required. Signals, variables and log/trace output files are the evidence that you use for that forensic analysis. Things that hinder that analysis typically slows down debug. Wave windows assist in the forensics as a good analytical tool, for investigating the scene of the crime (i.e. the failed assert). The two are complementary in that regard.....having said that though, I realize that the beginner will be debugging using waves alone (until they recognize the value of asserting darn near everything that they can instead). > > The downside of using entities for "information hiding" is that they > are an all or nothing solution: once you drop down into another > entity, there is NO shared visibility, unless you go completely global > which widens the scope too much (and many synthesis tools still don't > use anyway). I didn't mean to imply that if, after initial design creation, the realization sets in that some lower level entity has a 'need to know' about something and that the interface to that entity couldn't simply be changed to include that new signal and now the previously hidden info is known. No need to go global. > As far as "proper design", a state variable should only be accessed > and/or updated within a single process (actually, within the case > statement that defines the state transitions). To do otherwise makes > maintenance more difficult because the effects of changes to the state > assignments and transitions are not limited to the state machine. The downside to that is that the state machine code itself gets bloated and hard to maintain because you end up with lots of signal assignments intertwined with the various 'case' and 'if' branches typical of a state machine. In any case, a state variable is just another signal and is deserving of no more or less respect than any other signal or variable in the design. Changes to the code on any signal will have repercussions downstream, not just changes to state variables. Maintenance has more to do with readability then it does with dogma about scoping rules that apply to 'special' signals like state variables that inexplicitly do not apply to other signals. > > So let me clarify: The use of signals for state variables is not poor > design per se. The use of a signal for a state variable that is > accessible outside the state machine is poor design. A multiple screen long state machine filled with signal assignments in the various branches of the state machine code is a much poorer design (in my opinion), since it requires paging back and forth to understand the various reasons why something can be set or reset. I'd much rather have a 1000 line file where the logic defining any given signal can be viewed and understood within a single screen than having to wade through that same file searching for all the possible places that the signal might get assigned. > > Like it or not, there is a lot of benefit in the years of software > development standards that we can take advantage of to improve our > hardware designs. Just remember, somebody (maybe you) will have to > maintain that code some day... > Words of wisdom KJ