IN THE UNITED STATES PATENT AND TRADEMARK OFFICE
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`
`
`
`
`
`
`
`
`Trial No.:
`
`
`
`
`
`
`
`
`
`
`IPR 2012-00042
`
`Atty. Dkt. No.
`
`
`007121.00004
`
`
`
`
`
`
`
`
`
`
`
`
`In re U.S. Patent No. 6,240,376
`Application No.:
`09/127,587
` Filed:
`July 31, 1998
` Issued:
`May 29, 2001
`
`Alain Raynaud
`Luc M. Burgun
`
`Patent Owner: Mentor Graphics
`Corporation
`
`METHOD AND
`APPARATUS FOR GATE-
`LEVEL SIMULATION OF
`SYNTHESIZED
`REGISTER TRANSFER
`LEVEL DESIGNS WITH
`SOURCE-LEVEL
`DEBUGGING
`
`
`Inventors:
`
`For:
`
`
`
`
`
`
`
`
`DECLARATION OF WILLIAM D. DAVIS
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`I, WILLIAM D. DAVIS, declare as follows:
`
`1.
`
`I am a member of the Bar of the State of Texas, and I am attorney
`
`with the law firm of Davis and Associates located in Dripping Springs, Texas. I am
`
`registered to practice before the U.S. Patent and Trademark Office in patent cases,
`
`and my registration number is 38,428.
`
`
`
`1
`
`Mentor Graphics Corp. 2033
`Synopsys, Inc. v. Mentor Graphics Corp.
`IPR2012-00042
`
`

`

`Declaration of William D Davis
`
`
`
`
`IPR 2012-00042
`
`2.
`
`I have personal knowledge of the facts set forth in this declaration,
`
`and, if called to testify as a witness, could and would do so competently.
`
`3.
`
`I was previously employed as an associate with the law firm of
`
`Blakely Sokoloff Taylor Zafman, LLP (“BSTZ”). During my employment at
`
`BSTZ, I was responsible for drafting and filing U.S. patent application no.
`
`09/122,493 (which issued as U.S. patent no. 6,336,087, hereinafter the “ ‘087
`
`patent” or “ ‘087 patent application” as context requires) and U.S. patent
`
`application no. 09/127,584 (which issued as U.S. patent no. 6,240,376, hereinafter
`
`the “ ‘376 patent” or “ ‘376 patent application” as context requires) in the role of
`
`outside counsel for Mentor Graphics Corporation. The ‘376 patent application was
`
`filed July 31, 1998. The ‘087 patent application was filed on July 24, 1998. The
`
`detailed disclosures of these two applications are substantially the same.
`
`4.
`
`I submit this declaration to provide evidence of: (1) the conception of
`
`the invention(s) disclosed and invention claimed in the ‘376 patent by the inventors
`
`Alain Raynaud and Luc M. Burgun (hereinafter the “inventors”); and (2)
`
`reasonable diligence by the inventors and myself in reducing the invention claimed
`
`in the ‘376 patent to practice from prior to June 16, 1998 to the filing of the ’087
`
`patent application. At the time of drafting and filing the applications, I understood
`
`the inventors were employed by Meta Systems, a division of Mentor Graphics
`
`Corporation.
`
`2
`
`MG 2033
`
`

`

