JPH0749892A

JPH0749892A - 設計支援システム

Info

Publication number: JPH0749892A
Application number: JP5197357A
Authority: JP
Inventors: Kazunobu Morimoto; 和伸森本; Takashi Ishiyama; 俊石山; Osamu Tada; 修多田; Toshiyuki Fujiwara; 敏志藤原
Original assignee: Hitachi Computer Electronics Co Ltd; Hitachi Ltd
Current assignee: Hitachi Computer Electronics Co Ltd; Hitachi Ltd
Priority date: 1993-08-09
Filing date: 1993-08-09
Publication date: 1995-02-21
Anticipated expiration: 2015-09-04
Also published as: US5961557A; JP3083220B2

Abstract

(57)【要約】【目的】論理検証工程における作業管理、進捗状況管
理及び論理品質管理を効率よく行い、かつ、開発工数、
計算機資源のスループットを向上させる。【構成】検証管理テーブル９には、各検証項目の実施
順序、消化予定日、修正状況、確認状況等を登録してお
く。論理シミュレータ７によるシミュレーションによる
検証の実行時、検証管理部１０は、前記テーブル９の登
録情報を検索し、実施順序に沿わない項目、不良対策中
の項目の検証を実行させない。また、検証管理部１０
は、前記テーブルより各検証項目の消化予定と実績とを
集計し、図、表にして出力する。実装データ作成システ
ム８の実行時、検証管理部１０は、前記テーブル９の登
録情報を検索し、全ての検証項目の検証が済んでいる場
合にのみ、実装データ作成の処理を許可する。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、計算機システムの設計
支援システムに係り、特に、計算機システムの論理検
証、それに続く工程における作業管理のために使用して
好適な計算機システムの設計支援システムに関する。

【０００２】

【従来の技術】一般に、論理検証は、計算機システムの
開発における重要な工程の一つであり、実際に試作機を
作成する前に、充分な論理検証を行って論理品質を確保
しておくことにより、試作機上での検証を短期間で行う
ことができ、試作機の作り直し回数を低減して、開発期
間の短縮と開発コストを低減を図ることができる。この
論理検証を支援する手段の１つとして、論理シミュレー
ションが知られている。しかし、論理シミュレーション
だけで完全な論理検証を行うことは不可能なため、人手
による机上での検証も欠かせないものとなっている。

【０００３】前述の論理検証は、一般に、以下に説明す
るような方法で実施される。

【０００４】まず、検証の対象となる論理の設計仕様に
基づいて検証仕様を作成する。この検証仕様は、検証内
容と検証方法の概略とを規定するものである。次に、こ
れらの仕様に基づいて検証項目が作成される。この検証
項目の作成では、項目毎に、論理シミュレーション、机
上等の使用する検証手段が決定されると共に、検証項目
毎の消化予定日も決定される。通常、基本機能より検証
を始め、徐々に他の機能を検証していく。次に、検証仕
様に基づいて、論理シミュレーション環境を構築する。
その後、論理シミュレーション、机上で人手等により検
証項目を消化していく。

【０００５】検証のために論理シミュレーションを用い
る場合、各検証項目に従って、まず、テストデータとそ
の期待値とを作成する。そして、そのテストデータを用
いて論理シミュレーションを実行し、その結果と期待値
とを比較し成否を判定する。期待通りの結果が得られた
場合、当該検証項目を消化したものとし、そうでない場
合、論理を解析し対策を施した後、再度当該項目の検証
を実施する。

【０００６】前述した方法が、一般的な論理検証方法で
あるが、計算機システムの論理規模が増大するに従い、
論理検証の手段、精度に加え、工程の進捗と論理品質と
の管理が困難になるという問題点を生じる。

【０００７】すなわち、論理規模が大きくなると、検証
すべき項目の数も多くなり、多人数によるプロジェクト
を組み、多人数で論理検証が行われることになる。例え
ば、全担当者を検証担当と論理修正担当とに分け、検証
担当者をさらに机上担当、論理シミュレーション担当に
割り振る等により論理検証が行われるが、扱う論理規模
によっては、論理シミュレーション担当者だけで、数人
から数十人になることもある。

【０００８】このようなプロジェクトによる論理検証で
は、検証項目の消化状況管理、不良摘出及び対策状況の
管理が重要になってくる。これらの管理が充分になされ
ていないと、進捗状況が悪化し、不良の発生状況を的確
に把握することができなくなり、論理品質の早期確保が
困難になる恐れがある。また、発生している論理上の問
題点がプロジェクト全体に伝わらず、無駄な論理シミュ
レーションを実施してしまう等により手戻りが発生し、
計算機資源及び工数のスループットが悪化する恐れもあ
る。

