Hierarchical Synchronous Design

Hi,
In a hierarchical synchronous design methodology for FPGAs, is it
reqiured to register the outputs of all the modules in a hierarchy
(starting from the bottom) right upto the top module, or, is it
sufficient to register the outputs of the leaf hierarchical module (the
bottom-most module)?
Thanks
MORPHEUS

morpheus wrote:
> In a hierarchical synchronous design methodology for FPGAs, is it
> reqiured to register the outputs of all the modules in a hierarchy
> (starting from the bottom) right upto the top module, or, is it
> sufficient to register the outputs of the leaf hierarchical module (the
> bottom-most module)?

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

morpheus wrote:
> Hi,
> In a hierarchical synchronous design methodology for FPGAs, is it
> reqiured to register the outputs of all the modules in a hierarchy
> (starting from the bottom) right upto the top module, or, is it
> sufficient to register the outputs of the leaf hierarchical module (the
> bottom-most module)?
> Thanks
> MORPHEUS
> 
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.

valentin tihomirov wrote:
> I wonder how you can so easily speak about adding regisers somewhere in the
> circuit.

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.
2. Wastes flops
3. 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.

> 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.

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

       -- Mike Treseler

valentin tihomirov wrote:
> I wonder how you can so easily speak about adding regisers somewhere in the
> circuit. 
(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.
2. Wastes  regs
3. 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.

 > 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.

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

morpheus wrote:

 > To extend your suggestion, suppose i have 5 levels of hierarchy.

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.

 > My question is if I use your advice, I would be registering 'OUT' at
 > each level, is that what I should do?

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 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.

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