`Declaration of William D Davis
`
`
`
`
`IPR 2012-00042
`
`5.
`
`I have maintained in my possession, since the dates of original
`
`receipt/creation to the present day, attorney-client privileged material and attorney
`
`work product material related to the drafting and filing of the ‘087 patent
`
`application (hereinafter the “Archived Material”). I know this material to be
`
`related to the ‘087 patent application, because I have maintained the material on a
`
`“ZIP” floppy disk within a directory titled “002282.P030,” which was the BSTZ
`
`attorney docket number for the ‘087 patent application.
`
`6.
`
`The Archived Material includes an electronic copy of a document
`
`having the file name “BILL.DOC” with a “date modified” timestamp of January
`
`5, 1998. A printed copy of the document is attached hereto as Exhibit A. The
`
`BILL.DOC document includes unformatted text that substantively matches a
`
`printed article also in my possession entitled “Gate Level Simulation of
`
`Synthesized RTL Designs with Source Level Debugging,” which identifies Alain
`
`Raynaud and Luc Burgun as the authors (hereinafter the “Burgun Article”). A
`
`printed copy of the Burgun Article is attached hereto as Exhibit B. I recognize this
`
`Burgun Article as the inventors’ disclosure of the invention originally provided to
`
`me by Mentor Graphics, which I used as a basis for drafting the ‘087 patent
`
`application.
`
`7.
`
`The Archived Material includes an electronic copy of an email
`
`drafted by me to Brian Dalio, the Mentor Graphics and Meta Systems contact
`
`3
`
`MG 2033
`
`

`

`Declaration of William D Davis
`
`person for the ‘087 patent application. The electronic copy of the email has the file
`
`IPR 2012-00042
`
`
`
`name “dalio.doc” with a “date modified” timestamp of January 9, 1998. A printed
`
`copy of the email content is attached hereto as Exhibit C with privileged portions
`
`redacted. As indicated in the redacted copy, I acknowledged to Mr. Dalio the
`
`receipt of the Burgun Article, which occurred at least by January 8, 1998, the date
`
`I last modified the dalio.doc file.
`
`8.
`
`Several draft iterations the specification for ‘087 patent application
`
`are further included in the Archived Material. The draft iterations of the
`
`specification were authored solely by me based on the Burgun Article, with edits
`
`provided by the inventors and me over a time period spanning prior to June 16,
`
`1998 to the filing of the final specification on July 24, 1998. The edits are marked
`
`with underscores to indicate added text and strikethrough to indicate deleted text.
`
`Using the “tracked changes” function of Microsoft WORD, each edit is labeled
`
`with the author of the edit and a timestamp of when the edit was made. Edits made
`
`by the inventors are identified as being authored by “Meta Systems” and edits
`
`made by me are identified as being authored by “BSTZ.” The files containing each
`
`iteration further include a “date modified” timestamp indicating the date and time I
`
`last modified the file by editing the draft specification (with or without tracking
`
`changes) or incorporating previous edits made as regular text, i.e., removing the
`
`tracking information.
`
`4
`
`MG 2033
`
`

`

`Declaration of William D Davis
`
`
`
`
`IPR 2012-00042
`
`9.
`
`The timestamps in the draft iterations of the specification indicate that
`
`the inventors and I worked in 1998 to complete the draft specification at least on
`
`May 28 (Thu.), June 12 (Fri.), June 18 (Thu.), June 23 (Tue.), June 25 (Thu.),
`
`June 26 (Fri.), June 29 (Mon.), June 30 (Tue.), June 31 (Wed.), July 1 (Thu.),
`
`July 2 (Fri.), July 6 (Mon.), July 20 (Mon.), and July 21 (Tues.). Specific draft
`
`iterations of the specification including these time stamps are as follows:
`
`a.
`
`An electronic copy of a draft specification of the ‘087 patent
`
`application having a file name “P030rev9.doc” (hereinafter the “rev 9
`
`specification”). The rev 9 specification included previous draft iterations of
`
`the specification having edits by the inventors and myself that I incorporated
`
`as regular text, i.e., no tracked changes). The rev 9 specification was last
`
`modified by me on May 27, 1998, as indicated by “date modified”
`
`timestamp of the file.
`
`b.
`
`An electronic copy of a draft specification of the ‘087 patent
`
`application having a file name “P030rev9.1.doc” (hereinafter the “rev 9.1
`
`specification”). The rev 9.1 specification, an amended version of the rev 9
`
`specification, includes edits received from the inventors, which are time
`
`stamped May 28, 1998 and June 12, 1998. The rev 9.1 specification was
`
`last modified by me on June 18, 1998, as indicated by the “date modified”
`
`timestamp of the file.
`
`5
`
`MG 2033
`
`

`

