Work from RER
This commit is contained in:
parent
def30994a3
commit
881fe54ef0
1 changed files with 20 additions and 1 deletions
|
@ -429,7 +429,26 @@ addition of five heuristics. \qtodo{Why not use it then?}
|
|||
|
||||
\subsection{Corner cases}
|
||||
|
||||
\todo{}
|
||||
There were a few observed cases where the algorithm tends to be slower on
|
||||
certain configurations.
|
||||
|
||||
\paragraph{Split/merge trees.} A common pattern that tends to slow down the
|
||||
algorithm is split/merge trees. Those patterns occur when one wants to merge
|
||||
$n$ one bit wires into a single $n$ bits wire, or the other way around.
|
||||
|
||||
These patterns are pretty common, for instance when an opcode is run through a
|
||||
MUX tree to perform the requested operation.
|
||||
|
||||
Though, this pattern generates a lot of collisions in signatures. Indeed, for a
|
||||
tree of depth \eg{} 8, a node just below the root will need a signature of
|
||||
order 7 to have a different signature than another one at the same depth. With
|
||||
a signature of order up to 6, only other gates from the tree will be included
|
||||
in the signature when going down in the tree; the exact same gates will be
|
||||
included above the tree's root. Thus, nothing will differentiate one gate from another while
|
||||
the boundary of the tree is not reached (assuming the gates below the tree's
|
||||
leaves are not all the same; if so, more levels will be needed).
|
||||
|
||||
\todo{Figure describing the problem}
|
||||
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
|
||||
|
|
Loading…
Reference in a new issue