Hierarchical Synchronous Design

The only "requirement" is to meet static timing. The rest is style.

I prefer registers on all module outputs as this is how the standard HDL synchronous templates work. I also prefer to minimize hierarchy.

-- Mike Treseler

The main motive behing making the IOs of a module registered is to make the timing less dependent upon the internals of the module. So if you are making a module to interface with someone else's design, or you want to be able to floorplan the module without worrying as much about the routing delay between modules, then it's good to register the IOs. It's not a requirement, though, and having nonregistered outputs doesn't necessarily make the design asynchronous.

its better to register at each level if your resource demand isnt too much.

I wonder how you can so easily speak about adding regisers somewhere in the circuit. Wouldn't it change the functionality of the circuit (missing cycles)? Consider a MUX(S, A, B): you cannot just FF the outputs as this will break the contract inferring a cycle delay. I beleive, this issue must be elaborated in the "good design methodologies" literature. The non-experienced users like me would try both options in practice by a conditional, generic-controlled regstration.

It's more a question of where do you want to draw the boxes for a multi-module design. With no rules at all you will have a random collection of interfaces at the ports: out]--[in

1. reg to reg
2. flop to flop
3. reg to flop
4. flop to reg

1. Complicates timing.

1. Wastes flops
2. Is backwards from hdl synthesis which assumes but does not enforce synchronous inputs and creates registered outputs.

So I say type 4 only: All modules have plain inputs and registered outs.

Yes. Registering an output involves a one tick delay. Consider simulation to get each module lined up right.

-- Mike Treseler

(corrected reply) It's more a question of where do you want to draw the boxes for a multi-module design. With no rules at all you will have a random collection of interfaces at the ports: out]--[in

1. gate to gate
2. reg to reg
3. gate to reg
4. reg to gate

1. Complicates timing.

1. Wastes regs
2. Is backwards from hdl synthesis which assumes but does not enforce synchronous inputs and creates registered outputs.

So I like type 4 only: All modules have plain inputs and registered outs.

Yes. Registering an output involves a one tick delay. Consider simulation to get each module lined up right.

-- Mike Treseler

Thanks Mike, methinks that what you suggested is the right thing to do. To extend your suggestion, suppose i have 5 levels of hierarchy-A,B,C,D and E. 'A' being the top module and E being the leaf-level module. An output 'OUT' from 'E' needs to propagate to 'A' passing as output of 'D', 'C' and 'B' blocks. In this case, 'OUT' is an output of each module right from 'E' to 'A'. My question is if I use your advice, I would be registering 'OUT' at each level, is that what I should do? Thanks MORPHEUS

I'd rather suppose one or two. I don't use hierarchy for it's own sake. However, when reusing a substantial module already having a testbench, it is probably smarter to instance it than risk combining designs directly.

I don't really know what your are doing other than drawing boxes inside boxes. The fact that you are counting up output registers leads me to think that you might need fewer boxes with more logic in them.

-- Mike Treseler

I think the OP asked for a proper design demo on the single signal path example.

The OP asked:

The consensus of the replies was, yes if all else is equal, registering the outputs of all design entities (modules) is a good thing.

Yes, I passed on a 5 level hierarchy example. I prefer a two level hierarchy where the the top level contains only instances and wires. This eliminates the concern about how a level 5 output escapes to the top.

-- Mike Treseler