`Declaration of William D Davis
`
`
`
`
`IPR 2012-00042
`
`c.
`
`An electronic copy of a draft specification of the ‘087 patent
`
`application having a file name “02282.p030 application 11” (hereinafter the
`
`“rev 11 specification”). In the rev 11 specification, I reviewed and
`
`incorporated many of the inventors’ edits time stamped May 28, 1998 and
`
`June 12, 1998 between the period of June 12, 1998 and June 18, 1998. I
`
`further made additional edits, which are time stamped June 18, 1998. The
`
`rev 11 specification was last modified by me on June 18, 1998, as indicated
`
`by the “date modified” timestamp of the file.
`
`d.
`
`An electronic copy of a draft specification of the ‘087 patent
`
`application having a file name “02282.p030 application 12” (hereinafter the
`
`“rev 12 specification”). In the rev 12 specification, I reviewed and
`
`incorporated previous tracked edits in the rev 11 specification and made
`
`additional edits, which are time stamped June 23, 1998. The rev 12
`
`specification was last modified by me on June 23, 1998, as indicated by the
`
`“date modified” timestamp of the file.
`
`e.
`
`An electronic copy of a draft specification of the ‘087 patent
`
`application having a file name “rev13b.doc” (hereinafter the “rev 13b
`
`specification”). The rev 13b specification includes the June 23 1998 edits
`
`from the rev 12 specification and additional edits I made, which are time
`
`stamped June 25, 1998. The rev 13b specification was last modified by me
`
`6
`
`MG 2033
`
`

`

`Declaration of William D Davis
`
`
`
`
`IPR 2012-00042
`
`on June 25, 1998, as indicated by the “date modified” timestamp of the file.
`
`f.
`
`An electronic copy of a draft specification of the ‘087 patent
`
`application having a file name “luc” (hereinafter the “Luc specification”).
`
`The Luc specification includes additional inventors’ edits, which are time
`
`stamped June 26, 1998 and June 29, 1998. The Luc specification was last
`
`modified by me on July 6, 1998, as indicated by the “date modified”
`
`timestamp of the file.
`
`g.
`
`An electronic copy of a draft specification of the ‘087 patent
`
`application having a file name “alain” (hereinafter the “Alain
`
`specification”). The Alain specification includes additional inventors’ edits,
`
`which are time stamped June 30, 1998, July 1, 1998, and July 2, 1998. The
`
`Alain specification was last modified by me on July 6, 1998, as indicated by
`
`the “date modified” timestamp of the file.
`
`h.
`
`An electronic copy of a draft specification of the ‘087 patent
`
`application having a file name “marked-up luc:alain diff” (hereinafter the
`
`“Luc/Alain specification”). The Luc/Alain specification includes a
`
`comparison of the Luc specification and the Alain specification made by me,
`
`for my review of the inventors’ edits. The differences between the Luc
`
`specification and the Alain specification are indicated as edits made by me
`
`and time stamped July 6, 1998. The Luc/Alain specification was last
`
`7
`
`MG 2033
`
`

`

