JP2012252433A - Verification method and verification program - Google Patents

Verification method and verification program Download PDF

Info

Publication number
JP2012252433A
JP2012252433A JP2011123080A JP2011123080A JP2012252433A JP 2012252433 A JP2012252433 A JP 2012252433A JP 2011123080 A JP2011123080 A JP 2011123080A JP 2011123080 A JP2011123080 A JP 2011123080A JP 2012252433 A JP2012252433 A JP 2012252433A
Authority
JP
Japan
Prior art keywords
scenario
checker
error
verification
test bench
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2011123080A
Other languages
Japanese (ja)
Other versions
JP5799589B2 (en
Inventor
Fumiaki Suzuki
文明 鈴木
Satoshi Shoji
智 庄司
Jun Tanowaki
潤 田之脇
Minako Obara
美奈子 小原
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Semiconductor Ltd
Original Assignee
Fujitsu Semiconductor Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Semiconductor Ltd filed Critical Fujitsu Semiconductor Ltd
Priority to JP2011123080A priority Critical patent/JP5799589B2/en
Publication of JP2012252433A publication Critical patent/JP2012252433A/en
Application granted granted Critical
Publication of JP5799589B2 publication Critical patent/JP5799589B2/en
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Abstract

PROBLEM TO BE SOLVED: To provide a verification method that can efficiently develop a program such as a scenario used for circuit verification.SOLUTION: A verification method causes a computer to: generate a scenario checker (S69) by using a setting restriction list (S67), the scenario checker indicating a content of the setting restriction list, and the setting restriction list including restriction information for restricting execution of an instruction in a predetermined description part of a scenario (S65) in which instructions for a verification target is described; check by using the scenario checker (S69) whether or not the instruction includes the restriction information upon executing the above predetermined description part of the scenario (S65) during simulation (S74) of the verification target; and output a result (S75) of the checking.

Description

本発明は、回路検証に用いる検証方法及び検証プログラムに関する。   The present invention relates to a verification method and a verification program used for circuit verification.

ＬＳＩ（Large Scale Integration）等の集積回路の開発では、設計仕様を基にレジスタ・トランスファ・レベル（ＲＴＬ）と呼ばれる論理式を用いて回路の論理を表現する。このＲＴＬで設計された回路の機能、動作を検証するために、コンピュータを用いたシミュレーションが行われる。   In the development of an integrated circuit such as LSI (Large Scale Integration), the logic of a circuit is expressed using a logical expression called a register transfer level (RTL) based on a design specification. In order to verify the function and operation of the circuit designed by the RTL, a simulation using a computer is performed.

検証時には、検証対象の回路に対する命令の手順を記述したシナリオをテストベンチに組み込み、そのテストベンチを用いて検証対象のシミュレーションを行う。そして、その検証対象の回路からの出力について、仕様違反や規格違反等のエラーを起こしていないかチェックする。このような回路の検証に用いられるシナリオやテストベンチは、回路の検証に先立ち、或いは回路の検証と並行して、開発される。   At the time of verification, a scenario describing the instruction procedure for the circuit to be verified is incorporated in the test bench, and the verification target is simulated using the test bench. Then, the output from the circuit to be verified is checked for an error such as a specification violation or a standard violation. Scenarios and test benches used for circuit verification are developed prior to circuit verification or in parallel with circuit verification.

また、回路を制御するためのファームウェアを設計し、ファームウェアを用いて回路を動作させ、ファームウェアがその回路を正しく制御しているかを確認する技術等も知られている。   There is also known a technique for designing firmware for controlling a circuit, operating the circuit using the firmware, and confirming whether the firmware correctly controls the circuit.

このほか、ランダムに並べたテストシーケンスを含むシナリオを用いたランダムテストで回路を検証する際に、シミュレーションによって実際にテストされた検証項目を確認するための手法等も知られている。   In addition, a method for confirming verification items actually tested by simulation when a circuit is verified by a random test using a scenario including randomly arranged test sequences is also known.

特開２００４−８６８３８号公報JP 2004-86838 A

ところで、シナリオを組み込んだテストベンチを用いて検証対象の検証を行う場合、検出されるエラーは、検証対象が原因である場合のほか、テストベンチの開発段階ではそのテストベンチ、例えば組み込まれているシナリオが原因である場合もある。シナリオが原因である場合には、例えば、シミュレーション時の波形データを用いて、エラーを引き起こしたシナリオの命令箇所を特定する。しかし、エラーの発生タイミングとそのエラーを引き起こしたシナリオの命令タイミングには時間差があるため、エラーを引き起こしたシナリオの原因箇所を特定する作業が複雑になり、エラー原因の解析に長時間を要してしまうことがある。   By the way, when the verification target is verified using the test bench incorporating the scenario, the detected error is caused by the verification target, and the test bench, for example, is included in the test bench development stage. There can be a scenario. When the scenario is the cause, for example, the command location of the scenario causing the error is specified using the waveform data at the time of simulation. However, because there is a time difference between the timing of the error and the instruction timing of the scenario that caused the error, the task of identifying the cause of the scenario that caused the error is complicated, and it takes a long time to analyze the cause of the error. May end up.

一方、上記のような検証に用いるシナリオの開発段階では、検証対象の設計仕様書に基づき、一定条件の場合の命令実行を制限する制限事項を考慮してシナリオを作成し、それを組み込んだテストベンチを用いてシミュレーションが行われる。このシミュレーション時の波形データを目視確認することで、シナリオの動作が検証される。しかし、このような波形データの目視確認には長時間を要してしまうことがある。更に、シナリオに基づく検証対象への入力命令の数が膨大になると、それら全てについて波形データの目視確認で検証を行うことは難しくなる。このようにして検証されなかった命令や、制限事項が適正に考慮されていない命令が、上記のようなシナリオが原因のエラーを発生させる一因にもなっている。   On the other hand, at the development stage of the scenario used for verification as described above, based on the design specifications to be verified, a scenario is created in consideration of restrictions that restrict instruction execution under certain conditions, and a test that incorporates it Simulation is performed using a bench. The scenario operation is verified by visually checking the waveform data during the simulation. However, visual confirmation of such waveform data may take a long time. Furthermore, when the number of input commands to be verified based on the scenario becomes enormous, it is difficult to verify all of them by visual confirmation of the waveform data. Instructions that have not been verified in this way, and instructions that do not properly consider the restrictions, also contribute to the error caused by the above scenario.

ここではシナリオを例にしたが、回路を制御するファームウェアでも同様に、その開発段階では、作成したファームウェアを用いて回路（検証対象）を動作させ、エラーが検出された場合には、波形データの目視確認が行われる。このとき、エラーの原因が検証対象の回路側にあるのか、それを制御するファームウェア側にあるのかの判定に時間がかかってしまう。エラーの発生タイミングとそのエラーを引き起こしたファームウェアの命令タイミングに時間差があり、波形データを用いた解析が複雑になるためである。   Here, a scenario is taken as an example, but in the development stage of the firmware that controls the circuit as well, at the development stage, the circuit (verification target) is operated using the created firmware, and if an error is detected, the waveform data Visual confirmation is performed. At this time, it takes time to determine whether the error is caused by the circuit to be verified or by the firmware that controls the error. This is because there is a time difference between the occurrence timing of the error and the instruction timing of the firmware that caused the error, and the analysis using the waveform data becomes complicated.

本発明の一観点によれば、コンピュータが実行する検証方法であって、検証対象に対する命令を記述したプログラムの所定記述部分の命令実行を制限する制限情報を含むリストを用い、前記リストの内容を示すチェッカを生成し、前記プログラムを用いて前記検証対象を動作させ、前記所定記述部分の命令実行時に、前記チェッカを用いて前記所定記述部分の命令が前記制限情報を含むか否かのチェックを行い、前記チェックの結果を示す結果情報を生成する検証方法が提供される。   According to an aspect of the present invention, there is provided a verification method executed by a computer, wherein a list including restriction information for restricting instruction execution of a predetermined description part of a program describing an instruction for a verification target is used, and the contents of the list are The checker is generated, the verification target is operated using the program, and when the instruction of the predetermined description part is executed, the checker is used to check whether the instruction of the predetermined description part includes the restriction information. And a verification method for generating result information indicating the result of the check is provided.

また、本発明の一観点によれば、このような検証方法を実現するための処理をコンピュータに実行させる検証プログラムが提供される。   In addition, according to one aspect of the present invention, a verification program for causing a computer to execute processing for realizing such a verification method is provided.

開示の技術によれば、シナリオやファームウェア等のプログラムを、当該プログラムの実行時にチェッカを用いてチェックし、そのチェックの結果から検証することが可能になる。それにより、当該プログラムの検証時や、当該プログラムを用いた検証時に、波形データの取得、取得した波形データの目視確認作業を不要にすることが可能になる。適正なシナリオやファームウェア等のプログラムを、効率的に開発することが可能になり、当該プログラムを用いた検証作業を効率的に行うことが可能になる。   According to the disclosed technology, it is possible to check a program such as a scenario or firmware using a checker when the program is executed, and verify the result of the check. This makes it possible to eliminate the need for waveform data acquisition and visual confirmation of the acquired waveform data when verifying the program or verifying the program. Programs such as appropriate scenarios and firmware can be efficiently developed, and verification work using the programs can be efficiently performed.

論理シミュレーション環境の一例を示す図である。It is a figure which shows an example of a logic simulation environment. 検証作業フローの一例を示す図である。It is a figure which shows an example of a verification work flow. テストベンチ開発作業フローの一例を示す図（その１）である。It is FIG. (1) which shows an example of a test bench development work flow. テストベンチ開発段階でのテストベンチの構成例を示す図（その１）である。It is FIG. (1) which shows the structural example of the test bench in a test bench development stage. シナリオ要因のエラー発生例を示す図である。It is a figure which shows the example of an error occurrence of a scenario factor. シナリオ開発作業フローの一例を示す図（その１）である。It is FIG. (1) which shows an example of a scenario development work flow. シナリオ開発段階でのテストベンチの構成例を示す図（その１）である。It is FIG. (1) which shows the structural example of the test bench in a scenario development stage. シナリオ開発作業フローの一例を示す図（その２）である。It is FIG. (2) which shows an example of a scenario development work flow. シナリオ開発段階でのテストベンチの構成例を示す図（その２）である。It is FIG. (2) which shows the example of a structure of the test bench in a scenario development stage. テストベンチ開発作業フローの一例を示す図（その２）である。It is FIG. (2) which shows an example of a test bench development work flow. テストベンチ開発段階でのテストベンチの構成例を示す図（その２）である。It is FIG. (2) which shows the structural example of the test bench in a test bench development stage. 設定制限リストのフォーマットの一例を示す図である。It is a figure which shows an example of the format of a setting restriction | limiting list | wrist. 第１実施例に係る検証対象とシナリオの関係を示す図である。It is a figure which shows the relationship between the verification object and scenario which concern on 1st Example. 第１実施例に係る設定制限事項の一例を示す図である。It is a figure which shows an example of the setting limitation matter which concerns on 1st Example. 第１実施例に係るシナリオの記述部分の一例を示す図である。It is a figure which shows an example of the description part of the scenario which concerns on 1st Example. 設定制限リストの作成方法を示す図（その１）である。FIG. 6 is a diagram (part 1) illustrating a method for creating a setting restriction list. 設定制限リストの作成方法を示す図（その２）である。FIG. 6 is a diagram (part 2) illustrating a method of creating a setting restriction list. 設定制限リストの作成方法を示す図（その３）である。FIG. 11 is a third diagram illustrating a method for creating a setting restriction list; 設定制限リストの作成方法を示す図（その４）である。FIG. 6 is a diagram (part 4) illustrating a method of creating a setting restriction list. シナリオチェッカ生成スクリプトによる設定制限リストからシナリオチェッカへの変換形式を示す図である。It is a figure which shows the conversion format from the setting restriction | limiting list | wrist by a scenario checker production | generation script to a scenario checker. 第１実施例に係るシナリオチェッカ生成スクリプトによる設定制限リストからシナリオチェッカへの変換例を示す図である。It is a figure which shows the example of conversion from the setting restriction | limiting list | wrist by the scenario checker production | generation script which concerns on 1st Example to a scenario checker. 第１実施例に係るシナリオチェッカ組み込みスクリプトによるシナリオチェッカのシナリオへの組み込み例を示す図である。It is a figure which shows the example of incorporating the scenario checker into the scenario by the scenario checker incorporation script according to the first embodiment. 第１実施例に係るログファイルの出力例である。It is an output example of the log file which concerns on 1st Example. 第２実施例に係る設定制限事項の一例を示す図である。It is a figure which shows an example of the setting limitation matter which concerns on 2nd Example. 第２実施例に係るシナリオの記述部分の一例を示す図である。It is a figure which shows an example of the description part of the scenario which concerns on 2nd Example. 第２実施例に係る設定制限リストの一例を示す図である。It is a figure which shows an example of the setting restriction | limiting list | wrist which concerns on 2nd Example. 第２実施例に係るシナリオチェッカの一例を示す図である。It is a figure which shows an example of the scenario checker concerning 2nd Example.

ＬＳＩ開発では、設計仕様を基にＲＴＬで設計された論理回路の機能、動作を、コンピュータを用いた論理シミュレーションを行って検証する。
図１に論理シミュレーション環境の一例を示す。 In LSI development, the function and operation of a logic circuit designed in RTL based on design specifications are verified by performing a logic simulation using a computer.
FIG. 1 shows an example of a logic simulation environment.

論理シミュレーション環境は、コンピュータ１００を用いて構築される。コンピュータ１００は、ＣＰＵ（Central Processing Unit）１０１によって装置全体が制御される。ＣＰＵ１０１には、バス１１０を介して、ＲＯＭ（Read Only Memory）１０２及びＲＡＭ（Random Access Memory）１０３が接続される。ＲＯＭ１０２には、シミュレーションを行う論理回路を制御するファームウェア等のプログラムが格納される。ＲＡＭ１０３には、ＣＰＵ１０１に実行させるＯＳ（Operating System）のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、ＲＡＭ１０３には、ＣＰＵ１０１による処理に必要な各種データが格納される。   The logic simulation environment is constructed using the computer 100. The entire computer 100 is controlled by a CPU (Central Processing Unit) 101. A ROM (Read Only Memory) 102 and a RAM (Random Access Memory) 103 are connected to the CPU 101 via a bus 110. The ROM 102 stores a program such as firmware for controlling a logic circuit that performs simulation. The RAM 103 temporarily stores at least part of an OS (Operating System) program and application programs to be executed by the CPU 101. The RAM 103 stores various data necessary for processing by the CPU 101.

バス１１０には、複数の周辺機器が接続される。バス１１０に接続される周辺機器としては、ハードディスクドライブ（Hard Disk Drive；ＨＤＤ）１０４、通信インタフェース１０５、キーボード１０６、マウス１０７等がある。   A plurality of peripheral devices are connected to the bus 110. Peripheral devices connected to the bus 110 include a hard disk drive (HDD) 104, a communication interface 105, a keyboard 106, a mouse 107, and the like.

ＨＤＤ１０４は、ハードディスク（Hard Disk；ＨＤ）１０４ａに対して磁気的にデータの書き込み及び読み出しを行う。ＨＤＤ１０４には、ＯＳのプログラム、アプリケーションプログラム、及び各種データが格納される。通信インタフェース１０５は、ネットワークに接続され、ネットワークを介して、他のコンピュータ又は通信機器との間でデータの送受信を行う。また、キーボード１０６やマウス１０７から送られてくる信号は、バス１１０を介してＣＰＵ１０１に送信される。尚、マウス１０７は、ポインティングデバイスの一例であり、タッチパネル、タブレット、タッチパッド、トラックボール等、他のポインティングデバイスを用いることも可能である。   The HDD 104 magnetically writes and reads data to and from a hard disk (HD) 104a. The HDD 104 stores an OS program, application programs, and various data. The communication interface 105 is connected to a network, and transmits / receives data to / from other computers or communication devices via the network. Signals sent from the keyboard 106 and mouse 107 are sent to the CPU 101 via the bus 110. The mouse 107 is an example of a pointing device, and other pointing devices such as a touch panel, a tablet, a touch pad, and a trackball can be used.

バス１１０には、更に、その他の周辺機器１０８が接続されていてもよい。その他の周辺機器１０８としては、例えば、グラフィック処理装置や光学ドライブ装置等が挙げられる。この場合、グラフィック処理装置には、モニタ（ＣＲＴ（Cathode Ray Tube）を用いた表示装置や液晶表示装置等）が接続され、グラフィック処理装置は、ＣＰＵ１０１からの命令に従って、画像をモニタの画面に表示させる。また、光学ドライブ装置は、レーザ光等を利用して、光ディスク（ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−ＲＡＭ、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）等）に記録されたデータの読み取りを行う。   Other peripheral devices 108 may be further connected to the bus 110. Examples of other peripheral devices 108 include a graphic processing device and an optical drive device. In this case, a monitor (such as a display device using a CRT (Cathode Ray Tube) or a liquid crystal display device) is connected to the graphic processing device, and the graphic processing device displays an image on the screen of the monitor according to a command from the CPU 101. Let Further, the optical drive device uses an optical disk (DVD (Digital Versatile Disc), DVD-RAM, CD-ROM (Compact Disc Read Only Memory), CD-R (Recordable) / RW (ReWritable)) using a laser beam or the like. Etc.) is recorded.