【０００９】前述のような論理検証の管理を支援する従
来技術として、例えば、特開平４−１８８３３３号公報
等に記載された不良対策管理システムが知られている。

【００１０】この従来技術は、論理検証担当者が、論理
シミュレーション等を通じて論理不良を摘出する度に、
不良管理システム内のテーブルに不良情報を登録し、シ
ステムによって不良情報の集計と表示とを行い、これを
用いて検証工程管理者が論理品質と検証の進捗状況とを
管理するというものである。

【００１１】

【発明が解決しようとする課題】前述した従来技術は、
以下に説明するような問題点を有している。

【００１２】（１）通常、ある項目の検証中に不良が摘
出されると、その不良が摘出された検証項目は、その不
良に対する対策が完了するまで、論理シミュレーション
等の検証作業を中断しなければならなず、また、この項
目の確認後に実施が予定されている他の検証項目につい
ても、検証作業を中断する必要がある。

【００１３】前記従来技術は、このような管理を扱うこ
とができず、検証担当者が人手によりこのような管理を
行わなければならず、プロジェクトが大きくなってくる
と、扱う検証項目量が多くなり、このような管理を検証
担当者個人、一部の管理者に委ねることが不可能になる
という問題点を有している。

【００１４】（２）前記従来技術は、摘出した不良の状
況を人手で入力しなければならないため、論理シミュレ
ーションの実行と確認とに追われている論理検証担当者
が、不良管理のために前述の不良情報入力を行わなけれ
ばならず、そのための工数により大きな負担を負うこと
になるという問題点を有している。

【００１５】（３）通常、前述した論理検証の終了後、
次に、部品、論理ブロックを配置して配線を決定する実
装データ作成の工程に入る。しかし、論理検証が充分に
行われていない状況で、実装データ作成の工程に入って
しまうと、重大な不良の発生により手戻りが発生する可
能性が高い。

【００１６】前記従来技術は、このような管理を人手に
委ねていたため、論理検証が完全であることを確認する
ことが困難であるという問題点を有している。

【００１７】本発明の目的は、論理検証工程における作
業管理、進捗状況管理及び論理品質管理を効率よく行
い、かつ、開発工数、計算機資源のスループットを向上
させることのできる設計支援システムを提供することに
ある。

【００１８】また、本発明の目的は、（１）検証項目毎
の不良摘出、修正状況の管理とそれに伴う検証作業管理
を一貫して効率良く行うことができ、（２）検証工程の
進捗状況と論理品質状況の管理を、遅滞なくかつ検証担
当者の負担を最小限にして支援することができ、かつ、
（３）検証工程以降の工程に進む際の手戻りを低減する
ことができる設計支援システムを提供することにある。

【００１９】

【課題を解決するための手段】本発明によれば前記目的
は、ある検証項目を検証するために論理シミュレーショ
ンで用いるテストデータを指定する情報と、前記検証項
目の検証において発生した不良の有無、前記不良の修正
及び確認状況を示す情報と、前記検証項目を検証する前
提として確認が済んでいる必要のある他の検証項目を指
定する情報とを検証項目毎に記録する手段と、前記記録
手段に記録された情報から、論理シミュレータが実行し
ようとするテストデータに対応する検証項目と前記検証
項目の前提となる検証項目の確認状況を検索する手段と
を備え、実行しようとするテストデータについて、前記
記録情報より前提となる検証項目の確認状況を検索し、
前記前提となる検証項目が確認済みである場合にのみ、
論理シミュレーションの実行を可能とするようにするこ
とにより達成される。

【００２０】また、前記目的は、あるテストデータに対
する論理シミュレーション実行結果と期待値とを比較し
て検証の成否を判定する手段と、前記検証成否判定結果
に基づいて、発生した不良の有無及び確認状況を、前記
テストデータに対応する検証項目に対応付けて前記記録
手段に記録する手段を備え、検証結果を前記記録手段へ
登録するようにすることにより達成される。

【００２１】また、前記目的は、不良の発生により、論
理検証中の論理データを修正する際、前記不良を摘出し
た検証項目を入力し、前記記録手段上にその検証項目が
修正済みであることを記録する手段を備え、論理シミュ
レーションで実行しようとするテストデータに対応する
検証項目の確認状況を前記記録手段より検索し、前記検
証項目が未確認かつ未修正である場合、前記テストデー
タを用いた論理シミュレーションを実行しないようにす
ることにより達成される。

【００２２】また、前記目的は、机上チェック等の論理
シミュレーション以外の手段で検証した、ある検証項目
の確認結果を前記記録手段に記録する際、その検証項目
の前提となる項目が未確認であったり、既にその検証項
目で不良が発生しており、それに伴う修正が終了してい
場合、記録しようとしている確認結果を無効とすること
により達成される。

