Appeal 2007-2701
Application 10/079,811
system must be able to simulate the individual modeled software and
hardware components of the DUT. The Examiner finds that to perform co-
verification, Hollander creates a hardware model where the external
software (which is not actual code as alleged by the Appellants, but is the
modeled embedded logic of the DUT) is run on the hardware model. Thus,
the Examiner concludes that Hollander teaches modeled hardware and
software components are simulated (Answer 9).
In the Reply Brief, Appellants contend that the Examiner
misunderstands Hollander. Appellants argue that the simulation of the DUT
as a unit is not necessarily the same as the simulation of individual software
and hardware components and their interactions in order to identify problem
sources and causes (Reply Br. 1). Appellants point out that the only
structure being tested in Hollander’s Fig. 1 is the single DUT 38. Thus,
Appellants conclude that Hollander does not teach modeling and testing
individual components and their interoperability (Reply Br. 2, ¶3).
After carefully considering the record before us, we find the weight of
the evidence supports the Appellants’ position. We begin our analysis by
noting that Hollander provides a method and apparatus for functionally
verifying an integrated circuit design (i.e., a device under test or DUT)(col.
4, ll. 44-45; see also col. 6, ll. 12-15). While Hollander does verify systems
that may include embedded software (col. 4, l. 49), we nevertheless find the
thrust of Hollander’s test generation system is directed to using various
Hardware Description Languages (HDLs) to construct and customize
verification tests as necessary to “simulate and observe a model of a
hardware device.” (col. 4, ll. 58-62).
6
Page: Previous 1 2 3 4 5 6 7 8 Next
Last modified: September 9, 2013