このような構成を有するコンピュータ１００の、例えばＨＤ１０４ａに、ＲＴＬの論理回路（検証対象）の設計データ１２０、論理シミュレータ１３０、ＲＴＬの論理回路に対する命令を記述したシナリオを組み込んだテストベンチ１４０等が格納される。コンピュータ１００は、ＨＤＤ１０４を駆動し、ＨＤ１０４ａに格納されたこれらの情報を用いて、検証対象である論理回路の論理シミュレーションを実行する。この論理シミュレーションの結果に基づき、論理回路の機能、動作が適正か否かが検証される。   For example, the HD 104a of the computer 100 having such a configuration stores the design data 120 of the RTL logic circuit (verification target), the logic simulator 130, the test bench 140 in which the scenario describing the instruction for the RTL logic circuit is incorporated, and the like. Is done. The computer 100 drives the HDD 104 and executes logic simulation of the logic circuit to be verified using these pieces of information stored in the HD 104a. Based on the result of this logic simulation, it is verified whether the function and operation of the logic circuit are appropriate.

次に、論理シミュレーションを用いた検証作業の一例について説明する。
図２は検証作業フローの一例を示す図である。
論理シミュレーションを行う検証作業では、まず、検証対象である論理回路の仕様書（設計仕様書）（Ｓ１０）を基に、検証仕様書が作成される（Ｓ１１，Ｓ１２）。そして、作成された検証仕様書からテストベンチの構成が検討され、テストベンチ仕様書が作成される（Ｓ１３，Ｓ１４）。このテストベンチ仕様書を基に、テストベンチの開発が行われる（Ｓ１５，Ｓ１６）。開発されたテストベンチを用いて論理シミュレーション（検証作業）が行われ、その結果（検証結果）が取得される（Ｓ１７，Ｓ１８）。論理シミュレーションで得られる検証結果から、検証対象の論理回路が適正に動作するか否かが、開発者或いはコンピュータ１００によって、判定される。 Next, an example of verification work using logic simulation will be described.
FIG. 2 is a diagram illustrating an example of a verification work flow.
In the verification operation for performing the logic simulation, a verification specification is first created based on the specification (design specification) (S10) of the logic circuit to be verified (S11, S12). Then, the configuration of the test bench is examined from the created verification specification, and the test bench specification is created (S13, S14). Based on this test bench specification, the test bench is developed (S15, S16). Logic simulation (verification work) is performed using the developed test bench, and the result (verification result) is acquired (S17, S18). From the verification result obtained by the logic simulation, the developer or the computer 100 determines whether or not the logic circuit to be verified operates properly.

更にテストベンチ開発（Ｓ１５，Ｓ１６）に着目して説明する。
図３はテストベンチ開発作業フローの一例を示す図である。
図３のテストベンチ開発作業フローでは、開発者が、テストベンチ仕様書（Ｓ２０）から更にテストベンチの構成要素となる部品（モデル）毎の仕様を設定し、部品毎に開発を行う（Ｓ２１〜Ｓ２３）。図３の例では、チェッカの開発（Ｓ２１）、トランザクタの開発（Ｓ２２）、シナリオの開発（Ｓ２３）を行っている。そして、各部品について単体テストを実施し、問題がないことを確認して、各部品を取得する（Ｓ２４）。このようにして取得された各部品を、検証対象の論理回路と共に組み上げることで（Ｓ２５）、テストベンチ（論理回路を含むシミュレーションの全体環境）を取得する（Ｓ２６）。 Further, the test bench development (S15, S16) will be described.
FIG. 3 is a diagram showing an example of a test bench development work flow.
In the test bench development work flow of FIG. 3, the developer further sets specifications for each part (model), which is a component of the test bench, from the test bench specification (S20), and performs development for each part (S21 to S21). S23). In the example of FIG. 3, checker development (S21), transactor development (S22), and scenario development (S23) are performed. Then, a unit test is performed on each component, and it is confirmed that there is no problem, and each component is acquired (S24). By assembling the parts thus obtained together with the logic circuit to be verified (S25), a test bench (the entire simulation environment including the logic circuit) is obtained (S26).

テストベンチ開発段階でのテストベンチの構成例を図４に示す。
図４のテストベンチ２００は、部品として、シナリオ２１１及びトランザクタ２１２を含むモデル２１０、プロトコルチェッカ２２０、及び期待値比較チェッカ２３０を備えている（テストベンチ開発環境）。 FIG. 4 shows a configuration example of the test bench at the test bench development stage.
The test bench 200 of FIG. 4 includes a model 210 including a scenario 211 and a transactor 212, a protocol checker 220, and an expected value comparison checker 230 as test parts (test bench development environment).

シナリオ２１１には、ＲＴＬで設計された検証対象３００の論理回路に対する命令の手順が記述されている。シナリオ２１１は、トランザクタ２１２の仕様に合わせ、トランザクタ２１２に対し、検証対象３００を制御する（動作させる）命令を与える。   The scenario 211 describes a procedure of instructions for the logic circuit of the verification target 300 designed by RTL. The scenario 211 gives a command for controlling (operating) the verification target 300 to the transactor 212 in accordance with the specification of the transactor 212.

トランザクタ２１２は、シナリオ２１１からの命令に従い、検証対象３００との間のインタフェース仕様に合わせて信号を制御し、シナリオ２１１からの命令の情報を検証対象３００に伝える。検証対象３００は、このトランザクタ２１２からの情報を受けて、その情報が示す命令の動作を実行する。また、トランザクタ２１２は、検証対象３００から送られてくる情報を受信し、受信した情報をシナリオ２１１へ通知する。   The transactor 212 controls a signal according to the interface specification with the verification target 300 in accordance with the command from the scenario 211, and transmits information on the command from the scenario 211 to the verification target 300. The verification target 300 receives information from the transactor 212 and executes the operation of the command indicated by the information. Further, the transactor 212 receives information transmitted from the verification target 300 and notifies the scenario 211 of the received information.

プロトコルチェッカ２２０は、プロトコルが存在するインタフェースに対し、関連する入出力端子を参照し、プロトコルに特化したチェックを行う。プロトコルチェッカ２２０は、プロトコル違反を検出した場合、エラーを報告する。   The protocol checker 220 refers to a related input / output terminal for an interface in which the protocol exists, and performs a check specialized for the protocol. If the protocol checker 220 detects a protocol violation, it reports an error.

期待値比較チェッカ２３０は、検証対象３００の入出力端子を参照し、検証対象３００の出力端子（データ値、信号制御等）が設計仕様通り動作しているかのチェックを行う。期待値比較チェッカ２３０は、設計仕様違反を検出した場合、エラーを報告する。   The expected value comparison checker 230 refers to the input / output terminals of the verification target 300 and checks whether the output terminals (data value, signal control, etc.) of the verification target 300 are operating according to the design specifications. The expected value comparison checker 230 reports an error when a design specification violation is detected.

図３のテストベンチ開発作業フローにおいて、このような構成を有するテストベンチを取得（Ｓ２６）した後は、コンピュータを用い、テストベンチで検証対象の論理回路を動作させ、最終的な動作確認テスト（全体シミュレーション）を行う（Ｓ２７）。この全体シミュレーションの結果（テストベンチに組み込まれたチェッカによるチェック結果）は、ログファイルとして出力される（Ｓ２８）。このログファイルの情報から開発者がエラーの発生有無を判断する（Ｓ２９）。エラーが発生している場合、そのエラー要因を特定するために波形データが必要になる。この波形データを取得する目的で、コンピュータを用いた再シミュレーションを行う（Ｓ３０，Ｓ３１）。取得した波形データを開発者が目視で確認し、エラー要因を特定する（Ｓ３２）。エラー要因は、まず、検証対象の論理回路側にある場合と、テストベンチ側にある場合の２つに分けられる（Ｓ３３）。   In the test bench development work flow of FIG. 3, after obtaining the test bench having such a configuration (S26), the logic circuit to be verified is operated on the test bench using a computer, and the final operation check test ( (Whole simulation) is performed (S27). The result of this entire simulation (check result by the checker incorporated in the test bench) is output as a log file (S28). From this log file information, the developer determines whether an error has occurred (S29). If an error has occurred, waveform data is required to identify the cause of the error. In order to acquire this waveform data, re-simulation using a computer is performed (S30, S31). The developer visually confirms the acquired waveform data, and identifies the cause of the error (S32). Error factors are first divided into two cases: the case of being on the logic circuit side to be verified and the case of being on the test bench side (S33).

エラー要因が検証対象の論理回路側にある場合には（Ｓ３３）、開発者が、ＲＴＬで設計されたその論理回路の修正を行い（Ｓ３４）、修正後の論理回路を作成し（Ｓ３５）、修正後の論理回路と共に、再度テストベンチを取得する（Ｓ２５，Ｓ２６）。そして、その再取得したテストベンチを用いて全体シミュレーション（Ｓ２７）以降の作業を実施する。   When the error factor is on the logic circuit to be verified (S33), the developer corrects the logic circuit designed in the RTL (S34), and creates a corrected logic circuit (S35). A test bench is acquired again together with the corrected logic circuit (S25, S26). Then, the work after the entire simulation (S27) is performed using the re-acquired test bench.

一方、エラー要因がテストベンチ側にある場合（Ｓ３３）、エラー要因は、テストベンチ内のシナリオ、トランザクタ、チェッカ等の部品の、少なくともいずれかに存在している（Ｓ３６）。例えば、図４のテストベンチ２００の場合、シナリオ２１１、トランザクタ２１２、プロトコルチェッカ２２０、期待値比較チェッカ２３０のいずれかにエラー要因が存在する。   On the other hand, when the error factor is on the test bench side (S33), the error factor is present in at least one of the parts such as a scenario, a transactor, and a checker in the test bench (S36). For example, in the case of the test bench 200 in FIG. 4, an error factor exists in any of the scenario 211, the transactor 212, the protocol checker 220, and the expected value comparison checker 230.

シナリオにエラー要因（シナリオミス）がある場合には（Ｓ３６）、シナリオ開発（Ｓ２３）に戻り、シナリオのエラー要因を修正する。トランザクタにエラー要因（トランザクタミス）がある場合には（Ｓ３６）、トランザクタ開発（Ｓ２２）に戻り、トランザクタのエラー要因を修正する。チェッカにエラー要因（チェッカミス）がある場合には（Ｓ３６）、チェッカ開発（Ｓ２１）に戻り、チェッカのエラー要因を修正する。そして、上記同様、単体テストを実施して各部品を取得し（Ｓ２４）、テストベンチを取得（Ｓ２５，Ｓ２６）して、全体シミュレーション（Ｓ２７）以降の作業を実施する。   If there is an error factor (scenario error) in the scenario (S36), the process returns to scenario development (S23) to correct the error factor of the scenario. If there is an error factor (transactor miss) in the transactor (S36), the process returns to transactor development (S22) to correct the error factor of the transactor. If there is an error factor (checker miss) in the checker (S36), the process returns to the checker development (S21) to correct the checker error factor. Then, as described above, the unit test is performed to acquire each component (S24), the test bench is acquired (S25, S26), and the work after the entire simulation (S27) is performed.

全体シミュレーションでエラーが検出されず（Ｓ２９）、更に異なる条件で全体シミュレーション（テスト）を行う場合には（Ｓ３７）、シミュレーション条件を変更してテストを行う（Ｓ２７）。エラーなく全てのテストが終了すれば（Ｓ３７）、テストベンチ開発作業は終了となる。開発したテストベンチを用いて、上記図２の論理シミュレーション（検証作業）が行われる（Ｓ１７，Ｓ１８）。   If no error is detected in the overall simulation (S29) and the overall simulation (test) is performed under different conditions (S37), the simulation conditions are changed and the test is performed (S27). If all tests are completed without error (S37), the test bench development work is completed. The logic simulation (verification work) shown in FIG. 2 is performed using the developed test bench (S17, S18).

テストベンチは、例えば上記図３のような作業フローで開発が可能であるが、以下のような課題もある。
例えば、上記図３の作業フローでは、全体シミュレーションの結果（Ｓ２７，Ｓ２８）、チェッカによりエラーが検出された場合（Ｓ２９）、再シミュレーションで波形データが取得され（Ｓ３０，Ｓ３１）、その目視確認が行われる（Ｓ３２）。 The test bench can be developed with the work flow as shown in FIG. 3, for example, but has the following problems.
For example, in the work flow of FIG. 3 described above, if an error is detected by the checker (S27, S28) and the checker detects an error (S29), waveform data is acquired by re-simulation (S30, S31), and the visual check is performed. Performed (S32).

開発済みの適正なテストベンチが用いられている場合、チェッカがエラーを検出すれば、検証対象の論理回路側に問題があると判断できる。しかし、テストベンチの開発段階では、チェッカ自体が適正であるか否かが確定しておらず、その品質に問題が残っているため、検出されたエラーがチェッカ自体のミスによるものである可能性がある。更に、テストベンチの開発段階では、シナリオに問題がある場合も、チェッカによりエラーとして検出されてくる。このようにエラーの要因がシナリオにある場合、その要因の特定には時間がかかる。その理由を、次の図５を参照して説明する。   When a proper developed test bench is used, if the checker detects an error, it can be determined that there is a problem in the logic circuit to be verified. However, at the test bench development stage, it is not determined whether the checker itself is appropriate, and there remains a problem with its quality, so the detected error may be due to a mistake in the checker itself. There is. Furthermore, in the test bench development stage, even if there is a problem in the scenario, it is detected as an error by the checker. Thus, when the cause of the error is in the scenario, it takes time to specify the cause. The reason will be described with reference to FIG.

図５はシナリオ要因のエラー発生例を示す図である。図５において、（Ａ）はテストベンチの一例、（Ｂ），（Ｃ）は波形データの一例である。
まず、チェッカがエラーを検出するのは、検証対象の出力端子が仕様違反、規格違反した動作に対してであり、検証対象の出力動作は入力パターンで決まる。つまり、検証対象への入力パターン（シナリオの命令）にミスがあると、チェッカによってエラーが検出される。 FIG. 5 is a diagram showing an example of scenario factor error occurrence. In FIG. 5, (A) is an example of a test bench, and (B) and (C) are examples of waveform data.
First, the checker detects an error in response to an operation in which the output terminal to be verified violates the specification or the standard, and the output operation to be verified is determined by the input pattern. That is, if there is an error in the input pattern (scenario command) to the verification target, the checker detects an error.

今、図５（Ａ）のテストベンチ２００における一方のモデル２１０ａのシナリオ２１１ａに従い、図５（Ｂ）のような入力パターン（出力信号１，２）がトランザクタ２１２ａを介して検証対象３００に出力されたものとする。そして、その入力パターンに基づき、検証対象３００からは、図５（Ｃ）のような出力（出力信号１，２）が得られ、その出力がもう一方のモデル２１０ｂ（シナリオ２１１ｂ、トランザクタ２１２ｂ）に送られるものとする。この検証対象３００からの出力に対し、Ｂプロトコルチェッカ２２０ｂがＸ部にエラーを検出したものとする。即ち、この例では、Ｂプロトコルチェッカ２２０ｂが、出力のＸ部における、クロックの立ち上がりで出力信号１，２が共にハイ（Ｈ）レベルとなるエラーを検出する。このＢプロトコルチェッカ２２０ｂで検出されたエラーは、シナリオ２１１ａからの入力パターンにおける、Ｙ部の入力パターンミスが根本原因になっている。   Now, according to the scenario 211a of one model 210a in the test bench 200 of FIG. 5A, an input pattern (output signals 1 and 2) as shown in FIG. 5B is output to the verification target 300 via the transactor 212a. Shall be. Based on the input pattern, an output (output signals 1 and 2) as shown in FIG. 5C is obtained from the verification target 300, and the output is sent to the other model 210b (scenario 211b, transactor 212b). Shall be sent. It is assumed that the B protocol checker 220b detects an error in the X section with respect to the output from the verification target 300. That is, in this example, the B protocol checker 220b detects an error in which both the output signals 1 and 2 become high (H) level at the rising edge of the clock in the X portion of the output. The error detected by the B protocol checker 220b is caused by an input pattern error in the Y part in the input pattern from the scenario 211a.

このように、検証対象３００の出力についてＢプロトコルチェッカ２２０ｂで検出されるエラー要因が、検証対象３００に対する入力パターンにあると、エラーの検出ポイント（Ｘ部）と、その要因となる入力パターン（Ｙ部）の間には、時間差Ｔが生じる。エラー要因がシナリオ２１１ａにあり、その要因を波形データから特定しようとすると、この時間差Ｔのために、解析が複雑になる場合があり、解析に長時間を要してしまう場合もある。   In this way, when the error factor detected by the B protocol checker 220b for the output of the verification target 300 is in the input pattern for the verification target 300, the error detection point (X portion) and the input pattern (Y Part)), a time difference T occurs. If there is an error factor in the scenario 211a and it is attempted to identify the factor from the waveform data, the analysis may be complicated due to the time difference T, and the analysis may take a long time.