【００２３】さらに、前記目的は、検証進捗状況と論理
品質状況との管理を支援するために、各検証項目の消化
予定日と確認日とを前記記録手段に記録する手段と、前
記記録手段より、検証項目の消化予定と実績状況及び不
良摘出状況とを集計し、これらを出力する手段を備える
ことにより達成される。

【００２４】さらに、前記目的は、検証対象の論理デー
タを論理検証工程以降の工程で使用するときに、前記記
録手段により、検証項目が全て確認済であるか否かを検
索し、全て検証項目が確認済である場合にのみ、検証対
象の論理データの使用を許可するようにすることによ
り、あるいは、前記記録手段上の検証項目に、未確認の
まま論理検証以降の工程に進んで良いことを示す情報を
登録する手段を備え、前記情報が登録された検証項目以
外の検証項目が全て確認済である場合にのみ、論理検証
工程以降の工程でその論理データの使用を許可するよう
にすることにより達成される。

【００２５】

【作用】前記記録手段には、検証項目毎に、論理シミュ
レーションでこれを検証するために用いるテストデータ
が指定されている。そして、論理シミュレータにより、
あるテストデータによるシミュレーションを実行すると
き、前記記録手段より、そのテストデータに対応する検
証項目が検索される。前記記録手段には、この検証項目
を実行するための前提条件となる他の検証項目が指定さ
れているので、次に、この検証項目の確認状況が検索さ
れる。

【００２６】論理シミュレータは、前提条件となる項目
が確認済であれば、その検証項目の検証に進んでよいと
判断し、論理シミュレーションを実行し、前提条件とな
る項目が、不良発生等によりまだ確認されていない場
合、その検証項目の検証に進むのは尚早と判断し、その
テストデータのシミュレーションを中止する。

【００２７】本発明は、実行された論理シミュレーショ
ン結果を、その期待値と比較して成否を判定し、その判
定結果を前記記録手段に記録しているので、検証項目の
確認状況を常に最新状態にしておくことができる。ま
た、本発明は、論理修正時に、どの検証項目の結果に対
する修正かを入力し、前記記録手段にその検証項目が修
正済であることを記録し、修正済みでない、すなわち、
修正中である項目の論理シミュレーションを実施しない
ようにしているので、不良対策の終了していない項目の
検証を誤って行う等の無駄を防止することができる。

【００２８】また、本発明は、前記記録手段に記録され
た検証状況に基づいて、全検証項目、あるいは、特定の
検証項目が未消化の場合、実装データ作成システム等に
おける処理を実行させないようにすることができ、これ
により、作業の手戻りを防止することができる。

【００２９】前述したように、本発明は、検証項目毎
に、不良発生状況、確認状況の情報等の検証工程の最新
実績が、前記記録手段に登録されて、管理しているの
で、これらの情報をもとに、作業管理、進捗状況管理、
論理品質管理等を支援することができる。また、本発明
は、前記記録手段に、検証項目の消化予定を事前に記録
しておくことができるので、予定と最新実績を集計、編
集して出力することにより、進捗状況と論理品質の管理
情報とを得ることができる。

【００３０】

【実施例】以下、本発明による設計支援システムの一実
施例を図面により詳細に説明する。ここで説明する本発
明の一実施例は、論理シミュレーションを中心とした論
理検証に本発明を適用した例である。

【００３１】図１は本発明の一実施例の構成を示すブロ
ック図、図２は検証管理テーブルの構成の一例を示す
図、図３は論理検証処理の一例を説明するフローチャー
ト、図４は論理シミュレーション実施可否判定の処理を
説明するフローチャート、図５は検証項目の消化状況と
不良の摘出状況とを集計した検証管理資料の出力例を説
明する図、図６は検証管理情報を集計する処理を説明す
る示すフローチャート、図７は実装データ作成システム
の実行可否判定の処理を説明するフローチャートであ
る。図１において、１は端末、２はテストデータ入力
部、３はテストデータファイル、４はテストデータ、５
は設計データ入力部、６は設計データファイル、７は論
理シミュレータ、８は実装データ作成システム、９は検
証管理テーブル、１０は検証管理部、１１は検証管理テ
ーブル入力部、１２は管理情報集計部である。

【００３２】図１に示す本発明の一実施例において、テ
ストデータ入力部２は、端末１より入力された検証担当
者が作成したテストデータ４を、テストデータファイル
３に登録する。入力された各テストデータ４には、固有
の番号が与えられてテストデータファイル３に格納され
る。

【００３３】設計データ入力部５は、端末１より入力さ
れた論理設計者が作成した論理データを、設計データフ
ァイル６に登録する。論理シミュレータ７は、検証対象
となる設計データと検証に用いるテストデータとが指定
されることにより、テストデータ４をテストデータファ
イル３から読み出して、設計データファイル６上の設計
データに対し論理シミュレーションを実行する。

