Chapter 8

Architecture

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.

8.1 Architecture catalog

Where can the designer find a list of available architectures?

  • A list of cells already developed in the team often exists. (And should exist!)
  • Patents and publications can provide ideas.
  • Data sheets of existing products can provide valuable data.
  • The web is a large source of information.

As design-levels increases, it gets more and more difficult to give general methods to address architecture work, but here are some guidelines:

8.2 Levels 0 and 1 architecture

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.

  • For level 0, work starts at design validation.
  • For level 1, work starts at sizing.

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.

8.3 Level 2 architecture

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:

  • Useless functionality should be suppressed.
  • Missing functionality should be added.
  • Different functionality should be modified.

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.

8.4 Level 3 architecture

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.

8.5 Level 4 architecture

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.

8.6 Choosing an Architecture

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.

8.6.1 Frequent topologies

Even though the number of topologies can be infinite, experience shows that some topologies occur more frequently. These frequent topologies are:

  • Independent blocks
  • Processing chains
  • Loops

8.6.1.1 Independent blocks

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.

8.6.1.2 Processing chains

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.

8.6.1.3 Loops

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.

8.6.2 Specification items ranking

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:

  • Accuracy and all related items like drift, rejections etc…
  • Robustness, reliability and portability.
  • Performances versus process capability.

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.

  • Should the first item be a good accuracy, it would suggest a large gain loop.
  • Should the first item be a demanding noise figure, it would suggest a large gain, low noise first stage.
  • ...

The other items should be ranked by order of critical aspect. They should be taken into account to refine the selected architecture.

8.6.3 The three layers model

Specification items mainly fall into 3 categories:

  • Input specifications
  • Output specifications
  • Transfer specifications

An approach that proved to be efficient is called the three layers model:

  • Input specifications define input layer. In turn, this layer exhibits some transfer characteristics.
  • Output specifications define output layer. In turn, this layer exhibits some transfer characteristics.
  • Transfer specifications, together with input and output layers transfer characteristics define intermediate layer

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.

3LayersModel

This scheme is to be iterated.

8.6.4 The V cycle

The V cycle refers to the idea that the design process consists in recursively splitting the circuit in smaller blocks.

  • Along the design phase, designers go deeper and deeper in the circuit hierarchy and the objects complexity lowers. As this process takes place, test-cells for validating the resulting blocks are developed. This process down to leaf cells is the left hand, downwards going half of the “V”. This design phase can be called “synthesis”.
  • Once every leaf cell is designed, the circuit is build with, “simply” replacing behavioral descriptions with actual designs. The test-cells that have been developed and used during the synthesis phase can be used to validate the actual circuit operation. This process up to the circuit top-cell is the right hand, upwards going half of the “V”. This design phase can be called “verification”.

VCycle

8.7 Architecture tools

8.8 Architecture validation

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.

8.8.1 Levels 0 and 1

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.

8.8.2 Levels 2 to 4

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.

8.8.3 Architecture checklist

compteur.js.php?url=%2FCuq%2BrY5pFc%3D&d