尚、このような課題に対し、検証対象３００への入力パターンの制約違反のチェックを行うチェッカを開発することも考えられる。例えば、Ａプロトコルチェッカ２２０ａに検証対象３００への入力パターンをチェックするアサーションを実装することで、課題の改善には繋がる。しかし、チェッカ開発工数が増える、チェッカ開発が完了しないとチェックが行えない等、根本的な解決には至らない。   It is also conceivable to develop a checker that checks for violations of input pattern constraints on the verification target 300 for such a problem. For example, by implementing an assertion for checking the input pattern to the verification target 300 in the A protocol checker 220a, the problem can be improved. However, the checker development man-hours increase and the check cannot be performed unless the checker development is completed.

シナリオは、例えば次のような作業フローで開発されている。
図６はシナリオ開発作業フローの一例を示す図である。
図６のシナリオ開発作業フローでは、開発者が、検証対象の設計に用いる仕様書（Ｓ４０）を基に、シナリオの仕様の検討を行い（Ｓ４１）、シナリオに設定する設定手順（Ｓ４２）、シナリオを設定するうえでの制限事項（設定制限事項）（Ｓ４３）を抽出する。開発者は、抽出したこれらの情報を基に、シナリオを作成し（Ｓ４４，Ｓ４５）、それを組み込んだテストベンチを取得する（Ｓ４６，Ｓ４７）。そして、取得したテストベンチの動作確認のため、コンピュータを用いてシミュレーションを行い（Ｓ４８）、その結果（波形データ）を取得する（Ｓ４９）。 The scenario is developed by the following work flow, for example.
FIG. 6 is a diagram illustrating an example of a scenario development work flow.
In the scenario development work flow of FIG. 6, the developer examines the specification of the scenario based on the specification (S40) used for the design to be verified (S41), the setting procedure (S42) for setting the scenario, the scenario The restriction item (setting restriction item) (S43) is extracted. Based on the extracted information, the developer creates a scenario (S44, S45), and acquires a test bench incorporating the scenario (S46, S47). Then, in order to confirm the operation of the acquired test bench, a simulation is performed using a computer (S48), and the result (waveform data) is acquired (S49).

シナリオ開発段階でのテストベンチの構成例を図７に示す。
シナリオ開発段階のシミュレーション（Ｓ４８）に用いるテストベンチ２００Ａは、検証対象３００、その検証対象３００を動作させる、シナリオ２１１及びトランザクタ２１２を含むモデル２１０を備えている（シナリオ開発環境）。 FIG. 7 shows a configuration example of the test bench at the scenario development stage.
The test bench 200A used for the scenario development stage simulation (S48) includes a verification target 300 and a model 210 including a scenario 211 and a transactor 212 for operating the verification target 300 (scenario development environment).

シナリオ開発環境には、検証対象の入出力をチェックする機能が設けられていない。そのため、シミュレーション時（Ｓ４８）には、波形データを取得し（Ｓ４９）、その波形データを目視確認することで（Ｓ５０）、シナリオの動作を確認する。動作確認の結果、シナリオに問題が見つかった場合には、修正したシナリオを作成し（Ｓ４４，Ｓ４５）、それを組み込んだテストベンチを取得して（Ｓ４６，Ｓ４７）、再度シミュレーションを行い（Ｓ４８，Ｓ４９）、その波形データを確認する（Ｓ５０）。動作確認でシナリオに問題がなく（Ｓ５０）、更に異なる条件でシミュレーション（テスト）を行う場合には（Ｓ５１）、シミュレーション条件を変更してテストを行う（Ｓ４８）。エラーなく全てのテストが終了すれば（Ｓ５１）、シナリオ開発作業は終了となる。   The scenario development environment does not have a function for checking input / output to be verified. Therefore, during simulation (S48), waveform data is acquired (S49), and the waveform data is visually confirmed (S50) to confirm the scenario operation. As a result of the operation check, if a problem is found in the scenario, a corrected scenario is created (S44, S45), a test bench incorporating the same is acquired (S46, S47), and simulation is performed again (S48, S47). S49), the waveform data is confirmed (S50). When there is no problem in the scenario in the operation check (S50) and simulation (test) is performed under different conditions (S51), the simulation conditions are changed and the test is performed (S48). If all tests are completed without error (S51), the scenario development work is completed.

シナリオは、例えば上記図６のような作業フローで開発が可能であるが、以下のような課題もある。
例えば、上記図６の作業フローでは、シナリオの動作確認を、シミュレーション時（Ｓ４８）に取得した波形データ（Ｓ４９）の目視確認によって行っている（Ｓ５０）。 The scenario can be developed with the work flow as shown in FIG. 6, for example, but has the following problems.
For example, in the work flow of FIG. 6, the scenario operation is confirmed by visual confirmation of the waveform data (S49) acquired during the simulation (S48) (S50).

シナリオは、検証対象の状態やその受信状態よって、生成する入力パターンが変わるため、組み合わせを考慮すると、膨大な入力パターンが存在し得る。それら全ての組み合わせについて、波形データを目視で確認し、シナリオの動作確認を行うことは、困難である。そのため、組み合わせを考慮しない、機能毎の動作確認までしか行わない場合もある。   In the scenario, the input pattern to be generated varies depending on the state to be verified and the reception state thereof. Therefore, there are a large number of input patterns in consideration of combinations. For all these combinations, it is difficult to visually check the waveform data and check the operation of the scenario. Therefore, there is a case where only the operation check for each function is performed without considering the combination.

このようにしてシナリオの動作確認を行い、その開発作業を完了させたとしても、全入力パターンの動作確認が済んでいるわけではないため、シナリオが設定制限事項に違反した入力パターンを生成してしまう等、その後の工程に影響を及ぼしてしまう場合がある。例えば、上記図３のテストベンチ開発作業フローで述べた全体シミュレーション（Ｓ２７，Ｓ２８）、更にその結果に基づく再シミュレーション（Ｓ２９〜Ｓ３１）において、上記のようなシナリオ要因の問題が発生してしまう場合がある。   Even if you confirm the operation of the scenario in this way and complete its development work, the operation check of all input patterns is not completed, so the scenario generates an input pattern that violates the setting restrictions. In some cases, it may affect subsequent processes. For example, in the case of the overall simulation (S27, S28) described in the test bench development work flow of FIG. 3 and the re-simulation (S29 to S31) based on the result, the above scenario factor problem occurs. There is.

以上説明したように、検証対象の論理回路検証に用いるシナリオの開発（及びシナリオを組み込んだテストベンチの開発）においては、検証の早い段階で、適正な、安定した品質のシナリオを取得することが難しい。適正なシナリオを取得するために、開発中のシナリオ、テストベンチを実際に動作させたときの波形データを取得し、それを開発者が目視で確認する作業が必要になるため、開発に時間を要してしまう。   As described above, in the development of a scenario used for verification of a logic circuit to be verified (and development of a test bench incorporating a scenario), an appropriate and stable quality scenario can be acquired at an early stage of verification. difficult. In order to acquire an appropriate scenario, it is necessary to acquire the scenario data under development and the waveform data when the test bench is actually operated, and the developer must visually check it. I need it.

また、以上の説明では、シナリオ（及びシナリオを組み込んだテストベンチ）の開発を例にしたが、論理回路を制御するファームウェアの開発においても同様のことが起こり得る。   In the above description, the scenario (and the test bench incorporating the scenario) is taken as an example. However, the same may occur in the development of firmware that controls a logic circuit.

即ち、ファームウェアの開発段階では、作成したファームウェアを用いて論理回路を動作させ、エラーが検出された場合には、波形データの目視確認が行われる。このとき、エラー要因が論理回路側にあるのか、ファームウェア側にあるのかの判定に時間がかかってしまう。これは、上記図５において述べたのと同様に、エラーの発生タイミングとそのエラーを引き起こしたファームウェアの命令タイミングに時間差があり、波形データを用いた解析が複雑になるためである。このように論理回路を制御するためのファームウェアでも、その動作確認に時間を要してしまい、論理回路検証の早い段階で、適正な、安定した品質のファームウェアを取得することが難しい。   That is, at the firmware development stage, the logic circuit is operated using the created firmware, and when an error is detected, the waveform data is visually confirmed. At this time, it takes time to determine whether the error factor is on the logic circuit side or the firmware side. This is because, as described with reference to FIG. 5, there is a time difference between the error occurrence timing and the firmware instruction timing that caused the error, which complicates the analysis using the waveform data. Even in the case of firmware for controlling a logic circuit, it takes time to check its operation, and it is difficult to obtain firmware with appropriate and stable quality at an early stage of logic circuit verification.

シナリオ、ファームウェアのいずれの場合においても、それらを実際に動作させたときに取得される波形データの目視確認を行うことが、それらの開発効率を低下させ、更に、検証対象である論理回路の検証作業効率を低下させる一因になっている。   In both scenarios and firmware, visual confirmation of the waveform data acquired when they are actually operated reduces their development efficiency and further verifies the logic circuit to be verified. This contributes to a reduction in work efficiency.

そこで以下では、このような波形データの目視確認によらずに、適正なシナリオ、ファームウェアを効率的に取得する手法について、詳細に説明していく。ここでは主にシナリオを例に説明する。   Therefore, in the following, a method for efficiently acquiring an appropriate scenario and firmware without using such visual confirmation of waveform data will be described in detail. Here, a scenario will be mainly described as an example.

図８はシナリオ開発作業フローの一例を示す図である。
図８のシナリオ開発作業フローでは、上記図６で述べた作業フロー同様、まず開発者が、検証対象の設計に用いる仕様書（Ｓ６０）を基に、シナリオの仕様の検討を行い（Ｓ６１）、シナリオの設定手順（Ｓ６２）、シナリオの設定制限事項（Ｓ６３）を抽出する。開発者は、抽出したこれらの情報を基に、シナリオを作成する（Ｓ６４，Ｓ６５）。 FIG. 8 is a diagram showing an example of a scenario development work flow.
In the scenario development work flow of FIG. 8, like the work flow described in FIG. 6 above, the developer first reviews the specifications of the scenario based on the specifications (S60) used for the design to be verified (S61), Scenario setting procedure (S62) and scenario setting restrictions (S63) are extracted. The developer creates a scenario based on the extracted information (S64, S65).