【００３４】実装データ作成システム８は、設計データ
ファイル６内の論理データを使用して、部品、論理ブロ
ック等を配置して配線を決定する等により実装情報を作
成する。検証管理テーブル９には、検証項目毎に、それ
らの検証項目を検証するために論理シミュレーションで
使用するテストデータの番号、不良の発生状況、修正状
況、確認状況、各項目を検証する前提として確認済みで
なければならない検証項目（以下、前提条件検証項目と
呼ぶ）の番号が登録される。

【００３５】検証管理部１０は、論理シミュレータ７等
の問い合わせに対し、検証管理テーブル９より必要な情
報を検索し、実行許可を与え、あるいは、管理情報集計
部１２に集計に必要な情報を提供する。検証管理テーブ
ル入力部１１は、端末１を通じて入力された検証管理テ
ーブル９に登録すべき情報を、検証管理テーブル９に登
録する。管理情報集計部１２は、検証項目消化状況、不
良摘出状況等を集計して、それらをグラフ等の見やすい
形状に編集して出力する。

【００３６】次に、図２を参照して検証管理テーブル９
の詳細を説明する。このテーブルは、設計データ対応に
設けられるものであり、このテーブルには、以下に説明
する情報が検証項目毎に登録されている。

【００３７】テーブル中の検証項目番号２１は、各検証
項目に付与された検証項目固有の番号である。

【００３８】前提条件検証項目番号２２は、各項目の前
提条件検証項目の番号である。該当する項目がない場
合、空白とされる。また、複数の番号が登録されてもよ
い。

【００３９】テストデータ番号２３は、各検証項目を論
理シミュレーションによって検証するために用いるテス
トデータの番号である。ここに登録されたテストデータ
は、テストデータファイル３上に登録されているものと
する。

【００４０】消化予定日２４は、各検証項目を消化する
予定の日付である。

【００４１】不良発生状況２５は、各項目の検証で摘出
した現時点での不良発生状況である。図示例では、検証
未実施の場合空白が、検証実施中あるいは実施済みの場
合、１回のシミュレーションで摘出された不良数が登録
される。不良数の他に、設計データ変更管理番号を登録
してもよい。

【００４２】設計データ来歴２６は、その項目の検証を
最後に実施した時点での設計データの来歴である。検証
未実施の項目には空白データを登録する。この来歴は、
設計データ更新の都度、設計データ入力部５によって更
新され、設計データファイル６上にも記録されている。

【００４３】確認日２７は、期待通り論理が動作するこ
とを確認した日付である。未確認の項目は、空白データ
とされており、日付が入っている項目は確認済みである
とみなされる。

【００４４】図２に示す例では、各検証項目に次のよう
な情報が登録されている。すなわち、検証項目“ＴＥＳ
Ｔ００１”は、テストデータ“ＤＡＴＡ００”によって
検証される。この項目に対する前提条件検証項目はな
く、消化予定日は４月１５日である。この項目の検証に
伴い不良が１件摘出されたが、来歴“０１０”の設計デ
ータにおいて４月１５日に確認が済んでいる。検証項目
“ＴＥＳＴ００３”は、前提条件検証項目が“ＴＥＳＴ
００１”であり、用いるテストデータが“ＤＡＴＡ０
１”である。不良が１件摘出され、来歴“０１２”で検
証が実施されたが、論理が正常に動作することはまだ確
認されていない。検証項目“ＴＥＳＴ００４”は、消化
予定日が４月２０日であるが、まだ検証が実施されてい
ない。

【００４５】前述において、検証項目番号２１、前提条
件検証項目番号２２、テストデータ番号２３、消化予定
日２４の登録情報は、検証担当者が検証開始前に入力す
ることにより登録される。また、不良発生状況２５、及
び修正状況２６、確認日２７は、検証実施の都度、検証
担当者により登録され、あるいは、論理シミュレータ
７、または、設計データ入力部５から登録される。

【００４６】次に、図３に示すフローを参照して、本発
明の一実施例による論理検証の処理と各部の動作とを説
明する。

【００４７】（１）最初に、検証担当者は、端末１より
検証管理テーブル入力部１１を通して、検証管理テーブ
ル９に必要な検証項目情報を登録する（ステップ３０
１）。

【００４８】（２）その後、論理検証が開始される。ま
ず、検証項目に応じたテストデータ４が作成される（ス
テップ３０２）。

【００４９】（３）作成したテストデータ４は、端末
１、テストデータ入力部２を通して、テストデータファ
イル３に登録される。テストデータ作成後、テストデー
タ４と設計データファイル６とを指定して論理シミュレ
ータ７に論理シミュレーションの実行を依頼する（ステ
ップ３０３）。

