In the log 124. TAP timing & simulation I encountered a strange situation : the simulation would appear to take much longer than expected. This occurs after elaboration and during the first wait of the driving process.

This did not appear before because I think 2 factors played together for the first time :

• The design has grown and reaches about 100 gates, the largest I've tried so far. But this shouldn't be an issue by itself because the MUX64 is quite fast to sim.
• This if the first time I use a discrete flip-flop (a pair of NOR2) which could create undefined behaviours at start-up. But this shouldn't be a problem because the situation is already handled, right ?

Unfortunately I'm not able to trace what happens exactly but here are some tips :

• Make sure this is not an elaboration issue. A simple report lets you trace when and where the delay occurs. And normally, the total runtime should be directly proportional to the workload so change the iteration count for example.
• Check all the parameters of the initial values of the signals, either during declaration and in the testbench.
• Avoid undefined states and logical loops, and shield/split the units from them (gating/enabling data helps)
• Use different versions of the source code : change the architecture, try with a behavioural implementation, or the "simple" gates library.

In practice, the last tip can be a good compromise : it's not as fast as a behavioural model but less heavy than the "full trace" that is the default option.

However the "full trace" and "simple" libraries don't cohabit well but the design flow could require them both, depending on the level of analysis to perform. I have chosen to add a "simple" sub-directory in the latest version, where the homonymous version is built separately from the "full trace" version. Scripts using GHDL can then select which version is used on a case-by-case basis, depending on the requirements, by selecting the right path.

For the #YGREC8 this saves some seconds and uses more room but this is necessary because the tracing version can't analyse properly the sequential gates for now.