シナリオの作成後、この図８のシナリオ開発作業フローでは、開発者が、シナリオの仕様検討時に抽出した設定制限事項（Ｓ６３）、及び作成したシナリオ（Ｓ６５）を基に、設定制限リストを作成する（Ｓ６６，Ｓ６７）。設定制限リストには、例えば、作成したシナリオの所定記述部分の命令実行を制限する、上記設定制限事項の内容に対応した情報（制限情報）や、その記述部分に対応する所定行番号等の情報が含まれる。尚、設定制限リストの詳細については後述する。   After the scenario is created, in the scenario development work flow of FIG. 8, the developer creates a setting restriction list based on the setting restriction items (S63) extracted at the time of reviewing the scenario specifications and the created scenario (S65). (S66, S67). In the setting restriction list, for example, information (restriction information) corresponding to the contents of the above-mentioned setting restriction items restricting the command execution of the predetermined description part of the created scenario, information such as a predetermined line number corresponding to the description part Is included. Details of the setting restriction list will be described later.

そして、コンピュータを用い、このような設定制限リスト（Ｓ６７）を入力とし、シナリオの動作をチェックするためのシナリオチェッカを自動生成する（Ｓ６８，Ｓ６９）。コンピュータは、例えば、設定制限リスト（Ｓ６７）の内容を、シナリオと同じ言語を用いて、所定記述のシナリオチェッカに書き換える。シナリオチェッカは、例えば、上記したシナリオの所定記述部分の命令が実行されるときに、その命令が上記制限情報を含むか否か、即ち、命令（入力パターン）が設定制限事項に違反していないかをチェックする。尚、この点の詳細については後述する。   Then, a scenario checker for checking the operation of the scenario is automatically generated (S68, S69) using such a setting restriction list (S67) as input. For example, the computer rewrites the contents of the setting restriction list (S67) into a scenario checker with a predetermined description using the same language as the scenario. The scenario checker, for example, when an instruction of a predetermined description part of the scenario described above is executed, whether or not the instruction includes the restriction information, that is, the instruction (input pattern) does not violate a setting restriction item. To check. Details of this point will be described later.

設定制限リスト（Ｓ６７）は、このシナリオチェッカの生成のほか（Ｓ６８，Ｓ６９）、シナリオへのシナリオチェッカ組み込み処理に用いられる（Ｓ７０，Ｓ７１）。コンピュータは、例えば、設定制限リスト（Ｓ６７)に示された、上記したシナリオの所定記述部分に対応した行番号を基に、シナリオのその行番号の箇所に、生成したシナリオチェッカ（Ｓ６９）を呼び出すための命令文を挿入する（Ｓ７０）。これにより、当該所定記述部分の命令実行時に、生成されたシナリオチェッカ（Ｓ６９）を呼び出し可能にしたシナリオが取得される（Ｓ７１）。尚、この点の詳細については後述する。   The setting restriction list (S67) is used for generating a scenario checker (S68, S69) and for incorporating a scenario checker into a scenario (S70, S71). The computer, for example, calls the generated scenario checker (S69) at the position of the scenario line number based on the line number corresponding to the predetermined description portion of the scenario shown in the setting restriction list (S67). Is inserted (S70). As a result, a scenario in which the generated scenario checker (S69) can be called at the time of executing the instruction of the predetermined description portion is acquired (S71). Details of this point will be described later.

開発者は、このようにして取得されたシナリオチェッカ（Ｓ６９）と、そのシナリオチェッカ（Ｓ６９）を所定記述部分で呼び出し可能なシナリオ（Ｓ７１）とを組み込んだテストベンチを取得する（Ｓ７２，Ｓ７３）。   The developer acquires a test bench incorporating the scenario checker (S69) acquired in this way and a scenario (S71) that can call the scenario checker (S69) in a predetermined description part (S72, S73). .

シナリオ開発段階でのテストベンチの構成例を図９に示す。
シナリオ開発段階のテストベンチ２００Ａは、検証対象３００、その検証対象３００を駆動するモデル２１０であるシナリオ２１１及びトランザクタ２１２を備えている（シナリオ開発環境）。このシナリオ２１１に、シナリオチェッカ２１３が、所定記述部分で呼び出されるように組み込まれている。 A configuration example of the test bench at the scenario development stage is shown in FIG.
The test bench 200A in the scenario development stage includes a verification target 300, a scenario 211 that is a model 210 that drives the verification target 300, and a transactor 212 (scenario development environment). In this scenario 211, a scenario checker 213 is incorporated so as to be called in a predetermined description part.

シナリオ２１１に従って検証対象３００を動作させると、シナリオ２１１の当該所定記述部分でシナリオチェッカ２１３が呼び出される。呼び出されたシナリオチェッカ２１３は、シナリオ２１１からの命令（入力パターン）に上記制限情報が含まれていないか、即ち、設定制限事項に違反した入力パターンが生成されていないか、チェックする。このようなチェックが、続く、コンピュータを用いたシミュレーション（Ｓ７４）によって行われる。   When the verification target 300 is operated according to the scenario 211, the scenario checker 213 is called at the predetermined description portion of the scenario 211. The called scenario checker 213 checks whether or not the restriction information is included in the command (input pattern) from the scenario 211, that is, whether or not an input pattern that violates the setting restriction items is generated. Such a check is performed by a subsequent computer simulation (S74).

即ち、取得したテストベンチの動作確認のため、コンピュータを用いたシミュレーションが行われ（Ｓ７４）、コンピュータが、そのシミュレーション結果の情報（ログファイル）を生成する（Ｓ７５）。ここで生成されるシミュレーション結果の情報は、テストベンチにシナリオチェッカが組み込まれているため、シナリオチェッカでエラーを検出したか否かを示すログファイルとなる。上記図６で述べた作業フローにおけるように、シミュレーション結果として、必ずしも波形データを取得することを要しない。   That is, in order to confirm the operation of the acquired test bench, a simulation using a computer is performed (S74), and the computer generates information (log file) of the simulation result (S75). The simulation result information generated here is a log file indicating whether an error is detected by the scenario checker because the scenario checker is incorporated in the test bench. As in the work flow described in FIG. 6, it is not always necessary to acquire waveform data as a simulation result.

開発者は、シミュレーション結果のログファイルの情報を基に、シナリオから検証対象に対し、設定制限事項に違反しない、適正な命令（入力パターン）が入力されたか否かを判断することができ、そのシナリオの動作確認を行うことができる（Ｓ７６）。従って、シナリオの動作確認のために、上記のような波形データの目視確認を行うことが不要になり、シナリオの動作確認を効率的に行うことができる。   The developer can determine whether or not an appropriate command (input pattern) that does not violate the setting restrictions is input from the scenario to the verification target based on the log file information of the simulation result. The operation of the scenario can be confirmed (S76). Therefore, it is not necessary to visually check the waveform data as described above for the scenario operation confirmation, and the scenario operation confirmation can be performed efficiently.

作成したシナリオの動作確認の結果、エラーが検出された場合には、修正したシナリオを作成する（Ｓ６４，Ｓ６５）。そして、上記同様、設定制限リストの作成（Ｓ６６，Ｓ６７）、シナリオチェッカの生成（Ｓ６８，Ｓ６９）及び組み込み（Ｓ７０，Ｓ７１）を行い、テストベンチを取得して（Ｓ７２，Ｓ７３）、再度シミュレーションを行う（Ｓ７４，Ｓ７５）。そのログファイルの情報から、修正したシナリオの動作確認を行う（Ｓ７６）。   If an error is detected as a result of checking the operation of the created scenario, a corrected scenario is created (S64, S65). Then, as described above, the setting restriction list is created (S66, S67), the scenario checker is generated (S68, S69) and incorporated (S70, S71), the test bench is acquired (S72, S73), and the simulation is performed again. Perform (S74, S75). From the log file information, the operation of the corrected scenario is confirmed (S76).

動作確認でエラーが検出されず（Ｓ７６）、更に異なる条件でシミュレーション（テスト）を行う場合には（Ｓ７７）、シミュレーション条件を変更してテストを行う（Ｓ７４）。エラーなく全てのテストが終了すれば（Ｓ７７）、シナリオ開発作業は終了となる。   If no error is detected in the operation check (S76) and simulation (test) is performed under different conditions (S77), the simulation conditions are changed and the test is performed (S74). If all tests are completed without error (S77), the scenario development work is completed.

更に、シナリオ開発後の工程について説明する。
図１０はテストベンチ開発作業フローの一例を示す図である。
図１０のテストベンチ開発作業フローでは、上記図３で述べた作業フロー同様、開発者が、テストベンチ仕様書（Ｓ８０）を基に、テストベンチの構成要素の部品毎に、チェッカの開発（Ｓ８１）、トランザクタの開発（Ｓ８２）、シナリオの開発（Ｓ８３，Ｓ６０〜Ｓ７７）を行う。そして、テスト済みの各部品を取得し（Ｓ８４）、それらを組み込んだテストベンチを取得する（Ｓ８５，Ｓ８６）。 Furthermore, the process after scenario development is demonstrated.
FIG. 10 is a diagram showing an example of a test bench development work flow.
In the test bench development work flow of FIG. 10, as in the work flow described in FIG. 3, the developer develops a checker for each component of the test bench based on the test bench specification (S80) (S81). ), Transactor development (S82) and scenario development (S83, S60 to S77). Then, each tested part is acquired (S84), and a test bench incorporating them is acquired (S85, S86).

テストベンチ開発段階でのテストベンチの構成例を図１１に示す。
図１１のテストベンチ２００は、シナリオ２１１及びトランザクタ２１２を含むモデル２１０、プロトコルチェッカ２２０、及び期待値比較チェッカ２３０を備えている（テストベンチ開発環境）。このシナリオ２１１に、シナリオチェッカ２１３が組み込まれている。 FIG. 11 shows a configuration example of the test bench at the test bench development stage.
The test bench 200 of FIG. 11 includes a model 210 including a scenario 211 and a transactor 212, a protocol checker 220, and an expected value comparison checker 230 (test bench development environment). In this scenario 211, a scenario checker 213 is incorporated.

シナリオ開発（図９）で用いられたシナリオチェッカは、シナリオに組み込まれた構成（呼び出し可能な構成）になっており、テストベンチ開発のテストベンチにおいてもそのまま用いることができる。このようなテストベンチ（Ｓ８６）を用いて、上記図３で述べた作業フロー同様、検証対象の論理回路を動作させる全体シミュレーションを行う（Ｓ８７）。この全体シミュレーションの結果は、テストベンチに組み込まれたチェッカ（プロトコルチェッカ、期待値比較チェッカ、シナリオチェッカ）によるチェック結果のログファイルとして出力される（Ｓ８８）。このログファイルの情報から開発者がエラーの発生有無を判断する（Ｓ８９）。   The scenario checker used in scenario development (FIG. 9) has a configuration incorporated in the scenario (a configuration that can be called), and can be used as it is in a test bench for test bench development. By using such a test bench (S86), an overall simulation for operating the logic circuit to be verified is performed (S87) as in the work flow described in FIG. The result of this overall simulation is output as a log file of the check results by checkers (protocol checker, expected value comparison checker, scenario checker) incorporated in the test bench (S88). From the information in the log file, the developer determines whether an error has occurred (S89).

ここで、シナリオチェッカによりエラーが検出されている場合には（Ｓ８９）、シナリオ開発（Ｓ８３）に戻り、シナリオのエラー要因を修正する。ここではシナリオチェッカを設けているため、このように全体シミュレーション（Ｓ８７）のログファイルの結果確認段階で、シナリオのエラー（シナリオミス）を検出することが可能になっている。そのため、検証の比較的早い段階でシナリオの修正を行い、適正なシナリオを作成することができる。また、この時点でシナリオチェッカのエラーがなく、その他のチェッカエラーが検出されていれば、そのエラー要因が、検証対象か、テストベンチのシナリオ以外の部品にあると判断することができる。   If an error is detected by the scenario checker (S89), the process returns to scenario development (S83) to correct the scenario error factor. Since the scenario checker is provided here, it is possible to detect a scenario error (scenario error) at the result confirmation stage of the log file of the entire simulation (S87). Therefore, it is possible to correct the scenario at a relatively early stage of verification and create an appropriate scenario. Further, if there is no scenario checker error at this time and other checker errors are detected, it can be determined that the cause of the error is a verification target or a part other than the test bench scenario.

シナリオ以外についてのエラーが検出されている場合には（Ｓ８９）、コンピュータを用いた再シミュレーションを行って波形データを取得する（Ｓ９０，Ｓ９１）。取得した波形データを開発者が目視で確認し、エラー要因を特定する（Ｓ９２）。   If an error other than the scenario is detected (S89), re-simulation using a computer is performed to acquire waveform data (S90, S91). The developer visually confirms the acquired waveform data, and identifies the cause of the error (S92).

エラー要因が検証対象の論理回路側にある場合には（Ｓ９３）、開発者が、その論理回路の修正を行い（Ｓ９４）、修正後の論理回路を作成し（Ｓ９５）、修正後の論理回路と共に、再度テストベンチを取得する（Ｓ８５，Ｓ８６）。そして、その再取得したテストベンチを用いて全体シミュレーション（Ｓ８７）以降の作業を実施する。   When the error factor is on the logic circuit to be verified (S93), the developer corrects the logic circuit (S94), creates a corrected logic circuit (S95), and corrects the logic circuit. At the same time, the test bench is acquired again (S85, S86). And the operation | movement after the whole simulation (S87) is implemented using the re-acquired test bench.

エラー要因がテストベンチ側にある場合、エラー要因は、テストベンチ内のトランザクタ又はチェッカに分けられる（Ｓ９６）。トランザクタにエラー要因（トランザクタミス）がある場合には（Ｓ９６）、トランザクタ開発（Ｓ８２）に戻り、トランザクタのエラー要因を修正する。チェッカにエラー要因（チェッカミス）がある場合には（Ｓ９６）、チェッカ開発（Ｓ８１）に戻り、チェッカのエラー要因を修正する。そして、上記同様、単体テストを実施して各部品を取得し（Ｓ８４）、テストベンチを取得（Ｓ８５，Ｓ８６）して、全体シミュレーション（Ｓ８７）以降の作業を実施する。   When the error factor is on the test bench side, the error factor is divided into a transactor or a checker in the test bench (S96). If there is an error factor (transactor miss) in the transactor (S96), the process returns to transactor development (S82) to correct the transactor error factor. If there is an error factor (checker miss) in the checker (S96), the process returns to the checker development (S81) to correct the checker error factor. Then, as described above, the unit test is performed to acquire each part (S84), the test bench is acquired (S85, S86), and the work after the entire simulation (S87) is performed.