【００５０】（４）検証管理部１０は、このとき、検証
管理テーブル９の登録情報に基づいて、後述する判定方
法に従って、実際に論理シミュレーションを実施するか
否かを判定する（ステップ３０４）。

【００５１】（５）ステップ３０４の判定の結果、論理
シミュレーションの実施が可能な場合、論理シミュレー
タ７は、実際に論理シミュレーションを実施する（ステ
ップ３０５）。

【００５２】（６）その後、論理シミュレーション結果
を判定し、検証管理テーブル９に結果を登録する。例え
ば、検証対象論理の動作が正常であると確認された場
合、用いた設計データの来歴２６と確認日２７とを、検
証管理テーブル９上の用いたテストデータ番号２３を有
する欄に登録する。逆に、検証対象論理が正常に動作し
なかった場合、この検証項目の不良発生状況２５をカウ
ントアップし、用いた設計データの来歴２６を登録す
る。このとき、確認日２７は登録しない。

【００５３】このステップを検証担当者が人手で実施す
る場合、論理シミュレーション結果判定は、論理シミュ
レーション結果リストに基づいて行われ、検証管理テー
ブル９への結果登録は、端末１より検証管理テーブル入
力部１１を通じて行われる。このステップを論理シミュ
レータ７で行うことも可能である。この場合、シミュレ
ーション実施時にテストデータと共に期待値を入力す
る。論理シミュレータ７は、論理シミュレーション結果
と前記期待値とを比較し、両者が一致した場合正常、不
一致の場合正常でないと判断し、その結果に従って検証
管理テーブル９に前述のように必要なデータを登録する
（ステップ３０６）。

【００５４】（７）論理シミュレーションの結果、不良
が摘出されたか否かを判定し、不良が摘出されていれ
ば、検証担当者は、不良を解析して論理を修正し、その
後、ステップ３０３に処理を戻して再度論理シミュレー
ションを依頼する（ステップ３０７〜３０９）。

【００５５】（８）ステップ３０７の判定で、不良が摘
出されなかった場合、全検証が終了しているか否かを判
定し、終了していなければステップ３０２に戻り、次の
テストデータの処理を実行し、全検証が終了していれ
ば、図３の処理を終了する（ステップ３１０）。

【００５６】（９）ステップ３０４の判定で、論理シミ
ュレーションの実施が不可能と判定された場合、後述す
るようにこの検証項目２１の前提条件検証項目２２が未
確認であるか、この検証項目で以前に摘出された不良が
未修正であるためであるので、それらの検証項目に対す
る不良解析、論理修正等の対策を行い、その検証項目に
対する論理シミュレーションを依頼する（ステップ３０
８、３０９）。

【００５７】この場合、ステップ３０２で作成されたテ
ストデータを用いて検証を行おうとした検証項目に対す
る処理は、ステップ３０４でシミュレーション実施不可
能の原因となった検証対象の確認が済んでから実施され
る。

【００５８】次に、図４に示すフローを参照して、前述
したステップ３０４における論理シミュレーション実施
の可否判定の処理について説明する。

【００５９】（１）まず、論理シミュレータ７は、シミ
ュレーションを行おうとしているテストデータ番号を検
証管理部１０に伝える（ステップ４０１）。

【００６０】（２）検証管理部１０は、検証管理テーブ
ル９より、当該テストデータ番号に対応する検証項目２
１を検索する（ステップ４０２）。

【００６１】（３）次に、検証管理部１０は、当該検証
項目２１の前提条件検証項目２２の確認状況を、同じく
検証管理テーブル９上より検索する（ステップ４０
３）。

【００６２】（４）この前提条件検証項目が既に確認済
み、すなわち、確認日２７が登録済みであるか否かを判
定する（ステップ４０４）。

【００６３】（５）検証管理部１０は、ステップ４０４
の判定で、前提条件検証項目が既に確認済みの場合、論
理シミュレータ７にシミュレーションの実行許可を与
え、確認済みでない場合、論理シミュレータ７にシミュ
レーションの実施不可を伝える。論理シミュレータ７
は、この検証管理部１０の指示に従う（ステップ４０
５、４０６）。

【００６４】前述したような方法を用いることにより、
ある項目に関する論理検証において、その前提として消
化済みであるべき項目が未消化である場合に、当該項目
の検証を回避することができるので、検証のやりなおし
等による無駄な工数、計算機資源の浪費を回避すること
ができる。

【００６５】なお、前述した判定方法は、その検証項目
の前提条件のみを考慮してシミュレーション実施の可否
を判定するとしたが、本発明は、次に説明するような方
法を用いることにより、論理不良が修正済みであるか否
かを考慮するようにすることも可能である。