`Declaration of William D Davis
`
`
`
`
`IPR 2012-00042
`
`modified by me on July 6, 1998, as indicated by the “date modified”
`
`timestamp of the file.
`
`i.
`
`An electronic copy of a draft specification of the ‘087 patent
`
`application having a file name “rtl_debugar.rtf” (hereinafter the “RTL
`
`_debugar specification”). The RTL_debugar specification includes a
`
`combination of previous edits by the inventors and me made from June 23,
`
`1998 to July 2, 1998, and additional edits that do not indicate the author or a
`
`time stamp. The RTL_debugar specification was last modified by me on
`
`July 20, 1998, as indicated by the “date modified” timestamp of the file.
`
`j.
`
`An electronic copy of a draft specification of the ‘087 patent
`
`application having a file name “P030.rtf” (hereinafter the “P030
`
`specification”). The P030 specification includes previous edits from the RTL
`
`_debugar specification and additional edits made by me, which are time
`
`stamped July 20, 1998 and July 21, 1998. The P030 specification was last
`
`modified by me on July 21, 1998, as indicated by the “date modified”
`
`timestamp of the file.
`
`10. My above-described edits to the specification were made by me while
`
`employed out of BSTZ’s Lake Oswego, Oregon office. The above-described
`
`inventors’ edits were made in France. I know the location of the inventors based
`
`on their correspondence address, telephone number, and facsimile number, all of
`
`8
`
`MG 2033
`
`

`

`Declaration of William D Davis
`
`which I used to communicate with the inventors.
`
`
`
`IPR 2012-00042
`
`11. During the period of July 21, 1998 to July 24, 1998, I thoroughly
`
`reviewed the prior edits, made additional changes, and then filed the ‘087 patent
`
`application.
`
`12. My docket during the drafting of the ‘087 patent application typically
`
`included 3-5 office action responses per week and preparation and filing of new
`
`applications (including invention disclosure meetings and associated travel for
`
`such meetings). I performed patent prosecution tasks from my docket in the order
`
`that the work was received or as required by due dates. Because applications I
`
`worked on at the time (including the ‘087 patent application) were drafted over
`
`several weeks with several revisions being exchanged between myself and the
`
`inventors, gaps ranging from one day to two weeks between working on
`
`applications would have been necessary and unavoidable, as I was required to
`
`balance the workload and address filing deadlines each week for office action
`
`responses and new applications.
`
`13. All of the statements made in this declaration of my own knowledge
`
`are true. All statements made based on information and belief are believed to be
`
`true. Further, these statements are made with the knowledge that willful false
`
`statements and the like so made are punishable by fine or imprisonment, or both,
`
`under § 1001 of Title 18 of the United States Code and that such willful false
`
`9
`
`MG 2033
`
`

`

`Declaration of William D Davis
`
`‘
`
`IPR 2012—00042
`
`statements may jeopardize the validity of the subject patent.
`
`Respectfully submitted,
`
`5;”
`r"
`1;
`5E
`,
`3
`W
`t»-
`fiw’f/gégtgkt
`19%;” A;5414:?”
`4:“?,4;Ligfizfigéig
`'32(51
`<35 i; 9/ 5
`
`William D. Davis
`Date F
`”
`
`10
`
`(cid:48)(cid:42)(cid:3)(cid:21)(cid:19)(cid:22)(cid:22)
`MG 2033
`
`

`

`Declaration of William D Davis
`
`
`
`
`
`IPR 2012-00042
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`EXHIBIT A
`
`
`
`
`
`(cid:20)(cid:20)
`
`(cid:48)(cid:42)(cid:3)(cid:21)(cid:19)(cid:22)(cid:22)
`
`