全体シミュレーションでエラーが検出されず（Ｓ８９）、更に異なる条件で全体シミュレーション（テスト）を行う場合には（Ｓ９７）、シミュレーション条件を変更してテストを行う（Ｓ８７）。エラーなく全てのテストが終了すれば（Ｓ９７）、テストベンチ開発作業は終了となる。   If no error is detected in the entire simulation (S89) and the entire simulation (test) is performed under different conditions (S97), the simulation conditions are changed and the test is performed (S87). If all tests are completed without error (S97), the test bench development work is completed.

このように、シナリオにシナリオチェッカを組み込むことで、シナリオ開発及びテストベンチ開発において、シナリオミスについては、シミュレーションによる波形データの取得、取得した波形データの目視確認を不要にすることができる。それにより、適正なシナリオを比較的早期に作成することができ、シナリオ開発を効率化し、更に、テストベンチ開発、論理回路検証の効率化を図ることができる。   As described above, by incorporating the scenario checker into the scenario, in scenario development and test bench development, acquisition of waveform data by simulation and visual confirmation of the acquired waveform data can be eliminated for scenario mistakes. Thereby, an appropriate scenario can be created relatively early, scenario development can be made more efficient, and further, test bench development and logic circuit verification can be made more efficient.

上記図８のシナリオ開発作業フローには、上記図６の作業フローと異なり、設定制限リストの作成（Ｓ６６，Ｓ６７）、シナリオチェッカの生成（Ｓ６８，Ｓ６９）、シナリオチェッカの組み込み（Ｓ７０，Ｓ７１）、ログファイルの確認（Ｓ７５，Ｓ７６）を含む。これらのステップを含むことにより、上記のようなシナリオ開発の効率化が図られている。これらの各ステップは、以下のように行われる。   In the scenario development work flow of FIG. 8, unlike the work flow of FIG. 6, the creation of a setting restriction list (S66, S67), generation of a scenario checker (S68, S69), and incorporation of a scenario checker (S70, S71) Log file confirmation (S75, S76). By including these steps, the efficiency of scenario development as described above is improved. Each of these steps is performed as follows.

まず、設定制限リスト作成ステップ（Ｓ６６，Ｓ６７）について説明する。
設定制限リスト（Ｓ６７）の作成は、開発者が行う。設定制限リストの作成は、設定制限事項（Ｓ６３）及びシナリオ（Ｓ６５）を入力として行われる。 First, the setting restriction list creation step (S66, S67) will be described.
The developer creates the setting restriction list (S67). The setting restriction list is created with the setting restriction item (S63) and the scenario (S65) as inputs.

設定制限事項には、検証対象に対する入力動作（命令）を制限する制限事項の内容が、自然言語で記載されているものとする。また、入力動作を制限する各事項について、対応する番号（Ｎｏ．）が付与されているものとする。シナリオは、トランザクタへの命令を記述したソースコードである。このような設定制限事項及びシナリオを用いて、開発者が設定制限リストを作成する。   In the setting restriction item, the content of the restriction item that restricts the input operation (command) for the verification target is described in a natural language. Further, it is assumed that a corresponding number (No.) is assigned to each item that restricts the input operation. A scenario is source code that describes instructions to a transactor. The developer creates a setting restriction list using such setting restriction items and scenarios.

図１２に設定制限リストのフォーマットの一例を示す。
図１２の設定制限リストのフォーマット４００ａには、各種情報を記入（入力）する欄４０１ａ〜４０６ａが設けられている。 FIG. 12 shows an example of the format of the setting restriction list.
The setting restriction list format 400a of FIG. 12 includes columns 401a to 406a for entering (inputting) various information.

欄４０１ａには、設定制限リストからシナリオチェッカ生成ステップ（Ｓ６８、Ｓ６９）で生成するシナリオチェッカの名称（チェッカ名）が記入される。チェッカ名の欄４０１ａには、生成するシナリオチェッカの機能を表すような任意の文字列が記入される。この欄４０１ａに記入されたチェッカ名は、シナリオチェッカ生成ステップで生成されるファイル名の一部として使用される。また、このチェッカ名は、チェッカエラー時のメッセージに出力される文字列にも使用される。   In the column 401a, the name (checker name) of the scenario checker generated in the scenario checker generation step (S68, S69) from the setting restriction list is entered. In the checker name column 401a, an arbitrary character string representing the function of the scenario checker to be generated is entered. The checker name entered in this column 401a is used as part of the file name generated in the scenario checker generation step. This checker name is also used for a character string output in a message when a checker error occurs.

欄４０２ａには、シナリオ（Ｓ６５）の、設定制限事項（Ｓ６３）に関する入力動作を行う記述がある部分のファイルの名称（参照ファイル名）が記入される。欄４０３ａには、シナリオチェッカ生成ステップで生成されるシナリオチェッカを、上記参照ファイル名のファイル中に挿入する行番号（挿入行番号）が記入される。   In the column 402a, a file name (reference file name) of a part having a description for performing an input operation regarding the setting restriction item (S63) in the scenario (S65) is entered. In the column 403a, a line number (insertion line number) for inserting the scenario checker generated in the scenario checker generation step into the file having the above reference file name is entered.

欄４０４ａのＮｏ．（番号１〜ｎ）は、シナリオの入力動作についての各設定制限事項に対応して付与されている。入力１〜ｍの欄４０５ａには、各設定制限事項の入力動作の内容を決定する変数名が記入される。条件１＿１〜ｎ＿ｍの欄４０６ａには、各設定制限事項の入力動作の内容を決定する変数名（入力１〜ｍ）に対応した具体的な変数が記入される。欄４０６ａのその他条件１〜ｍには、入力１〜ｍの変数名に対応した変数以外の条件が記入される。欄４０５ａ、欄４０６ａは、該当する条件がない場合には空欄とされる。   No. in the column 404a. (Numbers 1 to n) are assigned corresponding to each setting restriction item regarding the scenario input operation. In the input 1 to m column 405a, a variable name that determines the content of the input operation of each setting restriction item is entered. In the conditions 1_1 to n_m column 406a, specific variables corresponding to variable names (inputs 1 to m) for determining the contents of the input operation of each setting restriction item are entered. In the other conditions 1 to m in the column 406a, conditions other than the variables corresponding to the variable names of the inputs 1 to m are entered. The columns 405a and 406a are blank when there is no applicable condition.

開発者は、設定制限事項（Ｓ６３）及びシナリオ（Ｓ６５）を用いて、フォーマット４００ａの各欄４０１ａ〜４０６ａの内容を記入し、設定制限リスト（Ｓ６７）を作成する。尚、設定制限リストを作成するうえで、行数及び列数は、設定制限事項の数（番号の数）及び変数名の数等に応じて適宜調節される。   The developer uses the setting restriction items (S63) and the scenario (S65) to fill in the contents of the respective columns 401a to 406a of the format 400a, and creates the setting restriction list (S67). In creating the setting restriction list, the number of rows and the number of columns are appropriately adjusted according to the number of setting restriction items (number of numbers), the number of variable names, and the like.

続いて、シナリオチェッカ生成ステップ（Ｓ６８，Ｓ６９）について説明する。
シナリオチェッカ（Ｓ６９）の生成は、開発者がシナリオチェッカ生成スクリプトを起動することにより、コンピュータの処理によって行われる。シナリオチェッカの生成は、設定制限リスト（Ｓ６７）を入力として行われる。 Next, the scenario checker generation step (S68, S69) will be described.
The scenario checker (S69) is generated by a computer process when the developer activates a scenario checker generation script. The scenario checker is generated using the setting restriction list (S67) as an input.

シナリオチェッカは１つ又は２つ以上のチェッカを含むファイルである。設定制限リストを入力としてシナリオチェッカ生成スクリプトを実行することにより、設定制限リストの内容を記述したシナリオチェッカが生成され、ファイルに出力される。このときのファイル名は“［チェッカ名］．［拡張子］”となる。拡張子は、テストベンチ（Ｓ７３）で使用する言語に依存する。   A scenario checker is a file that contains one or more checkers. By executing the scenario checker generation script with the setting restriction list as an input, a scenario checker describing the contents of the setting restriction list is generated and output to a file. The file name at this time is “[checker name]. [Extension]”. The extension depends on the language used in the test bench (S73).

生成されるシナリオチェッカの記述内容は、テストベンチで使用する言語によって異なる。但し、いずれの言語においても、シミュレーションを実行してシナリオチェッカがエラーとなったときに、どの設定制限事項に対してのエラーであるかが判別できるようにする。そのため、ログファイルにエラーの内容と共に、“［チェッカ名］＿［番号ｉ］”（ｉ＝１〜ｎ）という文字列（ラベル名）を出力するようなシナリオチェッカを生成する。   The description content of the generated scenario checker differs depending on the language used in the test bench. However, in any language, when a simulation is executed and a scenario checker becomes an error, it is possible to determine which setting restriction item is an error. Therefore, a scenario checker is generated that outputs a character string (label name) “[checker name] _ [number i]” (i = 1 to n) together with the error content to the log file.

続いて、シナリオチェッカ組み込みステップ（Ｓ７０，Ｓ７１）について説明する。
シナリオチェッカ（Ｓ６９）の組み込みは、開発者がシナリオチェッカ組み込みスクリプトを起動することにより、コンピュータの処理によって行われる。シナリオチェッカの組み込みは、設定制限リスト（Ｓ６７）、シナリオチェッカ（Ｓ６９）、シナリオ（６５）を入力として行われる。シナリオチェッカ組み込みスクリプトを実行することで、設定制限リストに記載された参照ファイル名（欄４０２ａ）に該当するファイルの、挿入行番号（欄４０３ａ）に該当する行番号に、シナリオチェッカ（Ｓ６９）のファイルのインクルード文が追加される。 Next, the scenario checker incorporation step (S70, S71) will be described.
The scenario checker (S69) is incorporated by a computer process when the developer starts a scenario checker incorporation script. The scenario checker is incorporated using the setting restriction list (S67), the scenario checker (S69), and the scenario (65) as inputs. By executing the scenario checker built-in script, the scenario checker (S69) has the line number corresponding to the insertion line number (column 403a) of the file corresponding to the reference file name (column 402a) described in the setting restriction list. A file include statement is added.

続いて、ログファイル確認ステップ（Ｓ７５，Ｓ７６）について説明する。
ログファイルの確認は、開発者が行う。ログファイルの確認では、シミュレーションを行った結果が出力されるログファイル（Ｓ７５）の内容から、シナリオチェッカのエラー出力メッセージの有無を確認し、シナリオ修正の要否が判断される。シミュレーションにおいてシナリオチェッカのエラーが発生した場合、ログファイルには、エラーを検出したチェッカ名と、そのエラーの内容を示す情報（設定制限事項の番号）を含んだラベル名の文字列が出力される。このようなログファイルに含まれる情報を基に、シナリオ修正の要否が判断される。 Next, the log file confirmation step (S75, S76) will be described.
The developer checks the log file. In the confirmation of the log file, the presence or absence of a scenario checker error output message is confirmed from the contents of the log file (S75) to which the result of the simulation is output, and the necessity of scenario correction is determined. If a scenario checker error occurs during simulation, the log file will output a character string with a label name that includes the name of the checker that detected the error and information indicating the content of the error (number of setting restrictions) . Based on the information included in such a log file, the necessity of scenario correction is determined.

以下、上記手法を、実施例によって、より具体的に説明する。
まず、第１実施例について説明する。
図１３は第１実施例に係る検証対象とシナリオの関係を示す図である。 Hereinafter, the above method will be described more specifically with reference to examples.
First, the first embodiment will be described.
FIG. 13 is a diagram illustrating the relationship between the verification target and the scenario according to the first embodiment.

第１実施例のテストベンチで使用する言語は、ＳｙｓｔｅｍＶｅｒｉｌｏｇとする。
図１３の検証対象３００はメモリモデルとなっており、内部にレジスタ領域３０１を有している。検証対象３００への入力動作として、レジスタ領域３０１への書き込み動作がある。検証対象３００には、アドレスＡＤＤＲ（３２’ｈ００００００００〜３２’ｈＦＦＦＦＦＦＦＣ）とデータＤＡＴＡを指定した、シナリオ２１１からの書き込み動作の命令が、トランザクタ２１２を介して送られる。検証対象３００では、指定されたアドレスＡＤＤＲの示すレジスタ領域３０１に、指定されたデータＤＡＴＡが格納される。 The language used in the test bench of the first embodiment is SystemVerilog.
The verification target 300 in FIG. 13 is a memory model and has a register area 301 inside. As an input operation to the verification target 300, there is a write operation to the register area 301. A command for a write operation from the scenario 211 that specifies the address ADDR (32′h00000000 to 32′hFFFFFFFC) and data DATA is sent to the verification target 300 via the transactor 212. In the verification target 300, the designated data DATA is stored in the register area 301 indicated by the designated address ADDR.

即ち、まずシナリオ２１１において、レジスタ領域３０１への書き込み動作のアドレスＡＤＤＲとデータＤＡＴＡの内容を決定する。次いで、シナリオ２１１がトランザクタ２１２に、レジスタ領域３０１への書き込み動作を行うように、アドレスＡＤＤＲとデータＤＡＴＡの情報を与えて命令する。トランザクタ２１２が検証対象３００に対してレジスタ領域３０１への書き込み動作の入力動作を行い、検証対象３００にアドレスＡＤＤＲとデータＤＡＴＡの情報を伝える。検証対象３００は、トランザクタ２１２からのレジスタ領域３０１への書き込み動作の情報を受けて、指定されたアドレスＡＤＤＲのレジスタ領域３０１に、指定されたデータＤＡＴＡを格納する。   That is, first, in the scenario 211, the address ADDR of the write operation to the register area 301 and the contents of the data DATA are determined. Next, the scenario 211 instructs the transactor 212 by giving the information of the address ADDR and the data DATA so as to perform the write operation to the register area 301. The transactor 212 performs an input operation of a write operation to the register area 301 with respect to the verification target 300, and transmits the address ADDR and data DATA information to the verification target 300. The verification target 300 receives the information of the write operation to the register area 301 from the transactor 212 and stores the specified data DATA in the register area 301 of the specified address ADDR.