【００６６】図３のステップ３０９の論理修正時、設計
データと共に、修正の契機となった検証項目の番号を設
計データ入力部５に入力し、設計データファイル６に記
録しておく。その検証項目に関し、論理シミュレーショ
ンが再度依頼されたとき、論理シミュレータ７は、用い
るテストデータだけでなく、前述の検証項目番号と設計
データの来歴とを検証管理部１０に伝える。検証管理部
１０は、伝えれらた来歴が検証管理テーブル９に登録さ
れているその検証項目の設計データ来歴２６より新しい
ことを確認し、新しい場合、論理が修正されたと判定
し、そうでない場合、論理が未修正のままであると判定
する。検証管理部１０は、前提条件検証項目が確認済
み、かつ、以前よりも設計データ来歴が新しい場合にの
み、論理シミュレーションの実施を許可する。

【００６７】前述したような手順による方法を用いるこ
とにより、検証項目の不良を未修正のまま同じ検証を実
施してしまうというような無駄をなくすことができる。

【００６８】次に、検証管理資料の出力例を示す図５及
びその処理フローを示す図６を参照して、管理情報集計
部１２の処理動作を説明する。ここでの例は、１週間単
位に検証項目の消化件数と不良発生件数とを集計すると
して説明するが、集計単位は、１週間単位に限られず、
１日単位等であってもよい。

【００６９】図５に示す管理情報集計部１２の出力例
は、検証項目消化状況と不良摘出状況とを集計してグラ
フにより示したもので、検証項目消化予定残件数５１、
検証項目消化実績残件数５２、不良発生件数５３が、検
証期間中に変化する様子が一目で判るように出力されて
いる。出力方法は、図５に示すようなグラフではなく、
表等であってもよい。

【００７０】以下、図６のフローを参照して動作の流れ
を説明する。

【００７１】（１）端末１より管理情報集計部１２に集
計の開始が指示されると、管理情報集計部１２は、前回
の集計から１週間が経過しているか否かを判定し、１週
間が経過していることを確認して集計の実施を開始する
（ステップ６０１、６０２）。

【００７２】（２）まず、検証管理テーブル９上の消化
予定日２４を検索し、検証開始時点から終了予定時点ま
で一週間単位に消化予定項目数を集計し、全体の項目数
から検証項目消化予定残件数５１を求める（ステップ６
０３）。

【００７３】（３）次に、検証管理テーブル９上の確認
日２７を検索し、検証開始時点から現時点まで一週間単
位に確認済み項目数を集計し、全体の項目数から検証項
目消化実績残件数５２を求める（ステップ６０４）。

【００７４】（４）その後、検証管理テーブル９上の不
良発生状況２５を検索し、検証開始時点から現時点まで
一週間単位に不良発生件数５３を集計する（ステップ６
０５）。

【００７５】（５）最後に、以上の集計データを図５に
示すような図にして出力する（ステップ６０６）。

【００７６】（６）全ての集計が終了しているか否か判
定し、集計が終了するまで、あるいは、集計の終了が指
示されるまで、ステップ６０２以降の処理を繰り返し実
行する（ステップ６０７）。

【００７７】前述した例では、毎回予定件数等を集計し
直しているが、管理情報集計部１２に前回までの集計結
果を記録しておくようにすれば、前回の集計以降に消化
した項目数と摘出した不良数とを集計するだけで、全デ
ータを得ることができる。

【００７８】また、出力として、検証項目の消化予定残
件数、消化実績残件数をグラフにより出力するとした
が、出力は、検証項目の消化予定件数、消化実績件数の
累積等であってもよい。

【００７９】前述した方法を用いることにより、論理検
証工程管理上必要なデータを自動的に得ることができ、
管理者を初めとするプロジェクト員は、このデータを利
用して、検証の進捗状況、論理品質等を常に的確に把握
することができる。

【００８０】次に、図７に示すフローを参照して、実装
データ作成システム８の処理動作について説明する。

【００８１】（１）実装データ作成システム８にの実行
が依頼されると、実装データ作成システム８は、検証管
理部１０に実行の可否を問い合わせる（ステップ７０
１、７０２）。

【００８２】（２）検証管理部１０は、検証管理テーブ
ル９を検索し、テーブル９上の全検証項目に確認日が登
録されているか否か、すなわち、全検証項目が確認済か
否かをを判定する（ステップ７０３、７０４）。

【００８３】（４）ステップ７０４の判定で、全検証項
目が確認済みの場合、検証工程は終了しているとみなせ
るので、検証管理部１０は、実装データ作成システム８
に対してその実行を許可する。実装データ作成システム
８は、これにより、部品、論理ブロックの配置を決定
し、配線を決定する実装データの作成処理を実行する
（ステップ７０５、７０６）。

