Runtime Analysis for Defect-tolerant Logic Mapping
on Nanoscale Crossbar Architectures
Yehua Su and Wenjing Rao
ECE Department, University of Illinois at Chicago, Chicago, IL 60607, USA
Email:{ysu8,wenjing}@uic.edu
Abstract—Crossbar architectures are promising in the emerging
nanoscale electronic environment. Logic mapping onto highly
defective crossbars emerges as a fundamental challenge and defect
tolerance techniques therefore become crucially important. In this
paper we investigate the most challenging part of the problem–the
exponential runtime inevitably involved in finding a valid mapping.
Runtime depends on solution density of the searching space. Yet,
the complexity of the problem is caused by the correlations in
the searching space. When defect rate is trivially low, such impact
is negligible. When defect rate increases, correlations drive up
runtime by not only decreasing the expectation of solution density,
but also increasing the standard deviation. Consequently, runtime
improvement can be achieved through means which reduce the
correlations in the solution space.
I. I NTRODUCTION
Nano-scale devices promise to overcome the fundamental
physical limitations of CMOS technology. One of the most
significant changes in the shift to nano-electronics is bottomup self-assembly fabrication [1]. Due to the fabrication limit
imposed by the self-assembly process, only regular structures
[2][3][4][5] can be manufactured. Particularly, crossbars have
been shown to suit well to the implementation of regular computational arrays such as programmable logic arrays (PLAs).
Self-assembly processes lower manufacturing costs at the
expense of reduced control over assembly of materials and
placement of devices. Without fine-grained control, the resulting
nanoscale devices will exhibit significantly higher defect rates
than that in current CMOS technology. The traditional approach
of rejecting defective chips in CMOS systems will no longer be
affordable since every chip will be defective in a nanoelectronic
system. New defect tolerance schemes need to be developed
and integrated in the design process to realize the potential of
nanoscale devices.
Crossbar-based nanoelectronic architectures have shown significant potentials. The regularity of crossbar architectures
intrinsically facilitates reconfiguration-based defect tolerant
system designs. Array based nano-architectures using programmable logic arrays were proposed in [6][7][8]. Defect
tolerance techniques are crucial to the design of crossbar-based
nano-architectures. A general defect tolerance approach based
on hierarchically sparing is discussed in [9], where circuits are
built by avoiding the faulty wires and switches. In [10], an
application independent scheme was proposed where a defectfree part of a defective crossbar was extracted as the functioning
resource. Work in [11][12][13] proposed defect models which
take into account defects in the logic mapping process.
Admittedly, no computationally efficient schemes exist for the
mapping problem due to its NP-complete complexity. However,
such a process has to be applied on every defective chip as
(a)
A
B
(b)
C
Configurable switch
Configurable edge
A
α
B
β
C
γ
α
β
γ
Close switch defect
Close edge
Open switch defect
Open edge
Broken line defect
Fig. 1.
(a) A nanoscale defective crossbar and (b) its bipartite graph model.
defect pattern varies. Therefore, developing functioning systems
based on defective nanofabrics neccesitates the investigation on
all the decisive factors of the mapping process: runtime, defect
rate, hardware redundancy and size of the target logic function.
II. P ROBLEM F ORMULATION AND C OMPLEXITY
A. Defective Nanoscale Crossbar Model
The manufacturing process introduces defects to both
switches and wires. Defective switches lose reconfigurable abilities by either being: (i) close or (ii) open, while wires may
suffer from breaks in the self-assembly process. Overall, these
defects affect the connectivity between orthogonal wires. One
example of a 3 × 3 crossbar with defects is shown in Fig.1(a).
Due to the defects, connectivity between horizontal and vertical
wires can be divided into three categories:
• Configurable (defect free): the switch at the crosspoint is
configurable to be on or off.
• Close: the crossing wires are stuck at each other, i.e. the
switch is permanently set at “on” state.
• Open: the crossing wires are disconnected, i.e. the switch
is permanently set at “off” state.
A defective crossbar can be represented by a bipartite graph
G = (U, V, E), where U , V are the node sets representing
the crossbar wire sets, and E is the edge set modeling the
switches. Every edge connects two nodes, one from U and the
other from V . A bipartite graph modeling defective crossbars
is denoted as a Crossbar Bipartite Graph (CBG). Based on the
categories of connectivity, there are three kinds of edges in a
CBG: configurable, close and open, as shown in Fig.1(b).
B. Logic Function Model
Just as the crossbar, a two-level logic function in the form
of SOP (sum of product) can be modeled by a bipartite graph,
based on the relationship between its variable set and product
set. Unlike CBGs, edges in an Logic Bipartite Graph (LBG) fall
into only two types: inclusion and exclusion. Inclusion indicates
a particular variable included in the product, and exclusion
indicates otherwise. Fig.2(a) shows an LBG for logic function
f = ab + bc.
(a)
Logic function f=ab+bc
a
ab
bc
b
c
(d)
(c)
(b)
Permuted LBG 1
Validity of edge mapping
Permuted LBG 3
α A
(ab) (a)
α
a
ab
c
bc
c
ab
B
(b)
β B
(bc) (b)
β
(ab)
b
bc
b
ab
b
bc
C
(c)
γ
(bc)
c
Inclusion edge
Exclusion edge
Permuted LBG 2
A
(a)
C
(c)
γ
Invalid
Valid
a
a
Mapping
Mapping
Fig. 2. (a) Bipartite graph model, (b) mapping rule, (c) an invalid mapping
trial and (d) a valid mapping trial.
C. Logic Mapping Model
The problem of logic mapping translates into a bipartite
graph embedding problem: specifying node correspondence
from an LBG to a CBG and mapping the corresponding edges.
Apparently, a configurable edge in a CBG can be used to
implement either an inclusion or exclusion edge in an LBG.
However, an inclusion edge in an LBG cannot be mapped onto
an open edge in a CBG, because an inclusion edge requires the
switch to be “on” while an open edge indicates a defect stuck at
“off”. Similarly, exclusion edges cannot be mapped onto close
edges. Thus, mapping rule is that among all six possible edge
mappings, such two edge mappings are invalid, as shown in
Fig. 2(b).
Fig. 2(c) shows an invalid mapping trial, as an inclusion edge
(c, bc) is mapped onto an open edge (C, β), and Fig. 2(d) shows
a valid one. For a given logic function and a specific crossbar, all
the mapping trials, i.e. different node correspondences between
the LBG and the CBG, compose the entire solution space.
Apparently, runtime in the searching process depends on the
solution space volume. In fact, the internal structure of the
solution space determines whether efficient searching schemes
can be developed.
1) Solution Space Volume:
The volume of the solution space is huge due to the tremendous number of node correspondence possibilities. Without loss
of generality, we can view the embedding process as first
permutating the nodes in an LBG and then directly mapping the
permuted LBG onto a (subset of ) CBG nodes directly. When
an LBG is of size n × m and a CBG is of size N × M , the
volume of the solution space, i.e. the number of all possible
!
M!
mapping trials, is (NN−n)!
(M −m)! . The volume of the solution
space therefore grows exponentially to the number of nodes in
both graphs.
The searching process inevitably takes a long time when there
are very few solutions in the solution space. The LBG/CBG
embedding problem by its nature is equivalent to a subgraph
isomorphism problem which is known as NP-complete. The
difference between them lies in that the validity of LBG/CBG
embedding problem is determined by the mapping rule, as
a configurable edge (representing a defect-free switch) is a
“wildcard” to map both types of edges in an LBG. Since the
complexity of validity checking stays the same, the LBG/CBG
embedding problem, as a variation of the subgraph isomorphism
problem, has the same computational complexity. Thus, finding
a solution for a given logic and a specific defective crossbar is
doomed with the challenge of prohibitive runtime.
2) Correlations in Solution Space:
Different mapping trials imply different ways of implementing the logic function onto the crossbar. In a defect-free crossbar,
any mapping trial would be valid. The presence of massive
×
Target CBG
Fig. 3.
Three permutated LBGs for the same logic function f=ab+bc.
defects imposes constraints and results in the invalidation of
most mapping trials. More interestingly, complex correlations
exist extensively among the mapping trials.
For instance, repetitive mapping trials occur when different
permutations of nodes in an LBG have identical edge distribution patterns. Fig.3 shows an example where two differently
permuted LBGs (1 and 2) become repetitive mapping trials with
the same edge distribution pattern.
More generally, correlated mapping trials exist widely: one
or more variable node(s) in an LBG are mapped onto the same
input node(s) in a CBG, and one or more product node(s) are
mapped onto the same output node(s). For example, LBG 1 and
3 in Fig.3 are correlated since variable node b and product node
bc are mapped onto same nodes in the CBG, making edge (b, bc)
being mapped onto the same targeting edge. Among correlated
mapping trials, failure of one mapping trial likely denotes the
failure of the other ones likewise.
Ideally, to search for a solution, only one instance among
repetitive mapping trials needs to be explored. Furthermore,
an invalid edge mapping likely indicates the failure of other
correlated mappings. Unfortunately, determining which LBG
permutations share a correlated edge distribution pattern is essentially a graph isomorphism problem, and repetitive/correlated
mapping trials are hard to be exploited so as to direct searching
process.
3) Randomized Algorithm:
Runtime is of crucial importance since it implies the expected
computational cost to find a solution for a desired logic function
and a given defective crossbar. Practically it is impossible to
explore the entire solution space, and only a very small part
of it can be explored. Mapping trials chosen randomly tend
to be less correlated and serves well as a reference point for
any future heuristic algorithm. Therefore, runtime analysis is
performed based on a randomized algorithm in the searching
process.
III. P ROBABILISTIC A NALYSIS ON RUNTIME
Essentially, the challenge of logic mapping is that the massive
defects impose constraints and make the searching process
impractically long. With the searching problem shown to be
NP-complete in nature [11][12][14], it is important to examine
its runtime. We analysis runtime quantitatively through the introduction of solution density: the percentage of correct mapping
trials in the entire solution space, when both LBG and CBG
are given. Obviously, high solution density leads to reduced
runtime.
A probabilistic approach is adopted to evaluate solution
density. Solution density expectation µsd and solution density
Benchmark xor5 of size 16x10
0.35
0.3
size ratio 1
size ratio 4
size ratio 16
size ratio 100
Solution Density Standard Deviation
Solution Density Standard Deviation
0.4
0.3
0.25
0.2
0.25
0.15
0.2
0.1
0.15
0.05
0.1
0
0
0.5
1
1.5
2
0.05
0
0
5
10
15
0.3
0.25
0.2
0.15
0.1
0.05
0
0
Defect Rate (%)
Fig. 4.
σsd for crossbars of different sizes, expressed as size ratio.
Fig. 5.
standard deviation σsd are examined to analyze the tradeoffs
among runtime, hardware redundancy and defect rate.
A. Solution Density Expectation
The solution space volume depends on (i) logic function size
(variable and product numbers) and (ii) crossbar size. When
both are given, the solution space volume is fixed. Defects
pose constraints in the mapping process and result in a drastic
decrease in the number of solutions in the solution space.
Naturally, more defects lead to lower solution density.
When a larger crossbar is used, there could be more solutions
existing in the enlarged solution space. When the size of logic
function increases, the number of solutions decreases in the yet
increased solution space. During the mapping process, large
logic functions inevitably hit into more defects at a mapping
trial, since more wires as well as switches need to be used.
Therefore, when the logic function size gets larger, we expect
µsd to drop sharply.
We examine quantitatively how µsd is affected by the impacting factors: defect rate, logic function size and crossbar size,
assuming that each switch has rc probability of being defective
for close and ro of being defective for open. The defect rate r
is then rc + ro . Since each switch has ro probability of being
open, it has probability of 1−ro working as a connected switch.
Similarly, each switch works as a disconnected switch with
probability of 1 − rc . For a logic function with density d (edge
ratio of inclusion to exclusion) and size n × m, each mapping
trial in the solution space is valid with probability:
pv = (1 − ro )dnm (1 − rc )(1−d)nm
(1)
where dnm is the number of inclusions and (1 − d)nm is the
number of exclusions in the LBG. Particularly, when ro = rc ,
pv = (1 − r/2)nm .
Since each mapping trial is valid with probability pv , µsd of
the solution space equals pv , i.e. µsd = pv . From Eq.1, we can
draw the following observations:
1) µsd drops sharply with defect rate increasing.
2) As logic function size increases, µsd decreases exponentially.
3) For a given defect rate and a desired logic function, µsd
is always the same regardless of crossbar size. In other
words, the solution space volume grows at the same speed
as the number of solutions grows when crossbar size
increases.
xor5 with size ratio 1
xor5 with size ratio 4
rd53 with size ratio 1
rd53 with size ratio 4
0.1
0.2
0.3
0.4
0.5
0.6
0.7
Solution Density Expectation
0.8
0.9
1
σsd of two benchmarks mapped onto crossbars of different sizes.
B. Solution Density Standard Deviation
Solution density standard deviation σsd reveals the variability,
which, in turn, indicates dropping of accuracy when using µsd
for runtime prediction.
In calculating σsd , enumerating solution density for each
specific crossbar is impractical due to a huge number of different
mapping trials in the solution space. Consequently, σsd is examined through simulations with the LGSynth93 benchmark set
[15]. To acquire solution density for each crossbar of different
defect pattern, 104 mapping trials are sampled randomly.
1) σsd varies with defect rate:
Fig.4 shows simulation results about σsd , where crossbar size
is expressed in size ratio (crossbar to logic function). As defect
rate increases, σsd increases and reaches its peak (roughly at
defect rate 0.7% for benchmark xor5), beyond which σsd begins
to decrease. When the defect rate is low, σsd is low as solution
densities are rarely impacted when only a few defects exist.
With increased defect rate, the impact of defect patterns on
solution densities becomes significant. However, if crossbars
contain a very high level of defects such that all the mapping
trials tend to be invalid, σsd decreases since all solution densities
are universally low.
In Fig.4, σsd is most significant at defect rate between
[0.2%, 2%], where the corresponding µsd is within the range
[0.2, 0.8], according to Eq.1. In fact, σsd is maximized (i.e.
σsd most sensitive to defect pattern) when the number of valid
mapping trials is comparable to that of invalid mapping trials.
2) σsd decreases with crossbar size increasing:
As is shown in Fig.4, large crossbars lead to low σsd
uniformly at all defect rate, and σsd reduction speed becomes
slower as crossbar size further increases. For instance, σsd
decreases significantly when size ratio varies from 1 to 4, while
the reduction is very limited for size ratio growing from 16 to
100. As crossbar size increases to infinity, σsd approaches 0.
The reason is large crossbars have less correlations in the
solution space. When a logic function is mapped onto a small
sized crossbar, the correlation in the solution space is very high,
because of the limited number of nodes in the CBG to be
chosen from. When crossbar size increases, the solution space
grows and the correlations in the enlarged solution space are
reduced because more wires are available to implement the logic
function. Due to the impact from the reduced correlations, larger
crossbar size decreases σsd .
3) σsd varies with logic function size:
Fig.5 shows how σsd varies as µsd increases. As µsd increases, σsd increases and culminates at the point where µsd
Benchmark xor5 of size 16x10
22
Runtime Expectation
TABLE I
S UMMARY OF INFLUENCE OF DEFECT RATE , LOGIC FUNCTION SIZE AND
CROSSBAR SIZE ON µsd , σsd AND RUNTIME EXPECTATION .
4
size ratio 1
size ratio 2
size ratio 4
size ratio 16
1/usd
20
18
16
14
12
3.5
Influence
µsd
σsd
Runtime
3
2.5
2
10
1.5
8
6
1
0.5
4
Fig. 6.
0.4
Crossbar Size %
constant
&
&
IV. S UMMARY AND C ONCLUSIONS
0.6
0.7
0.8
0.9
1
2
0.3
Defect Rate % Logic Function Size %
&
&
maximized when µsd =0.5
%
%
0.5
0.6
0.7
Solution Density Expectation
0.8
0.9
1
Runtime expectation for crossbars of different sizes.
is 0.5. When µsd exceeds 0.5, σsd begins to decrease. When
defect rate is fixed, σsd varies with different sized benchmarks.
This is because various logic function size leads to different
µsd . Though it seems that both logic function and defect rate
influence σsd , it turns out that σsd is uniquely dependent on µsd .
Fig.5 shows that at the same µsd , σsd is the same regardless of
the difference on in logic function size.
C. Solution Density Based Runtime Estimation
We use the number of mapping trials as the metric for
runtime. When the solution space is explored with randomized
algorithms, the expected number of mapping trials to hit one
solution is inversely proportional to solution density sd. Runtime
expectation is the expectation of 1/sd, which depends on both
µsd and σsd . We perform simulations to examine runtime
expectation and compare the results with the curve of 1/µsd ,
which can be obtained from Eq.1 directly.
Fig.6 shows runtime expectation results on benchmark xor5.
The following observations are made:
1) : As µsd increases, runtime expectation always decreases.
Obviously, higher solution density indicates it is easier to hit a
solution in the solution space. Consequently, low defect rate
leads to high µsd and reduced runtime. For the same reason,
small sized logic functions reduce runtime expectation because
of the high µsd .
2) : Large crossbar size leads to reduced runtime expectation.
The reason for this is large sized crossbars have small σsd
which, in turn, reduces runtime expectation. Ideally, if σsd
reduces to 0, then runtime expectation becomes 1/µsd . Since
correlations always exist in the solution space and σsd > 0,
1/µsd is the lower bound for the actual runtime, as is shown in
Fig.6.
3) : Runtime estimation based on 1/µsd can predict runtime
expectation accurately when crossbar size is above two times
larger than the logic function size. This indicates that correlations in the mapping trials become very low as crossbar size
increases to two times larger.
Overall, 1/µsd is the lower bound for runtime expectation as
runtime expectation depends on both µsd and σsd . As µsd can be
easily calculated, while variation in solution density captured by
σsd is imposed by high correlations in the solution space (caused
by high defect rate, large logic function size and small crossbar
size), 1/µsd can be used to predict runtime accurately when
correlations in the solution space are very low (by increasing
crossbar size).
In this paper, we focus on the runtime analysis for the logic
mapping process in nanocrossbar-based nanoelectronic systems.
As finding a solution takes prohibitive runtime when massive
defects exist in a crossbar, a probabilistic methodology is used
to analyze runtime. Solution density based runtime analysis is
presented and analyzed. Solution density expectation (µsd ) can
be easily calculated, while the variation (σsd ) cannot be derived
from equations. Influence of defect rate, logic function size and
crossbar size on µsd , σsd and runtime expectation is summarized
in Tab.I.
Runtime is driven up by increasing defect rate for two
reasons: (i) high defect rate leads to low solution density, and (ii)
high defect rate augments the impact of correlations in solution
space on runtime. As the size of logic function increases, the
runtime increases as well. However, runtime can be improved
by adding more hardware redundancy, as correlations among the
explored solution space are reduced with large-sized crossbars.
R EFERENCES
[1] M. Butts, A. DeHon, and S. C. Goldstein, “Molecular Eletronics: Devices,
Systems and Tools for Gigagate, Gigabit Chips,” Proc. International
Conference on Computer-Aided Design, pp. 443–440, 2002.
[2] A. Bachtold, P. Hadley, T. Nakanishi, and C. Dekker, “Logic Circuits with
Carbon Nanotube Transistors,” Science, vol. 294, pp. 1317–1320, 2001.
[3] Y. Huang, X. Duan, Y. Cui, L. J. Jauhon, K. Kim, and C. M. Lieber, “Logic
Gates and Computation from Assembled Nanowire Building Blocks,”
Science, vol. 294, pp. 1313–1317, Nov. 2001.
[4] M. Butts, A. DeHon, and S. C. Goldstein, “Molecular Eletronics: Devices,
Systems and Tools for Gigagate, Gigabit Chips,” Int’l Conf. on ComputerAided Design, p. 443C440, 2002.
[5] Y. Cui and C. M. Lieber, “Functional Nanoscale Electronics Devices
Assembled Using Silicon Nanowire Building Blocks,” Science, vol. 291,
pp. 851–853, 2001.
[6] A. DeHon, P. Lincoln, and J. E. Savage, “Stochastic Assembly of Sublithographic Nanoscale Interfaces,” IEEE Transactions on Nanotechnology,
vol. 2, pp. 165–174, 2003.
[7] A. DeHon, “Nanowire-based Programmable Architectures,” ACM Journal
on Emerging Technologies in Computing System, vol. 1, no. 2, pp. 23–32,
July 2005.
[8] A. DeHon and M. J. Wilson, “Nanowire-based Sublithographic Programmable Logic Arrays,” In Proc. ACM Intl Symp. on FieldProgrammable Gate Arrays, pp. 123–132, 2004.
[9] A. DeHon, “Array-Based Architecture for FET-Based, Nanoscale Electronics,” IEEE Transactions on Nanotechnology, vol. 2, no. 1, pp. 109–
162, 2003.
[10] M. B. Tahoori, “Application-Independent Defect Toleranceof Reconfigurable Nanoarchitectures,” ACM Journal on Emerging Technologies in
Computing Systems, pp. 197–218, 2006.
[11] W. Rao, A. Orailoglu, and R. Karri, “Topology Aware Mapping of
Logic Functions onto Nanowire-base Crossbar Architectures,” IEEE/ACM
Design Automation Conference, pp. 723–726, July 2006.
[12] T. Hogg and G. Snider, “Defect-tolerant Logic with Nanoscale Crossbar
Circuits,” Journal of Electronic Testing, vol. 23, pp. 117–129, Jun. 2007.
[13] M. Crocker, S. Hu, and M. Niemier, “Defect Tolerance in QCA-Based
PLAs,” IEEE International Symposium on Nanoscale Architectures, pp.
46–53, 2008.
[14] Y. Su and W. Rao, “Defect-tolerant Logic Mapping on Nanoscale Crossbar
Architectures and Yield Analysis,” IEEE International Symposiumon
Defect and Fault Tolerance (DFT) in VLSI Systems, Accepted, 2009.
[15] “Collaborative Benchmarking Laboratory,” 1993 LGSynth Benchmarks,
North Carolina State University, Department of Computer Science,1993.