第１実施例では、このようなレジスタ領域３０１への書き込み動作に関し、シナリオ２１１を設定するうえでの設定制限事項があるものとする。図１４は第１実施例に係る設定制限事項の一例を示す図である。図１４に例示する設定制限事項５００では、まず第１（Ｎｏ．０００１）の設定制限事項の内容として、アドレス３２’ｈ００００００００に対して３２’ｈ０００００００１の書き込み禁止が設定されている。更に、第２（Ｎｏ．０００２）の設定制限事項の内容として、ｔｏｐ．ＲＥＡＤＹｏ＝＝０のときアドレス３２’ｈ０００００００４に対して書き込み禁止が設定されている。   In the first embodiment, it is assumed that there is a setting restriction item for setting the scenario 211 regarding such a write operation to the register area 301. FIG. 14 is a diagram illustrating an example of setting restriction items according to the first embodiment. In the setting restriction item 500 illustrated in FIG. 14, first, as the contents of the first (No. 0001) setting restriction item, write prohibition of 32′h00000001 is set for the address 32′h00000000. Furthermore, as the contents of the second (No. 0002) setting restriction item, top. When READYo == 0, write prohibition is set for the address 32'h00000004.

図１５は第１実施例に係るシナリオの記述部分の一例を示す図である。図１５には、第１実施例のシナリオ２１１に含まれるレジスタ領域３０１への書き込み動作を行う記述部分（一部）を例示している。第１実施例のシナリオ２１１には、“ｓｃｅｎａｒｉｏ．ｓｖ”という名称のファイル２１１ｆａが含まれており、このファイル２１１ｆａに、レジスタ領域３０１への書き込み動作を行う記述（ｗｒｉｔｅ＿ａｃｃｅｓｓタスク）が含まれている。   FIG. 15 is a diagram illustrating an example of a description part of a scenario according to the first embodiment. FIG. 15 illustrates a description part (part) of performing a write operation to the register area 301 included in the scenario 211 of the first embodiment. The scenario 211 of the first embodiment includes a file 211fa named “scenario.sv”, and the file 211fa includes a description (write_access task) for performing a write operation to the register area 301. .

上記のような設定制限事項５００及びシナリオ２１１を用いた設定制限リストの作成を、例えば、図１６〜図１９のような流れで行っていく。
設定制限リスト４００の作成では、まず図１６のように、生成しようとするシナリオチェッカの機能を表すような任意の文字列、ここでは“ＷＲＩＴＥ”という文字列を、チェッカ名の欄４０１（図１２のフォーマット４００ａの欄４０１ａ）に記入する。 The creation of the setting restriction list using the setting restriction item 500 and the scenario 211 as described above is performed, for example, according to the flow shown in FIGS.
In creating the setting restriction list 400, first, as shown in FIG. 16, an arbitrary character string representing the function of the scenario checker to be generated, in this case, a character string “WRITE” is entered in the checker name column 401 (FIG. 12). In the column 401a) of the format 400a.

次いで、図１７のように、設定制限事項５００に関する入力動作を行う記述のあるファイル２１１ｆａの名称“ｓｃｅｎａｒｉｏ．ｓｖ”を、参照ファイル名の欄４０２（図１２のフォーマット４００ａの欄４０２ａ）に記入する。更に、後のシナリオチェッカ生成ステップで生成されるファイルを“ｓｃｅｎａｒｉｏ．ｓｖ”内でインクルードする行番号を、挿入行番号の欄４０３（図１２のフォーマット４００ａの欄４０３ａ）に記入する。この第１実施例では、生成されるファイルを、レジスタ領域３０１に対する書き込み動作の内容（アドレスＡＤＤＲ、データＤＡＴＡ）を参照できる箇所である１０１行目に挿入することになるため、欄４０３には“１０１”を記入する。   Next, as shown in FIG. 17, the name “scenario.sv” of the file 211fa containing the description for performing the input operation regarding the setting restriction item 500 is entered in the reference file name column 402 (column 402a of the format 400a in FIG. 12). . Further, the line number for including the file generated in the later scenario checker generation step in “scenario.sv” is entered in the insertion line number column 403 (the column 403a of the format 400a in FIG. 12). In this first embodiment, the generated file is inserted into the 101st line, where the contents of the write operation (address ADDR, data DATA) to the register area 301 can be referenced. Enter 101 ".

次いで、図１８のように、入力（変数名）の欄４０５（図１２のフォーマット４００ａの欄４０５ａ（入力１及び入力２））に、変数名を記入する。この第１実施例では、レジスタ領域３０１に対する書き込み動作の内容を決定する変数がアドレスＡＤＤＲとデータＤＡＴＡであるため、欄４０５に“ＡＤＤＲ”及び“ＤＡＴＡ”を記入する。   Next, as shown in FIG. 18, the variable name is entered in the input (variable name) column 405 (the column 400a (input 1 and input 2) of the format 400a in FIG. 12). In this first embodiment, since the variables that determine the content of the write operation to the register area 301 are the address ADDR and data DATA, “ADDR” and “DATA” are entered in the column 405.

次いで、設定制限事項５００に記載されている内容を解釈して、図１９のように、各条件の欄４０６（図１２のフォーマット４００ａの欄４０６ａ）に、具体的な条件を記入する。第１実施例では、Ｎｏ．０００１の設定制限事項について、“ＡＤＤＲ”に対して“３２’ｈ００００００００”を記入し、“ＤＡＴＡ”に対して“３２’ｈ０００００００１”を記入し、その他条件は空欄とする。また、Ｎｏ．０００２の設定事項については、“ＡＤＤＲ”に対して“３２’ｈ０００００００４”を記入し、“ＤＡＴＡ”は空欄とし、その他条件に対して“ｔｏｐ．ＲＥＡＤＹｏ＝＝０”を記入する。   Next, the contents described in the setting restriction item 500 are interpreted, and specific conditions are entered in each condition column 406 (format 400a column 406a in FIG. 12) as shown in FIG. In the first embodiment, no. For the setting restriction item of 0001, “32′h00000000” is entered for “ADDR”, “32′h00000001” is entered for “DATA”, and other conditions are blank. No. For the setting items of 0002, “32′h00000004” is entered for “ADDR”, “DATA” is blank, and “top.READYo == 0” is entered for other conditions.

このようにして設定制限リスト４００の作成が行われる。
続いて、作成された設定制限リスト４００を用いたシナリオチェッカ２１３の生成について、図２０及び図２１を参照して説明する。 In this way, the setting restriction list 400 is created.
Next, generation of the scenario checker 213 using the created setting restriction list 400 will be described with reference to FIGS.

ここでは、ＳｙｓｔｅｍＶｅｒｉｌｏｇを用いている場合を例に説明する。ＳｙｓｔｅｍＶｅｒｉｌｏｇのチェッカのアサーションは、“［ラベル名］：ａｓｓｅｒｔ（［エラー条件］）”というフォーマットになる。［ラベル名］は任意の文字列となり、［エラー条件］はＳｙｓｔｅｍＶｅｒｉｌｏｇの文法における論理式となる。このチェッカがシミュレーション中に実行されたときに、［エラー条件］の論理式が真を示すと、結果(ログファイル)に、［ラベル名］と共に、エラーであることが記録される。   Here, a case where SystemVerilog is used will be described as an example. The assertion of the SystemVerilog checker is in the format “[label name]: assert ([error condition])”. [Label name] is an arbitrary character string, and [Error condition] is a logical expression in the grammar of SystemVerilog. When this checker is executed during simulation, if the logical expression of [error condition] indicates true, the result (log file) is recorded as an error together with [label name].

ＳｙｓｔｅｍＶｅｒｉｌｏｇの場合のシナリオチェッカ生成では、シナリオチェッカ生成スクリプトを実行することにより、作成された設定制限リスト４００を基に、［ラベル名］と［エラー条件］の部分の文字列を生成し、シナリオチェッカ２１３を生成する。シナリオチェッカ２１３は、“［チェッカ名］．ｓｖｈ”というファイル名で生成する。   In the scenario checker generation in the case of SystemVerilog, the scenario checker generation script is executed to generate the character strings of the [label name] and [error condition] parts based on the created setting restriction list 400, and the scenario checker. 213 is generated. The scenario checker 213 is generated with a file name “[checker name] .svh”.

図２０に、シナリオチェッカ生成スクリプトによる設定制限リストからシナリオチェッカへの変換形式を示す。図２０には、設定制限リストのフォーマット４００ａの記載と、それから生成されるシナリオチェッカ２１３の記述との対応を示している。   FIG. 20 shows a conversion format from the setting restriction list to the scenario checker by the scenario checker generation script. FIG. 20 shows a correspondence between the description of the setting restriction list format 400a and the description of the scenario checker 213 generated therefrom.

各Ｎｏ．（番号１〜ｎ）について、それぞれ１つのチェッカが生成される。各チェッカの［ラベル名］は、“チェッカ名＿番号ｉ”（ｉ＝１〜ｎ）という文字列で生成される。［エラー条件］は、例えばＮｏ．０００１では、“（入力１＝＝条件１＿１）＆＆（入力２＝＝条件１＿２）・・・（入力ｍ＝＝条件１＿ｍ）＆＆（その他条件１）”という文字列で生成される。但し、条件が空欄の場合は、その部分の論理式は生成されない。   Each No. One checker is generated for each (number 1 to n). The [label name] of each checker is generated by a character string “checker name_number i” (i = 1 to n). [Error condition] is, for example, “No. In 0001, a character string “(input 1 == condition 1_1) && (input 2 == condition 1_2)... (Input m == condition 1_m) && (other conditions 1)” is generated. However, if the condition is blank, the logical expression for that part is not generated.

第１実施例では次の図２１に示すようになる。
図２１は第１実施例に係るシナリオチェッカ生成スクリプトによる設定制限リストからシナリオチェッカへの変換例を示す図である。 The first embodiment is as shown in FIG.
FIG. 21 is a diagram showing an example of conversion from the setting restriction list to the scenario checker by the scenario checker generation script according to the first embodiment.

図２１のように、設定制限リスト４００より、Ｎｏ．０００１については［ラベル名］が“ＷＲＩＴＥ＿０００１”、［エラー条件］が“ＡＤＤＲ＝＝３２’ｈ００００００００）＆＆（ＤＡＴＡ＝＝３２’ｈ０００００００１）”のチェッカ２１３ａが生成される。また、設定制限リスト４００より、Ｎｏ．０００２については［ラベル名］が“ＷＲＩＴＥ＿０００２”、［エラー条件］が“ＡＤＤＲ＝＝３２’ｈ０００００００４）＆＆（ｔｏｐ．ＲＥＡＤＹｏ＝＝０）”のチェッカ２１３ｂが生成される。   As shown in FIG. For 0001, a checker 213a having [label name] "WRITE_0001" and [error condition] "ADDR == 32'h00000000) && (DATA == 32'h00000001)" is generated. From the setting restriction list 400, No. For 0002, a checker 213b with [label name] "WRITE_0002" and [error condition] "ADDR == 32'h00000004) && (top.READYo = 0)" is generated.

このようなチェッカ２１３ａ，２１３ｂを含むシナリオチェッカ２１３のファイル名は、“ＷＲＩＴＥ．ｓｖｈ”となる。
続いて、生成されたシナリオチェッカの組み込みについて、図２２を参照して説明する。 The file name of the scenario checker 213 including such checkers 213a and 213b is “WRITE.svh”.
Next, incorporation of the generated scenario checker will be described with reference to FIG.

図２２は第１実施例に係るシナリオチェッカ組み込みスクリプトによるシナリオチェッカのシナリオへの組み込み例を示す図である。
図２２のように、シナリオチェッカ組み込みスクリプトを実行することで、設定制限リスト４００の情報を基に、シナリオ２１１の“ｓｃｅｎａｒｉｏ．ｓｖ”のファイル２１１ｆａの１０１行目に、“ＷＲＩＴＥ．ｓｖｈ”のインクルード文２１１ｃが挿入される。これにより、図２１のようなシナリオチェッカ２１３がシナリオ２１１に組み込まれた記述（シナリオチェッカ２１３を呼び出し可能な記述）が得られる。 FIG. 22 is a diagram illustrating an example of incorporation of a scenario checker into a scenario by a scenario checker incorporation script according to the first embodiment.
As shown in FIG. 22, by executing the scenario checker embedded script, the “WRITE.svh” inclusion is included in the 101st line of the “scenario.sv” file 211fa of the scenario 211 based on the information of the setting restriction list 400. A sentence 211c is inserted. As a result, a description in which the scenario checker 213 as shown in FIG. 21 is incorporated in the scenario 211 (a description that can call the scenario checker 213) is obtained.

このようなシナリオ２１１を用いたシナリオ開発やテストベンチ開発の段階で行われるシミュレーションの際には、シナリオの“ｓｃｅｎａｒｉｏ．ｓｖ”の記述部分の命令実行時に、“ＷＲＩＴＥ．ｓｖｈ”のシナリオチェッカ２１３が呼び出される。そして、呼び出されたシナリオチェッカ２１３により、シナリオ２１１が実行する命令に、その実行を制限する制限情報（アドレスＡＤＤＲ、データＤＡＴＡ、その他条件）が含まれるか否か（エラー条件の論理式が真を示すか否か）がチェックされる。シナリオ２１１の命令実行を制限する制限情報が含まれていればエラーとなる。エラーか否かのチェック結果は、ログファイルとして出力される。   In the case of a simulation performed at the stage of scenario development or test bench development using such a scenario 211, the scenario checker 213 of “WRITE.svh” is executed at the time of executing an instruction in the description part of “scenario.sv” of the scenario. Called. Then, by the called scenario checker 213, whether or not the instruction executed by the scenario 211 includes restriction information (address ADDR, data DATA, other conditions) for restricting the execution (the logical expression of the error condition is true). Whether or not to show) is checked. If the restriction information for restricting the execution of the instruction of the scenario 211 is included, an error occurs. The result of checking whether there is an error is output as a log file.

続いて、シナリオチェッカを用いたシミュレーションの結果得られるログファイルについて、図２３を参照して説明する。
図２３は第１実施例に係るログファイルの出力例である。 Next, a log file obtained as a result of simulation using a scenario checker will be described with reference to FIG.
FIG. 23 shows an example of log file output according to the first embodiment.

第１実施例のシナリオチェッカ２１３がシミュレーションでエラーを検出した場合、シミュレーションの結果得られるログファイル６００には、チェッカ２１３ａ，２１３ｂの［ラベル名］の文字列が出力される。即ち、この例では、“ＷＲＩＴＥ＿０００１”や“ＷＲＩＴＥ＿０００２”というラベル名６０１がログファイル６００に出力される。   When the scenario checker 213 of the first embodiment detects an error in the simulation, a character string of [label name] of the checkers 213a and 213b is output to the log file 600 obtained as a result of the simulation. That is, in this example, label names 601 such as “WRITE_0001” and “WRITE_0002” are output to the log file 600.