【００８４】（５）ステップ７０４の判定で、検証項目
に未確認の項目がある場合、検証管理部１０は、検証工
程が終了しておらず、実装データを作成するには尚早で
あると判断し、実装データ作成システム８に対して、実
行不可を通知する。この場合、実装データ作成システム
８は、なにも行わずに処理を終了する（ステップ７０
７）。

【００８５】実装データ作成システム８に実行を開始さ
せる前に、前述したような処理を行わせることにより、
本発明の一実施例は、検証工程の完全な終了以前に実装
データの作成を行ってしまい、後から不良が発見され再
度実装データの作成を実施するというような事態を避け
ることができる。

【００８６】前述で説明した例は、実装データ作成開始
までに、全ての検証項目の確認が必要であるとしている
が、実装データ作成の開始までに必ずしも全検証項目が
消化されていなくてもよい場合がある。この場合、検証
管理テーブル９の各検証項目に、実装データの作成開始
時点で消化済みであるべきか否かを登録し、実装データ
作成システム８への実行依頼時、検証管理部１０が、消
化済みであるべき検証項目が全て消化されている場合の
み、実装データ作成システム８に実行を許可するように
すればよい。このようにすることにより、特定の検証項
目が未消化な場合にも、実装データの作成を行うことが
できる。

【００８７】前述した本発明の一実施例によれば、論理
シミュレーションを中心とした論理検証において、誤っ
た項目の検証を回避することができ、検証工程の進捗管
理、論理品質状況の管理を容易に行うことができる。

【００８８】なお、前述した本発明の実施例は、論理検
証の進め方によって、下記のように変形して用いること
ができる。

【００８９】一般に、実際の論理検証では、一旦検証確
認済みとなった項目を、論理変更の発生、論理シミュレ
ーション結果確認時の不良見逃し等によって、再度検証
する必要が生じることがある。このような場合には、検
証管理テーブル９上の該当する検証項目の確認日をクリ
アする必要がある。なぜなら、確認日が登録されている
限り、検証管理部１０は、その項目の検証の実施を認め
ないからである。また、確認日がクリアされた検証項目
を前提条件検証項目としている検証項目も、同様に確認
日をクリアする必要がある。なぜなら、これらの項目も
再度検証する必要があるからである。

【００９０】このクリアは、検証担当者が、端末１より
検証管理テーブル入力部１１を介して行うことができ
る。この場合、確認日がクリアされた検証項目を前提条
件検証項目としている検証項目を、検証管理部１０によ
って検証管理テーブル９より検索させ、それらの確認日
をクリアさせるようにすることができる。これにより、
登録情報修正に伴う作業工数を低減でき、修正もれの防
止、再確認すべき項目の明確化を行うことができる。

【００９１】また、論理検証では、論理シミュレーショ
ンだけでなく、人手による机上での検証も行われる。こ
の場合、この机上検証分も検証管理テーブル９に登録し
て管理する必要がある。このとき、検証管理テーブル９
に登録するデータは、机上分も論理シミュレーション分
と同一でよく、その初期登録と更新とは、端末１より検
証管理テーブル入力部１１を通じて行えばよい。

【００９２】但し、人手により検証を実施するため、前
提条件検証項目が未消化であるにもかかわらず検証が実
施されてしまうこともある。そこで、検証管理テーブル
入力部１１による確認状況の登録時、前提条件検証項目
の確認状況を検証管理テーブル９より検索し、それらが
確認済みの場合のみ確認状況データを受け付けるように
する。これにより、誤った確認状況の登録を防止するこ
とができる。

【００９３】また、不良が発生した項目に対しても、検
証管理テーブル９を利用して、修正の入った場合にのみ
確認状況データを受け付けるようにする。この結果、検
証担当者が扱う検証項目を誤った場合にも、検証担当者
に警告等を発することが可能となる。

【００９４】

【発明の効果】以上説明したように本発明によれば、
（１）各検証項目について、確認が済んでいる必要のあ
る項目が未確認であったり、摘出された不良が未対策で
ある場合に、論理シミュレーションの実行を回避するこ
とができ、（２）検証項目の消化予定と実績、摘出不良
実績を自動的に図表等により出力することができ、
（３）検証工程以降の工程で、必要な検証項目が未消化
のままの対象設計データの使用を防止することができ
る。本発明は、これにより、大規模な論理検証プロジェ
クトにおける、作業工数と計算機資源のスループット向
上と、作業管理、進捗管理、論理品質管理の効率化とを
図ることができる。

【図面の簡単な説明】

【図１】本発明の一実施例の構成を示すブロック図であ
る。

【図２】検証管理テーブルの構成の一例を示す図であ
る。

【図３】論理検証処理の一例を説明するフローチャート
である。

【図４】論理シミュレーション実施可否判定の処理を説
明するフローチャートである。