`

`Abstract
`
`In this paper, we present a new approach for simulating a digital circuit using a gate-level simulator
`while presenting a high-level view which is similar to Source-Level debugging proposed by RTL
`Software simulators. While the simulation is performed on actual gates, enough information is
`extracted through a process that we call instrumentation, so that the user can set breakpoints
`inside the RTL source code, as well as examine and navigate within the hierarchy of signal of the
`original source code.
`
`This new approach is especially suitable in the context of hardware accelerators and emulators: it
`combines the speed of simulation with the ease of use of traditional RTL software simulation
`environments.
`
`Introduction
`RTL Simulation
`
`
`1.1
`
`Chip designers have adopted high-level hardware description languages, partly because of the
`increasing complexity of the chips that the electronic market requires. The two main languages
`used for hardware design are VHDL and Verilog. Obtaining a gate-level netlist of the resulting chip
`is performed automatically by a process called synthesis. Synthesis Tools only accept a subset of
`the HDL that is called Register Transfer Level (RTL).
`
` 1
`
` A
`
` very important step is the simulation and validation of designs at the RT-level. Designers want to
`debug designs in the same environment that they describe them, for obvious convenience and
`efficiency reasons. As in software language debugging environments, designers can set
`breakpoints on a line of their source code, navigate the design hierarchy, view any variable or
`signal and see how it evolves. Another advantage of RTL Debug is that RTL simulation is typically
`an order of magnitude faster than gate-level simulation. Finally, the state of the art in synthesis has
`reached a point where a design which is verified at the RT-level can be considered correct. RTL
`sign-off is becoming more and more popular.
`
`1.2
`
`Gate-Level Simulation
`
` A
`
` fast turnaround time is very important in helping the designer find, understand and correct as
`many problems as possible. Often, billions of vectors have to be applied to a complex design in
`order to exercise certain cases, which can take hours and even days for a software simulator.
`Hardware accelerators and emulators offer a dramatic speedup in simulation performance, and
`their usage is becoming commonplace. While providing blazing fast speed, their main limitation is
`that being hardware-based, they only simulate designs at the gate-level, which prohibits RTL
`Simulation. Therefore, they are used later in the design flow, once synthesis has been performed.
`
`After synthesis, most high-level information from the original source code is lost. As there clearly is
`a need for designers to use hardware-accelerated simulation in a more friendly environment than
`gate-level, some work has attempted to bring hardware-based simulators closer to RTL simulation.
`Quick-Turn’s HDL-ICE (1) lets designers examine the RTL source code during emulation. It also
`quarantees that all the signals of the RTL code are visible. Another enhancement (2) has dealt with
`
`(cid:20)(cid:21)
`
`(cid:48)(cid:42)(cid:3)(cid:21)(cid:19)(cid:22)(cid:22)
`
`