開発者は、シミュレーションの結果得られるログファイル６００を確認し、このようにチェッカ２１３ａ，２１３ｂの［ラベル名］が出力されている場合は、シナリオ２１１にエラーがあるとみなし、シナリオ２１１を修正する工程へ進むことになる。   The developer checks the log file 600 obtained as a result of the simulation, and if the [label name] of the checkers 213a and 213b is output in this way, the scenario 211 is regarded as having an error, and the scenario 211 is corrected. Proceed to the process.

次に、第２実施例について説明する。
上記第１実施例では、レジスタ領域３０１への書き込み動作における設定制限事項の場合について例示したが、このような単一の動作に対するもののほか、ある機能の一連の処理全体に対する設定制限事項の場合も同様に、上記手法を適用することができる。このような例を、第２実施例として説明する。 Next, a second embodiment will be described.
In the first embodiment, the case of the setting restriction item in the write operation to the register area 301 has been illustrated. However, in addition to the single operation as described above, the case of the setting restriction item for the entire series of processes of a certain function is also possible. Similarly, the above method can be applied. Such an example will be described as a second embodiment.

第２実施例の検証対象は、次のような構成を有しているものとする。この検証対象は、ＤＭＡ（Direct Memory Access）機能を有している。検証対象は、複数のＤＭＡ機能設定レジスタを備え、ＤＭＡ機能設定レジスタに行いたい動作の設定を書き込んでＤＭＡ機能が起動されると、ＤＭＡ機能設定レジスタに書き込まれた設定値に従ってＤＭＡ機能の動作を行う。   The verification target of the second embodiment is assumed to have the following configuration. This verification target has a DMA (Direct Memory Access) function. The verification target has a plurality of DMA function setting registers, and when the DMA function is activated by writing the operation setting to be performed in the DMA function setting register, the DMA function operation is performed according to the setting value written in the DMA function setting register. Do.

ＤＭＡ機能設定レジスタには、転送方向（ＯＵＴ／ＩＮ）、ＤＭＡモード（ブロック／デマンド）、バーストモード（ＳＩＮＧＬＥ／ＩＮＣＲ）の各設定項目があるものとする。尚、ＤＭＡモードのブロックは、１回の転送要求にてブロック単位で１回の転送を行うモードを示し、デマンドは、転送要求がアクティブの期間、転送を行うモードを示す。バーストモードのＳＩＮＧＬＥは、１回の転送要求で単独転送を行うモードを示し、ＩＮＣＲは、インクリメント式のバースト転送を行うモードを示す。このほか、ＤＭＡ機能設定レジスタには更に、総転送数（ＬＥＮＧＴＨ）（１６ｂｉｔ）、転送元（ＳＲＣ）アドレス（３２ｂｉｔ）、転送先（ＤＳＴ）アドレス（３２ｂｉｔ）の各設定項目があるものとする。   It is assumed that the DMA function setting register includes setting items for transfer direction (OUT / IN), DMA mode (block / demand), and burst mode (SINGLE / INCR). The DMA mode block indicates a mode in which transfer is performed once in a block unit in response to a single transfer request, and the demand indicates a mode in which transfer is performed while the transfer request is active. SINGLE in the burst mode indicates a mode in which single transfer is performed with a single transfer request, and INCR indicates a mode in which incremental burst transfer is performed. In addition, the DMA function setting register further includes setting items for the total number of transfers (LENGTH) (16 bits), transfer source (SRC) address (32 bits), and transfer destination (DST) address (32 bits).

このような検証対象のＤＭＡ機能の動作に関し、シナリオ２１１を設定するうえでの設定制限事項があるものとする。図２４は第２実施例に係る設定制限事項の一例を示す図である。図２４に例示する設定制限事項５１０では、まずＮｏ．０００１の設定制限事項の内容として、総転送数０でのＤＭＡ起動禁止が設定されている。Ｎｏ．０００２の設定制限事項の内容として、転送方向がＩＮ且つＤＭＡモードがデマンドでのＤＭＡ起動禁止が設定されている。Ｎｏ．０００３の設定制限事項の内容として、ＤＭＡモードがブロック且つバーストモードがＩＮＣＲでのＤＭＡ起動禁止が設定されている。   Regarding the operation of the DMA function to be verified, it is assumed that there are setting restrictions for setting the scenario 211. FIG. 24 is a diagram illustrating an example of setting restriction items according to the second embodiment. In the setting restriction item 510 illustrated in FIG. As the content of the setting restriction item of 0001, DMA activation prohibition with a total transfer number of 0 is set. No. As the contents of the setting restrictions of 0002, DMA activation prohibition is set in which the transfer direction is IN and the DMA mode is demand. No. As the content of the setting restriction item 0003, prohibition of DMA activation when the DMA mode is block and the burst mode is INCR is set.

図２５は第２実施例に係るシナリオの記述部分の一例を示す図である。図２５には、第２実施例のシナリオ２１１に含まれるＤＭＡ機能の起動処理を行う記述部分（一部）を例示している。第２実施例のシナリオ２１１には、“ｓｃｅｎａｒｉｏ．ｓｖ”という名称のファイル２１１ｆｂが含まれており、このファイル２１１ｆｂに、ＤＭＡ機能の起動処理を行う記述（ｄｍａ＿ｐｒｏｃｅｓｓタスク）が含まれている。ｄｍａ＿ｐｒｏｃｅｓｓタスクは、入力されたＤＭＡ機能設定レジスタの設定項目の情報に従ってレジスタの書き込みを行い、一連のＤＭＡ機能の起動処理を行うタスクである。   FIG. 25 is a diagram illustrating an example of a description part of a scenario according to the second embodiment. FIG. 25 exemplifies a description part (a part) for performing the DMA function activation process included in the scenario 211 of the second embodiment. The scenario 211 of the second embodiment includes a file 211fb named “scenario.sv”, and this file 211fb includes a description (dma_process task) for performing DMA function activation processing. The dma_process task is a task for performing a series of DMA function activation processing by writing a register in accordance with the input setting item information of the DMA function setting register.

上記のような設定制限事項５１０及びシナリオ２１１を用いて作成される、第２実施例に係る設定制限リストの一例を図２６に示す。
図２６の設定制限リスト４１０は、上記第１実施例と同様の手順で作成することができる。この第２実施例の設定制限リスト４１０では、チェッカ名の欄４１１（図１２のフォーマット４００ａの欄４０１ａ）に“ＤＭＡ”という文字列が記入される。 FIG. 26 shows an example of a setting restriction list according to the second embodiment created using the setting restriction items 510 and the scenario 211 as described above.
The setting restriction list 410 in FIG. 26 can be created in the same procedure as in the first embodiment. In the setting restriction list 410 of the second embodiment, the character string “DMA” is entered in the checker name column 411 (the column 401a of the format 400a in FIG. 12).

参照ファイル名の欄４１２（図１２のフォーマット４００ａの欄４０２ａ）には、ＤＭＡ機能の起動処理を行う記述のあるファイル２１１ｆｂの名称“ｓｃｅｎａｒｉｏ．ｓｖ”が記入される。   In the reference file name column 412 (the column 402a of the format 400a in FIG. 12), the name “scenario.sv” of the file 211fb having a description for starting the DMA function is entered.

挿入行番号の欄４１３（図１２のフォーマット４００ａの欄４０３ａ）には、シナリオチェッカ生成ステップで生成されるファイルをインクルードする行番号が記入される。この第２実施例では、生成されるファイルを、ＤＭＡ機能の起動処理の内容（ディレクトリＤＩＲ、ＤＭＡモードＤＭＡ＿ＭＯＤＥ、バーストモードＢＵＲＳＴ＿ＭＯＤＥ、ＬＥＮＧＴＨ）を参照できる行である“２０７”が欄４１３に記入される。   In the insertion line number column 413 (the column 403a of the format 400a in FIG. 12), the line number for including the file generated in the scenario checker generation step is entered. In the second embodiment, “207”, which is a line that can refer to the contents of the DMA function activation processing (directory DIR, DMA mode DMA_MODE, burst mode BURST_MODE, LENGTH), is written in the column 413 for the generated file. .

入力（変数名）の欄４１５（図１２のフォーマット４００ａの欄４０５ａ）には、ＤＭＡ機能の起動処理の内容を決定するディレクトリＤＩＲ、ＤＭＡモードＤＭＡ＿ＭＯＤＥ、バーストモードＢＵＲＳＴ＿ＭＯＤＥ、ＬＥＮＧＴＨの各変数名が記入される。   In the input (variable name) column 415 (format 400a column 405a in FIG. 12), the variable names of the directory DIR, DMA mode DMA_MODE, burst mode BURST_MODE, and LENGTH that determine the contents of DMA function activation processing are entered. The

各条件の欄４１６（図１２のフォーマット４００ａの欄４０６ａ）には、設定制限事項５１０の内容が解釈されて具体的な制限情報が記入される。第２実施例では、Ｎｏ．０００１の設定制限事項について、“ＬＥＮＧＴＨ”に対して“１６’ｈ００００”が記入され、それ以外は空欄とされる。Ｎｏ．０００２の設定事項については、“ＤＩＲ”及び“ＤＭＡ＿ＭＯＤＥ”に対して“１’ｂ１”が記入され、それ以外は空欄とされる。Ｎｏ．０００３の設定事項については、“ＤＭＡ＿ＭＯＤＥ”に対して“１’ｂ０”が記入され、“ＢＵＲＳＴ＿ＭＯＤＥ”に対して“１’ｂ１”が記入され、それ以外は空欄とされる。   In each condition column 416 (the column 406a of the format 400a in FIG. 12), the content of the setting restriction item 510 is interpreted and specific restriction information is entered. In the second embodiment, no. For the setting restriction item of 0001, “16′h0000” is entered for “LENGTH”, and the others are blank. No. For the setting items of 0002, “1′b1” is entered for “DIR” and “DMA_MODE”, and the others are blank. No. For setting items 0003, “1′b0” is entered for “DMA_MODE”, “1′b1” is entered for “BURST_MODE”, and the others are blank.

図２７は第２実施例に係るシナリオチェッカの一例を示す図である。
上記のような設定制限リスト４１０を基に、シナリオチェッカ生成スクリプトを実行することで、Ｎｏ．０００１，０００２，０００３の各チェッカ２１３ｃ，２１３ｄ，２１３ｅを含むシナリオチェッカ２１３が生成される。各チェッカ２１３ｃ，２１３ｄ，２１３ｅは、第１実施例同様、“［ラベル名］：ａｓｓｅｒｔ（［エラー条件］）”というフォーマットに従って生成される。この第２実施例の場合、生成されるシナリオチェッカ２１３は、“ＤＭＡ．ｓｖｈ”というファイル名になる。 FIG. 27 is a diagram illustrating an example of a scenario checker according to the second embodiment.
By executing the scenario checker generation script based on the setting restriction list 410 as described above, No. A scenario checker 213 including checkers 213c, 213d, and 213e of 0001, 0002, and 0003 is generated. Each checker 213c, 213d, 213e is generated according to the format "[label name]: assert ([error condition])", as in the first embodiment. In the case of the second embodiment, the generated scenario checker 213 has a file name “DMA.svh”.

そして、上記第１実施例同様、シナリオチェッカ組み込みスクリプトを実行し、設定制限リスト４１０を基に、これらのチェッカ２１３ｃ，２１３ｄ，２１３ｅを含むシナリオチェッカ２１３をファイル２１１ｆｂの２０７行目に呼び出すインクルード文を挿入する。それにより、それにより、当該シナリオチェッカ２１３が、ファイル２１１ｆｂの２０７行目で呼び出されるように組み込まれたシナリオ２１１が得られるようになる。   Then, as in the first embodiment, a scenario checker embedded script is executed, and an include statement that calls the scenario checker 213 including these checkers 213c, 213d, and 213e on line 207 of the file 211fb is executed based on the setting restriction list 410. insert. Thereby, a scenario 211 in which the scenario checker 213 is incorporated so as to be called on the 207th line of the file 211fb can be obtained.

このようなシナリオ２１１が用いられてシナリオ開発やテストベンチ開発で行われるシミュレーションでは、エラー検出の際のログファイルに“ＤＭＡ＿０００１”、“ＤＭＡ＿０００２”、“ＤＭＡ＿０００３”の［ラベル名］が出力される。開発者は、シミュレーションの結果得られるログファイルを確認し、このようにチェッカ２１３ｃ，２１３ｄ，２１３ｅの［ラベル名］が出力されている場合は、シナリオ２１１にエラーがあるとみなし、シナリオ２１１を修正する工程へ進む。   In a simulation performed in scenario development or test bench development using such a scenario 211, [label names] of “DMA — 0001”, “DMA — 0002”, and “DMA — 0003” are output to the log file at the time of error detection. The developer checks the log file obtained as a result of the simulation, and if the [label name] of the checkers 213c, 213d, and 213e is output in this way, the scenario 211 is regarded as having an error, and the scenario 211 is corrected. Proceed to the process.

以上説明した手法によれば、シナリオ開発段階、テストベンチ開発段階で行われるシミュレーションにおいて、シナリオのエラーの有無及びエラーの内容を示す情報を、ログファイルの確認で行うことができる。そのため、シナリオのエラーが検出されたときに、敢えて波形データを取得することが不要になり、更に、取得した波形データを開発者が目視で確認し解析することによってそのエラー要因を特定するといった作業が不要になる。従って、シナリオ要因のエラーの解析時間を短縮することが可能になる。例えば、テストベンチ開発段階で、シナリオ要因のエラーとそれ以外のエラーがそれぞれ５割の割合で発生していた場合、全体としてのエラーの解析時間がおよそ２分の１になることになる。   According to the method described above, in the simulation performed in the scenario development stage and the test bench development stage, information indicating the presence / absence of a scenario error and the content of the error can be confirmed by checking the log file. Therefore, it is not necessary to dare to acquire waveform data when a scenario error is detected. Further, the developer can visually check and analyze the acquired waveform data to identify the cause of the error. Is no longer necessary. Therefore, it is possible to shorten the analysis time of the scenario factor error. For example, if a scenario factor error and other errors occur at a rate of 50% in the test bench development stage, the error analysis time as a whole is reduced to about one half.

更に、以上説明した手法では、シナリオ開発段階でのシナリオの動作確認（検証）をログファイルの確認で行うことができる。一方、シナリオの動作確認を波形データの目視確認によって行うと、時間がかかり、あまり多くの動作について確認が行えない場合があった。上記手法によれば、シナリオの動作確認をログファイルの確認で行え、波形データの目視確認を不要とすることができるため、動作確認に要する時間を短縮できる。その結果、より多くの動作について確認を行うことも可能になり、シナリオの動作確認を十分に行うことが可能になる。   Furthermore, with the method described above, scenario operation confirmation (verification) at the scenario development stage can be performed by confirming the log file. On the other hand, when confirming the operation of the scenario by visual confirmation of the waveform data, it takes time, and there are cases in which it is not possible to confirm a large number of operations. According to the above method, the operation of the scenario can be confirmed by confirming the log file, and the visual confirmation of the waveform data can be eliminated, so that the time required for the operation confirmation can be shortened. As a result, it is possible to confirm more operations, and it is possible to sufficiently confirm the operation of the scenario.