【図５】検証項目消化状況と不良摘出状況とを集計した
検証管理資料の出力例を説明する図である。

【図６】検証管理情報を集計する処理を説明する示すフ
ローチャートである。

【図７】実装データ作成システムの実行可否判定の処理
を説明するフローチャートである。

【符号の説明】

１端末２テストデータ入力部３テストデータファイル４テストデータ５設計データ入力部６設計データファイル７論理シミュレータ８実装システム９検証管理テーブル１０検証管理部１１検証管理テーブル入力部１２管理情報集計部

───────────────────────────────────────────────────── フロントページの続き (72)発明者石山俊神奈川県海老名市下今泉810番地株式会社日立製作所オフィスシステム事業部内 (72)発明者多田修神奈川県海老名市下今泉810番地株式会社日立製作所オフィスシステム事業部内 (72)発明者藤原敏志神奈川県秦野市堀山下１番地株式会社日立コンピュータエレクトロニクス内

Claims

【特許請求の範囲】

【請求項１】計算機システムの論理検証、それに続く
工程の作業管理のための設計支援システムにおいて、あ
る項目を検証するために論理シミュレーションで実行す
るテストデータを指定する情報、前記検証項目の検証に
おいて発生した不良の有無を表す情報、前記不良の修正
及び確認状況を表す情報、前記検証項目を検証する前提
として確認が済んでいる必要のある他の検証項目を指定
する情報を、検証項目毎に記録する手段と、前記記録手
段より、論理シミュレータが実行しようとするテストデ
ータに対応する検証項目及び前記検証項目の前提となる
検証項目の確認状況を検索する手段とを備え、実行しよ
うとするテストデータについて、前記記録手段より前提
となる検証項目の確認状況を検索し、前記前提となる検
証項目が確認済みである場合にのみ、論理シミュレーシ
ョンの実行を可能とすることを特徴とする設計支援シス
テム。
【請求項２】あるテストデータに対する論理シミュレ
ーションの実行結果と期待値とを比較して検証の成否を
判定する手段と、該手段による検証の成否判定結果に基
づいて、発生した不良の有無及び確認状況を、前記テス
トデータに対応する検証項目に対応付けて前記記録手段
に記録する手段とをさらに備えることを特徴とする請求
項１記載の設計支援システム。
【請求項３】不良の発生により論理検証中の論理デー
タを修正する際、前記不良を摘出した検証項目を入力
し、前記検証項目に対応付けて前記記録手段上に修正状
況を記録する手段を備え、論理シミュレーションで実行
しようとするテストデータに対応する検証項目の確認状
況を前記記録手段より検索し、前記検証項目が未確認か
つ未修正である場合、前記テストデータを用いた論理シ
ミュレーションを実行しないことを特徴とする請求項１
または２記載の設計支援システム。
【請求項４】前記記録手段に検証項目の確認状況を記
録する際、その検証項目の前提となる検証項目の確認状
況を検索し、前記前提となる確認項目が未確認である場
合、その検証項目に記録しようとする確認状況を無効と
することを特徴とする請求項１、２または３記載の設計
支援システム。
【請求項５】前記記録手段に検証項目の確認状況を記
録する際、その検証項目の不良発生状況と修正状況とを
検索し、その検証項目で不良が発生しかつ未修正である
場合、その検証項目に記録しようとする確認状況を無効
とすることを特徴とする請求項１ないし４のうち１記載
の設計支援システム。
【請求項６】前記記録手段上に、一旦確認済みと記録
された検証項目に関連する不良が発生したとき、その検
証項目を前提となる検証項目としている検証項目の確認
状況を前記記録手段より検索し、前記確認状況が確認済
みである場合、前記確認状況を未確認として前記記録手
段に記録しなおすことを特徴とする請求項１ないし５の
うち１記載の設計支援システム。
【請求項７】各検証項目の消化予定日と確認日とを、
前記記録手段に記録する手段と、前記記録手段より、検
証項目の消化予定と実績状況及び不良摘出状況とを集計
して出力する手段とを備えたことを特徴とする請求項１
ないし６のうち１記載の設計支援システム。
【請求項８】検証対象の論理データを論理検証工程以
降の工程で使用するとき、前記記録手段より、検証項目
が全て確認済であるか否かを検索し、全て確認済である
場合にのみ、前記論理データの使用を許可することを特
徴とする請求項１ないし７のうち１記載の設計支援シス
テム。
【請求項９】前記記録手段上の検証項目に、未確認の
まま論理検証以降の工程に進んでよいことを示す情報を
登録する手段を備え、前記情報が登録された検証項目以
外の検証項目が全て確認済である場合にのみ、論理検証
工程以降の工程で前記論理データの使用を許可すること
を特徴とする請求項８記載の設計支援システム。