`

`Mixed-Mode Simulation
`
`incremental compilation: whenever the designer makes modification in the RTL code, only those
`parts that have changed are synthesized again. This improves the time-to-emulation factor.
`
`Little work has focused on preserving breakpoints through synthesis. Koch et al (3) described a
`system that preserves breakpoints when transforming behavioral code to RTL code. It relies on the
`internals of the algorithm that generates the state controller for the behavioral code, and cannot be
`applied to RTL code.
`
`All these contributions still don’t qualify hardware-based simulators for RTL simulation. Only the
`most basic feature of RTL simulators (signal visibility) is provided. Most other features, ranging
`from setting breakpoints to analyzing the source code coverage, are not available.
`
`1.3
`
`We propose a new approach that closes the gap between hardware-based simulators (and gate-
`level simulation in general) and RTL simulation. This method relies on automatically modifying the
`HDL code (VHDL or Verilog) before it is synthesized, so that the resulting gate-level design
`contains additional hardware that is used to reconstitute the flow of execution of the original
`source code. We call this process instrumenting the source code. The resulting gate-level design
`can then be simulated at the RT-level with any gate-level simulator including hardware accelerators
`and emulators.
`
`Figure 1 shows such a flow. The instrumentation doesn’t have to take place before synthesis:
`figure 15 shows a different implementation of the instrumentation principles.
`
`If the simulator has the capacity to set a breakpoint whenever certain s
`
`signals reach a given value, then it is possible to implement breakpoints at the RT-level: whenever
`the user specifies a breakpoint in the source code, the condition is converted to a comparison with
`key signals.
`
`With the data acquired by the instrumentation process, it is possible to implement a source code
`coverage tool. By storing the instrumentation signals for each cycle of execution, one easily obtains
`how many times each line of RTL source code has been activated. Numerous methods have been
`presented in the past on how to process this information, the novelty of the approach is the means
`to obtain the data on which lines of the original source code are active at each simulation cycle.
`
`The data collected could also be used by a Finite State Machine (FSM) analyzer, that would verify
`for instance that all the possible transitions of an FSM have been tested.
`
`Finally, the instrumentation data can be used to enhance the source code display, for instance by
`highlighting the execution paths that are active at a given cycle. This would be a visual help for the
`designer, as he could understand without having to check the value of any signal, what each
`process is actually doing at each cycle.
`
`
`(cid:20)(cid:22)
`
`(cid:48)(cid:42)(cid:3)(cid:21)(cid:19)(cid:22)(cid:22)
`
`

`

`Altogether, these mechanisms give the user the feeling that source-level RTL debugging, including
`setting breakpoints, is possible in the context of gate-level simulators. We call this capacity mixed-
`mode simulation (RTL and Gate-Level).
`
`1.4
`
`
`
`
`Background on Design Methodology
`
`
`
`figure 1: Instrumentation Flow.
`
` A
`
` design is built by assembling elementary blocks hierarchically. In VHDL, a block corresponds to
`an architecture of an entity. In Verilog, a block corresponds to a module. Each architecture or
`module is composed of a declarative part and a statement part. The declarative part contains for
`instance the list of the ports (connectors) of the block, and is of little interest for instrumentation.
`
`The statement part is the place which describes the behavior of the block and this is where the
`user needs help in debugging his design. Concurrent statements assign a logic expression to a
`signal continuously: guaranteeing that signals can be observed and allowing breakpoints when
`they reach certain values is enough. Sequential statements assign various signal different
`expressions depending on the execution flow of the sequence. This is where source-level
`debugging is the most powerful. Figure 2 is an example of such statements.
`
`Sequential Code corresponds to VHDL processes and to Verilog always blocks. Their main
`characteristic is that they are built of an unlimited combination of nested statements such as loops,
`alternatives and conditions. There are two kinds of sequential statements: those that are level
`sensitive, meaning outputs one depend on the value of the inputs, and those that rely on events to
`compute the outputs. The first ones are synthesized to combinational gates and latches only,
`whereas the second ones use sequential gates such as flip-flops.
`
`The instrumentation is different for both cases.
`
`Section 2 explains how to instrument level-sensitive code, while section 3 deals with edge-sensitive
`RTL code. Section 4 presents a way to detect when processes become active. Section 5 details
`various optimizations that can be applied to the instrumentation mechanisms explained in the
`previous sections. Finally, considerations on synthesis are found in section 6.
`
`
`
`
`
`The simplest way to instrument level-sensitive code without losing on generality is to attach one
`variable to each elementary statement. Indeed, the goal being to detect when a given elementary
`statement is executed, it is clear that attaching one variable to each elementary statement will fulfill
`the goal. Elementary statements include signal assignments, variable assignments and function
`and procedure calls. All other control statements (such as if-then-else, case-when, for loop,
`module declarations, etc.....) are of course not instrumented.
`
`The algorithm is as follows:
`
`2
`
`2.1
`
`Level-Sensitive Code Instrumentation
`
`General Instrumentation
`
`(cid:20)(cid:23)
`
`(cid:48)(cid:42)(cid:3)(cid:21)(cid:19)(cid:22)(cid:22)
`
`