尚、以上の説明では、シナリオ（及びシナリオを組み込んだテストベンチ）の開発を例にしたが、論理回路を制御するファームウェアの開発においても、上記同様の手法を用いることができる。   In the above description, the scenario (and the test bench incorporating the scenario) is taken as an example. However, the same technique as described above can also be used in the development of firmware for controlling the logic circuit.

即ち、検証対象の仕様、ファームウェアの仕様等を基に、ファームウェアの制御動作を設定するうえでの設定制限事項を得る。その設定制限事項を基に、上記シナリオの例に従い、ファームウェアの所定記述部分の命令実行を制限する制限情報を含んだ設定制限リストを作成する。そして、作成した設定制限リストの内容を記述したファームウェアのチェッカを生成し、生成したチェッカを、ファームウェアに対し、その所定記述部分の命令実行時に呼び出せるように組み込む。このファームウェアを用いて論理回路を動作させ、所定記述部分でチェッカを呼び出し、その所定記述部分の命令にその実行を制限する制限情報が含まれるか否かを、呼び出したチェッカによってチェックする。ファームウェアの命令実行を制限する制限情報が含まれていればエラーとなる。エラーの有無及びエラーの内容を示す情報を、ログファイルとして出力する。   That is, setting restrictions for setting the firmware control operation are obtained based on the specification to be verified, the firmware specification, and the like. Based on the setting restriction item, a setting restriction list including restriction information for restricting instruction execution of a predetermined description part of the firmware is created according to the example of the scenario. Then, a firmware checker in which the contents of the created setting restriction list are described is generated, and the generated checker is incorporated into the firmware so that it can be called at the time of execution of the instruction of the predetermined description part. The logic circuit is operated using this firmware, the checker is called at the predetermined description part, and whether the restriction information for restricting the execution is included in the instruction of the predetermined description part is checked by the called checker. An error occurs if the restriction information that restricts the instruction execution of the firmware is included. Information indicating the presence / absence of an error and the content of the error is output as a log file.

このような手法によれば、検出されるエラーがファームウェアによるものであることをログファイルから判定でき、更に、ファームウェア要因のエラーについて、波形データの解析が不要になる。そのため、ファームウェア要因のエラーを波形データの目視確認で行う場合に比べ、エラーの解析時間を短縮することが可能になる。   According to such a method, it is possible to determine from the log file that the detected error is caused by firmware, and further, it is not necessary to analyze the waveform data for the error caused by the firmware. Therefore, the error analysis time can be shortened as compared with the case where the error caused by the firmware is performed by visual confirmation of the waveform data.

尚、上記のシナリオ、テストベンチ、及びファームウェア、並びにそれらを用いた対象回路の検証は、コンピュータを用いて実現することができ、その場合、コンピュータが実行する処理機能の内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。コンピュータで読み取り可能な記録媒体としては、磁気記憶装置、光ディスク、光磁気記録媒体、半導体メモリ等がある。磁気記憶装置には、ＨＤ、フレキシブルディスク（ＦＤ）、磁気テープ等がある。光ディスクには、ＤＶＤ、ＤＶＤ−ＲＡＭ、ＣＤ−ＲＯＭ／ＲＷ等がある。光磁気記録媒体には、ＭＯ（Magneto-Optical disk）等がある。   The scenario, test bench, firmware, and verification of the target circuit using them can be realized using a computer. In this case, a program describing the contents of processing functions executed by the computer is provided. Is done. By executing the program on a computer, the above processing functions are realized on the computer. The program describing the processing contents can be recorded on a computer-readable recording medium. Examples of the computer-readable recording medium include a magnetic storage device, an optical disk, a magneto-optical recording medium, and a semiconductor memory. Magnetic storage devices include HD, flexible disk (FD), magnetic tape, and the like. Optical discs include DVD, DVD-RAM, CD-ROM / RW, and the like. Magneto-optical recording media include MO (Magneto-Optical disk).

プログラムを流通させる場合には、例えば、そのプログラムが記録されたＤＶＤ、ＣＤ−ＲＯＭ等の可搬型記録媒体が販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。   When distributing the program, for example, a portable recording medium such as a DVD or a CD-ROM in which the program is recorded is sold. It is also possible to store the program in a storage device of a server computer and transfer the program from the server computer to another computer via a network.

プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラム若しくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。尚、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、ネットワークを介して接続されたサーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムに従った処理を実行することもできる。   The computer that executes the program stores, for example, the program recorded on the portable recording medium or the program transferred from the server computer in its own storage device. Then, the computer reads the program from its own storage device and executes processing according to the program. The computer can also read the program directly from the portable recording medium and execute processing according to the program. In addition, each time a program is transferred from a server computer connected via a network, the computer can sequentially execute processing according to the received program.

また、上記の処理機能の少なくとも一部を、ＤＳＰ（Digital Signal Processor）、ＡＳＩＣ（Application Specific Integrated Circuit）、ＰＬＤ（Programmable Logic Device）等の電子回路で実現することもできる。   Further, at least a part of the above processing functions can be realized by an electronic circuit such as a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), or a PLD (Programmable Logic Device).

１００ コンピュータ
１０１ ＣＰＵ
１０２ ＲＯＭ
１０３ ＲＡＭ
１０４ ＨＤＤ
１０４ａ ＨＤ
１０５ 通信インタフェース
１０６ キーボード
１０７ マウス
１０８ 周辺機器
１１０ バス
１２０ 設計データ
１３０ 論理シミュレータ
１４０，２００，２００Ａ テストベンチ
２１０，２１０ａ，２１０ｂ モデル
２１１，２１１ａ，２１１ｂ シナリオ
２１１ｃ インクルード文
２１１ｆａ，２１１ｆｂ ファイル
２１２，２１２ａ，２１２ｂ トランザクタ
２１３ シナリオチェッカ
２１３ａ，２１３ｂ，２１３ｃ，２１３ｄ，２１３ｅ チェッカ
２２０ プロトコルチェッカ
２２０ａ Ａプロトコルチェッカ
２２０ｂ Ｂプロトコルチェッカ
２３０ 期待値比較チェッカ
３００ 検証対象
３０１ レジスタ領域
４００，４１０ 設定制限リスト
４００ａ フォーマット
４０１ａ，４０２ａ，４０３ａ，４０４ａ，４０５ａ，４０６ａ，４０１，４０２，４０３，４０５，４０６，４１１，４１２，４１３，４１５，４１６ 欄
５００，５１０ 設定制限事項
６００ ログファイル
６０１ ラベル名 100 computer 101 CPU
102 ROM
103 RAM
104 HDD
104a HD
105 communication interface 106 keyboard 107 mouse 108 peripheral device 110 bus 120 design data 130 logic simulator 140, 200, 200A test bench 210, 210a, 210b model 211, 211a, 211b scenario 211c include statement 211fa, 211fb file 212, 212a, 212b transactor 213 Scenario checker 213a, 213b, 213c, 213d, 213e checker 220 protocol checker 220a A protocol checker 220b B protocol checker 230 expected value comparison checker 300 verification target 301 register area 400, 410 setting restriction list 400a format 401a, 402a, 403a, 404a , 405a, 406a, 401, 402, 403, 405, 406, 411, 412, 413, 415, 416 Column 500, 510 Setting restrictions 600 Log file 601 Label name

Claims (5)

コンピュータが、
検証対象に対する命令を記述したプログラムの所定記述部分の命令実行を制限する制限情報を含むリストを用い、前記リストの内容を示すチェッカを生成し、
前記プログラムを用いて前記検証対象を動作させ、前記所定記述部分の命令実行時に、前記チェッカを用いて前記所定記述部分の命令が前記制限情報を含むか否かのチェックを行い、
前記チェックの結果を示す結果情報を生成する、
ことを特徴とする検証方法。 Computer
Using a list including restriction information for restricting instruction execution of a predetermined description part of a program describing instructions for a verification target, generating a checker indicating the contents of the list,
The verification target is operated using the program, and at the time of executing the instruction of the predetermined description part, it is checked whether the instruction of the predetermined description part includes the restriction information using the checker,
Generating result information indicating the result of the check;
A verification method characterized by that. 前記コンピュータは、前記所定記述部分の命令実行時に前記チェッカを呼び出し、前記チェックを行うことを特徴とする請求項１に記載の検証方法。   The verification method according to claim 1, wherein the computer calls the checker at the time of executing an instruction of the predetermined description portion and performs the check. 前記リストは、当該リストから生成する前記チェッカを識別する識別情報、前記チェッカを呼び出す前記プログラム内の行番号、及び前記制限情報を含み、
前記コンピュータは、
前記リストから前記識別情報及び前記制限情報を含む前記チェッカを生成し、
前記チェッカの生成後、前記リストに基づいて、前記プログラムの前記行番号に、前記チェッカを呼び出すための前記識別情報を含む命令文を挿入し、
前記プログラムの前記行番号に、前記識別情報に基づいて前記チェッカを呼び出し、前記チェックを行う、
ことを特徴とする請求項２に記載の検証方法。 The list includes identification information for identifying the checker generated from the list, a line number in the program that calls the checker, and the restriction information.
The computer
Generating the checker including the identification information and the restriction information from the list;
After generating the checker, based on the list, insert a statement including the identification information for calling the checker into the line number of the program,
Calling the checker to the line number of the program based on the identification information and performing the check,
The verification method according to claim 2, wherein: 前記制限情報は、前記検証対象に対する命令の内容を決定する変数を含むことを特徴とする請求項１乃至３のいずれかに記載の検証方法。   The verification method according to claim 1, wherein the restriction information includes a variable that determines a content of an instruction for the verification target. コンピュータに、
検証対象に対する命令を記述したプログラムの所定記述部分の命令実行を制限する制限情報を含むリストを用い、前記リストの内容を示すチェッカを生成し、
前記プログラムを用いて前記検証対象を動作させ、前記所定記述部分の命令実行時に、前記チェッカを用いて前記所定記述部分の命令が前記制限情報を含むか否かのチェックを行い、
前記チェックの結果を示す結果情報を生成する、
処理を実行させることを特徴とする検証プログラム。 On the computer,
Using a list including restriction information for restricting instruction execution of a predetermined description part of a program describing instructions for a verification target, generating a checker indicating the contents of the list,
The verification target is operated using the program, and at the time of executing the instruction of the predetermined description part, it is checked whether the instruction of the predetermined description part includes the restriction information using the checker,
Generating result information indicating the result of the check;
A verification program characterized by causing processing to be executed.
JP2011123080A 2011-06-01 2011-06-01 Verification method and verification program Expired - Fee Related JP5799589B2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2011123080A JP5799589B2 (en) 2011-06-01 2011-06-01 Verification method and verification program

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2011123080A JP5799589B2 (en) 2011-06-01 2011-06-01 Verification method and verification program

Publications (2)

Publication Number Publication Date
JP2012252433A true JP2012252433A (en) 2012-12-20
JP5799589B2 JP5799589B2 (en) 2015-10-28

Family

ID=47525214

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2011123080A Expired - Fee Related JP5799589B2 (en) 2011-06-01 2011-06-01 Verification method and verification program

Country Status (1)

Country Link
JP (1) JP5799589B2 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114764641A (en) * 2022-04-29 2022-07-19 中国能源建设集团广东省电力设计研究院有限公司 Two-ticket management method, system, computer equipment and medium based on security verification

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH01243136A (en) * 1988-03-24 1989-09-27 Hitachi Ltd Logic simulation system
JPH07253909A (en) * 1994-03-16 1995-10-03 Hitachi Ltd Microprogram verifying method

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH01243136A (en) * 1988-03-24 1989-09-27 Hitachi Ltd Logic simulation system
JPH07253909A (en) * 1994-03-16 1995-10-03 Hitachi Ltd Microprogram verifying method

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114764641A (en) * 2022-04-29 2022-07-19 中国能源建设集团广东省电力设计研究院有限公司 Two-ticket management method, system, computer equipment and medium based on security verification
CN114764641B (en) * 2022-04-29 2023-11-14 中国能源建设集团广东省电力设计研究院有限公司 Two-ticket management method, system, computer equipment and medium based on security verification

Also Published As

Publication number Publication date
JP5799589B2 (en) 2015-10-28

Similar Documents

Publication Publication Date Title
JP4667386B2 (en) Business model diagram creation support program, business model diagram creation support method, and business model diagram creation support device
JP4255079B2 (en) Assertion generation system, circuit verification system, program, and assertion generation method
CN100442293C (en) Method for combination of original files of hardware design language and checking data files
US9990458B2 (en) Generic design rule checking (DRC) test case extraction
JP2006244073A (en) Semiconductor design device
US20140214396A1 (en) Specification properties creation for a visual model of a system
JP4850091B2 (en) Verification scenario generation apparatus, method, program, and verification apparatus
JP2006350420A (en) Device for testing rule file for layout verification and test method and test program
JP2007034833A (en) Function verification description generation device, function verification description generation method and function verification description generation program
US8739091B1 (en) Techniques for segmenting of hardware trace and verification of individual trace segments
JP5799589B2 (en) Verification method and verification program
JP5056625B2 (en) Circuit design apparatus and circuit design method
JP6318976B2 (en) DEBUG CIRCUIT, DEBUGGER DEVICE, SEMICONDUCTOR DEVICE, AND DEBUG METHOD
US7086017B1 (en) Method of post-implementation simulation of a HDL design
JPWO2006025412A1 (en) Logic verification method, logic module data, device data, and logic verification apparatus
JP2004326650A (en) Logic verification program and recording medium
JP2016126700A (en) Program verification device, program verification method, and program verification program
JP7351189B2 (en) Timing constraint extraction device, timing constraint extraction method, and timing constraint extraction program
JP2011145880A (en) Generation method for test task used in logic verification of semiconductor integrated circuit
JP5736588B2 (en) Source code conversion method and source code conversion program
JP4983642B2 (en) Design verification program, design verification method, and design verification apparatus
JP2004145670A (en) Method and device for generating test bench, and computer program
JP6724673B2 (en) Test support program, test support method, and test support device
JP2009110076A (en) Software verification support program, recording medium for recording its program, software verification support device, and software verification support method
JP5392862B2 (en) Software simulation apparatus and simulation method

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20140228

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20150219

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20150324

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20150519

A711 Notification of change in applicant

Free format text: JAPANESE INTERMEDIATE CODE: A712

Effective date: 20150611

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20150728

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20150810

R150 Certificate of patent or registration of utility model

Ref document number: 5799589

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees