4 ms·
You're absolutely right, but I feel the author's statement refers to internal logic only. I/O bring up is certainly more tricky - a reset that goes through the
by lvoudour 9y ago
You're absolutely right, but I feel the author's statement refers to internal logic only. I/O bring up is certainly more tricky - a reset that goes through the FPGA is not a guarantee of proper power-on behaviour anyway, you need to deal with the pre-configuration state as well.
But since we're here talking about resets I'll give my own 10 cents for beginners:
- Do not reset EVERY REGISTER. Before you apply reset to a register ask yourself: does this piece of logic really require an initial state? This is especially true for data registers where the validity of its data is signaled by a separate control signal. Rule of thumb, reset the control signal not the data value - or better, design your circuits so that you only need to reset control signals (state machines included). Excessive use of resets puts a burden on the routing tools, can negatively affect your timing and prevent certain optimizations
- adwn 9y agoI used to think the same way, but I've since changed my mind and consider it now premature optimization: It's totally okay to do it in a just-for-fun project, but otherwise the usual rules for optimizations apply: 1) Only do it once you know if and where it is actually necessary and 2) measure the impact of your changes. Especially for beginners I would recommend that you reset all your registers, because errors due to uninitialized signals are a pain to debug, and they might not be visible in simulation. For example, if r is uninitialized and has the value 'U' (or 'X'), then if r = '0' then ... else ... end if; will execute the else-branch in simulation, but might take the then-branch in a hardware.