`

`(cid:120)
`
`
`
`
`
`
`
`Figure 3: Instrumented Sample Code.
`
`Figure 4: Synthesized Instrumented Code.
`
`initialization: all variables that monitor an elementary statement are set to zero at the beginning
`of the process
`(cid:120) Flow instrumentation: each time an elementary statements is encountered, a statement that
`sets a variable to one is added at the same position in the code
`(cid:120) Gathering: all the variables are assigned to global signals at the end of the process
`
`The major advantage of this algorithm is that it is flexible and will tolerate all kinds of coding style.
`
`Once instrumented, the code above will look like the one on Figure 3. The code added by the
`instrumentation is shown in italics.
`
`
`
`
`It is interesting to note that in the example above, both alternatives of the if statement can be true
`during the same clock cycle. Indeed, whenever one bit of vector a is equal to 0 while another bit is
`equal to 1, both conditions will be true (for different values of the index i ). This example is a good
`illustration of the fact that there is no obvious simplification between the instrumentation signals of
`two alternatives such as if-then-else.
`
`Figure 4 shows the gates that are generated by a Synthesis Tool for the instrumented code of
`Figure 3. As expected, signal trace4 is a logical OR of all the bits of vector a when reset is inactive,
`signal trace1 is equivalent to signal reset, and so on.
`
`
`
`2.2
`
`This method quarantees that when the original source code infers latches (because some signals
`are not assigned in every possible flow of execution), the instrumentation signal won’t infer latches.
`Indeed, the logic to detect which line of code is active is purely combinational, even when the code
`generalities latches.
`
`
`
`
`Figure 5 shows a sample Verilog code that infers a latch with a synchronous reset. Figure 6 shows
`the instrumented code (begin-end statements were omitted for clarity), Figure 7 shows the resulting
`synthesized gates.
`
`2.3
`
`Instrumentation and Latches
`
`
`
`Figure 5: Sample Verilog Code that Infers a Latch.
`
`Cross-Reference File
`
` A
`
` cross-reference file is generated which contains the mapping between line numbers and
`instrumentation signals. Each time an instrumentation variable (and its associated signal) is added
`to the source code, all the line numbers of the elementary statements that belong to the same
`block are added to this file. The line number of a block need not be contiguous: for instance, there
`
`(cid:20)(cid:24)
`
`(cid:48)(cid:42)(cid:3)(cid:21)(cid:19)(cid:22)(cid:22)
`
`

`

`can be a nested conditional statement in the middle of the block. It is therefore important to check
`all the line numbers of the elementary statements.
`
`Once the instrumentation process is complete, the cross-reference file will be used by the gate-
`level simulation environment to convert user’s breakpoints into actual conditions on instrumentation
`signals.
`
`Edge-Sensitive Code Instrumentation
`Event Handling
`
`
`
`
`
`Figure 8: Sample VHDL Code with Events
`
`Figure 9: Sample Verilog Code with Events
`
`
`3.1
`
`The previous section has correctly dealt with instrumenting the flow of sequential statements when
`they don’t contain references to signal events. Signal events are typically used to specify flip-flops.
`Amore sophisticated algorithm is required when signal events appear. Figures 8 and ( show the
`code for a D flip-flop with asynchronous reset using VDHL and Verilog.
`
`
`
`
`
`In order to detect events on signals correctly, we need to sample those signals using a fast clock
`that is provided by the hardware-based simulator. In terms of RTL, it means that each signal which
`uses events is stored in a flip-flop, and a comparison between the input and output of that flip-flop
`is used as the event. It is equally easy to generate the two other signal attributes that are used in
`VHDL to specify edges: clock’stable is the negation of clock’event, and clock’lastvalue is the
`content of the sampled flip-flop.
`
`The algorithm is as follows:
`
` 3
`
` (cid:120)
`
` event generation: all the signals with events are sampled using a fast clock and an equivalent
`event signal is generated
`(cid:120) process copy: all the processes which reference signal events are duplicated
`
`
`
`
`
`
`
`
`
`
`Figure 10: Sample Instrumented VHDL Code with Events.
`
`Figure 11: Synthesized Instrumented VHDL Code with Events.
`
` (cid:120)
`
` Flow instrumentation: all elementary statements are replaced by a statement that sets a
`variable to one (this is similar to the algorithm) in Section 2)
`(cid:120) event replacement: each time an event is referenced in a process, it is replaced by the event
`signal which has been computed in; the first step.
`
`
`
`Figure 12: Sample Instrumented Verilog Code with Events.
`
`
`
`
`Figure 10 and 12 illustrate the modifications to the previous source code to handle events. In the
`case of Verilog, it is interesting to note that the detection mechanism will be more precise than in
`VHDL: whenever an event occurs on the asynchronous reset signal, the corresponding source line
`will be activated. This is in accordance with the semantics of the language. Also, Verilog always
`
`(cid:20)(cid:25)
`
`(cid:48)(cid:42)(cid:3)(cid:21)(cid:19)(cid:22)(cid:22)
`
`

`

`Summary
`
`blocks are only activated when an edge is detected: this means that an implicit test must inserted
`in the instrumented code. On the opposite, VHDL constructs test explicitly (through the use of if
`clock’event for instance) for clock edges, therefore it is enough to replace each occurrence of
`clock’event constructs by the instrumented signal clock_event. Figure 11 shows the gates that are
`added by the instrumentation code of figure 10.
`
`3.2
`
`This section has shown how to instrument RTL code. Depending on the type of sequential
`statements to instrument. The instrumentation method for statements that contain signal events is
`generic and is a superset of the combinational method. However, it is recommended to use the
`combinational method whenever possible, as it allows the synthesis tool to detect obvious resource
`sharing. The second method involves duplicating code and it is unclear whether the synthesis tool
`will recognize that the same code appears twice. An expensive phase (in terms of CPU time) of
`resource sharing may need to be applied in order to achieve the same results as the first method.
`
`
`
`An advantage of always duplicating the code the way the second method does it, is to guarantee
`that the gates generated by the synthesis toll are exactly the ones that would have been generated
`if the design had not been instrumented. This can be critical when the user wants to verify the
`result of synthesis at the gate-level, while retaining the RTL breakpoint capacity.
`
`Table 1: Logic Generated in Instrumented Designs.
`
`
`The instrumentation method described in the sections above allows the detection of any path that
`has been taken while a process (VHDL) or an always block (Verilog) is activated. However, when a
`process is not activated, it retains the same data. This actually makes sense in terms of hardware
`description language: as long as the process is not activated again, all the assignments that have
`occurred in the last execution are still active.
`
`Figure 13: Sample Instrumented VHDL Code which detects Process Activation.
`
`If one wants to obtain a behavior even closer to the one of a software RTL simulator, it is
`necessary to generate a second kind of information: the activation of each process. This is done
`simply by looking at the sensitivity list of each process. Logic can then be generated that compares
`the signals on the sensitivity list between two consecutive simulation cycles. Each time this signal
`indicates a difference, it means the process has been executed again.
`
`One way to implement this is to sample all the signals that are on the sensitivity list of a process,
`and detect whenever events occur on any of them. The logical OR condition is equivalent to
`meaning that the process has been activated. Figure 13 shows a process and the instrumented
`code that generates the activation signal.
`
`By combining this information with the information on which execution flow was taken inside a
`process to recreate the illusion of a process being activated and a certain line of the source code
`being executed.
`
`Instrumenting Process Activation
`
`(cid:20)(cid:26)
`
`(cid:48)(cid:42)(cid:3)(cid:21)(cid:19)(cid:22)(cid:22)
`
` 4
`
`
`
`

`

`Optimizations
`
` 5
`
`
`
`
`Instrumentation is a way to obtain the logical equations that correspond to all the conditions for
`which the lines of the source code are activated. However, it is not necessary to implement those
`equations purely in gates that are simulated by the gate-level simulator. Depending on the
`simulator, one can implement part or all of those equations in a way that is specific to the
`simulator. For instance, when using a software simulator, one can decide to implement the
`handling of events by simply comparing the value of a signal with its previous value, assuming this
`information is still available in the internal structures of the simulator.
`
`Section 5.2 presents possible optimizations when a hardware accelerator is used that has
`programmable hardware triggers that can operate on combinations of bits. Section 4 presents a
`way to detect the activation of a process using gates. It could also be implemented in specific
`software if a gate-level software simulator is used.
`
`The tradeoff between implementing the equations partly using gates and partly using specif