Code Ordering In Hardware Description Languages

HDLs may be the most flexible and widely used programming systems that have relaxed code ordering. In an HDL, one can write A=B+C;B=1;C=2 and get the answer A=3. In most such HDLs it is illegal to assign to a variable twice within the same clock phase.

HDLs exhibit relax code ordering because the actual hardware gates and wires they model evaluate according to signal propagation, not according to the order they are written down in a list.

If all of the statements in an HDL program are simple gates, then it is always possible to sort the statements into an order for which sequential valuation would be correct. It just may be clearer to group logically connected statements together.

However, if some of the statements in an HDL program invoke modules, then circular dependencies may arise between the modules. E.g. module 1 may take as input A and K and produce as outputs L and X. module 2 may take as input B and L and produce as outputs K and Y. there is a circular dependency between module 1 and module 2 even though there is no actual circular dependency.

module 1: L=A+1; X=K

module 2: K=B+1; Y=L

Sure: you could change the module partitioning. But, doing that may obscure the logical relationship between the statements in the module.

Related: in computer hardware simulators, when written in languages like C/C++, many people have observed fragility - as changes are made to program, code often needs to be moved between modules, and new modules created, in order to preserve sequential ordering. One occasionally sees things like Module1.Phase1(); Module2.Phase1(); Module1.Phase2(); Module2.Phase2() - arbitrary partitioning just to work around the problems of sequential code ordering.

If module 1 and module 2 are exploded, then their statements can be sorted into a sequential order. This can always be done in a hardware description language, if the hardware is finite.

It may be awkward to explode the modules. Some simulators employ relaxation, evaluating all modules, then reevaluating any modules as inputs have changed, repeating until no module inputs have changed. This can be expensive.

Some simulators sort the modules, looking at the explicit dependencies between modules. This does not handle circular dependencies, but allows the modules to be specified out of order.