Architecture work is choosing the way the cell functionality is divided into sub-cells. It includes choosing both the sub-cell nature or function and the sub-cell arrangements. Since a real circuit can be complex, it can require a number of hierarchical levels. Depending on the hierarchical level the designer is dealing with, the objects nature can change significantly. Usually, top level objects are complex and they get less and less complex as the hierarchical level decreases. When it comes to deal with leaf cells, objects are electronic components.
Whatever the nature of objects, an architecture is required to define the kind of functions to use and the way the signals proceed between objects.
As design-levels increases, it gets more and more difficult to give general methods to address architecture work, but here are some guidelines:
For design levels 0 and 1, no architecture work is done at properly speaking as design is either copied as is for level 0 or re-sized for level 1.
However validating the architecture is strongly recommended at least for level 1. This consists in checking that the chosen architecture is potentially capable of achieving function and performances with an appropriate sizing. If not, it is not worth trying to size the circuit.
If architecture is not appropriate, design level should be increased to level 2.
For level 2 design, work starts from an existing architecture that is considered to be close to the target. Differences with the target should be identified and then:
Modification can be considered as a combination of suppression and addition, but it is kept as a separate option since it is often simpler. Again, validating the architecture is strongly recommended. If architecture is not appropriate, design level should be increased to level 3.
For level 3 design, work starts from several architectures that are felt as good candidates to be merged to reach the target. By assumption, none of these candidates can do the job alone; otherwise this would be level 2 design. Only synergy (the system does more than its components) can bring the functionality and the performance. The new architecture is based on synergy. It must combine the intrinsic qualities of the parent architectures so as to increase performance but it must also prevent or limit drawbacks from parents or from combining.This work usually requires several iterations.Every new solution must be validated. At this point, design validation is mainly checking functionality. Design validation often fails for early solutions, but the failure origin can give indications for improvements. During level 3 design work, methods from level 2 can often be successful (suppressing, adding and modifying). Again, validating the architecture is strongly recommended. If architecture is not appropriate, design process should be iterated.
Level 4 design usually results from failure in doing the job with level 3. For level 4 design, work starts from specification only, but previous attempts at lower design levels also give valuable inputs. And again, as soon as some ideas take shape, validating the new architecture is mandatory.
Among the three design steps, architecture is the most demanding, the one that requires the more skill. This is mainly because there is no well defined, step by step method. However, here are some indications on the way to address this design step.
Even though the number of topologies can be infinite, experience shows that some topologies occur more frequently. These frequent topologies are:
This is some sort of “degree 0” architecture, but for top cells it is not so rare. Circuits are sometimes just a collection of functionality that are not really related to each other. In this case, architecture results in a list of independent blocks. A good practice however is to wonder if some utilities or some sub-blocks could not be shared. And usually the digital control block and the power management block, if any, are common to all other blocks.
This is another very common situation. Signal processing, in a very general sense, is usually divided in steps. In this case, architecture commonly follows the same division and results in a processing chain built from successive blocks. If processing involves non-linear functions, the blocks are to be assembled in a well defined sequence. Swapping two blocks would result in a different processing. If processing only involves linear operators, the sequence might be changed without impact. However, true linear operation is a theoretical behavior that an actual circuit can only approximate to some extent. Then, the processing sequence must be defined carefully. The effects of non-linearity, the signal to noise ratio are some elements to consider when choosing the processing sequence.
The most frequent reason for choosing a looped architecture is accuracy. Most loops compare the output to the target and use the error signal to correct the output. As loops exhibit this capability to correct at least part of their own errors, they are usually accurate and robust.
As already stated, a good approach to the architecture work is to rank the specification items in such an sequence that it helps choosing the architecture. Ranking items properly is a difficult task that requires experience. Here are some indications to rank items properly.
Of course, since at this point we are dealing with architecture, only specification items that relate to architecture should be considered.
Items related to architecture are:
The first item in the list should be the most critical one. Critical aspect can be evaluated through discussions with other designers, by searching standard products performance or by looking at state of the art in published papers.
Architecture should be chosen in such a way that it addresses first the most critical specification item. It should be shaped by the first item. The selected topology should directly derive from the first item.
The other items should be ranked by order of critical aspect. They should be taken into account to refine the selected architecture.
Specification items mainly fall into 3 categories:
An approach that proved to be efficient is called the three layers model:
This approach can be iterated if intermediate layer appears too complex to be implemented in a single block.
Design usually starts with the most stringent input or output specification. It is then not so rare that design starts with the output stage…
If design has to start with the intermediate layer, iteration is often required to take into account actual I/O layers characteristics.
This scheme is to be iterated.
The V cycle refers to the idea that the design process consists in recursively splitting the circuit in smaller blocks.
As already stated, it is a good practice, whatever the design level, to validate the architecture prior to start sizing. The time it takes to validate architecture is negligible when compared to the characterization time and can potentially save lots of time by reducing the number of iterations in the loop.
In levels 0 and 1, validating the architecture is just checking that the cell functional modes and functionality cover the requirement. This can seem a bit formal, but can be done very quickly and can save lots of time if only a detail that was not foreseen is not compliant. This detail would appear after a significant amount of characterization work that would have to be done again later on.
In level 2, 3 and 4 architecture is modified so it must be validated at properly speaking. This is a difficult task that is mainly based on the designer’s capability. The method looks like mental simulation, some “what if” play. Result is a feeling that the architecture should do the job. This exercise requires a good experience in this field. It is, of course, simpler for level 2 and more difficult for level 4. A good practice for building the required experience is to start by level 2.Simulation can help, but running a simulation requires that the cell is sized and this is normally not the case.A possible solution is to size the cell roughly and to run a simulation to check if functionality is correct, whatever the performances are. Again, experience can help choosing a reasonable sizing, but, at this point, experience in the team can be shared with benefit. Asking a more skilled designer or even searching through literature or on the web can give valuable information. Attention must be paid, in this case, to the fact that the boundary between functionality and performance is not very clear. Making several simulations with different sizing sets can help.