Deisgn partitioning issues

A single design module is simplest if there is no reason to split it. Connections between modules are tedious.

Possible reasons to partition include multiple module instances, testbench complexity, multiple designers and the availability of specifications.

-- Mike Treseler

Hi Neo,

There is no unique way to do this. However, there are some general guidelines for methodological approach, which I am always using in my team. The list is very long, but the basic considerations that the blocks are partitoined according to are:

(*) complexity (mostly in terms of logic density) (*) independency in terms of logic functionality (say, TX & RX flows are always in the different blocks) (*) ability to debug, that is, if you bring a block to waveform, there would not be too many signals (no need ot scroll and group too many signals) (*) always keep not more than 1 clock per module (*) in one module, there should be no mix of logic and instances (*) clock and reset generation should be handled within a separate block.

These are not mandatory, i.e. the design still could be working if the above are not considered, but this represents a good design practice in terms of organized team work & design integrability & interoperability, especially if you are designing something for several applications and the changes are only in several places, than a correct and profound thinking about the partitioning could ease the future work.

Hope this helps.

Vladislav

Another reason is to partition into things you think would make sense to re-use, so I like to partition at boundaries where I could take a partition and move it into another project with minimum interface change.

-- Pete

So basically it all points to ease of use and functionality. thanks for your answers