設計・検証のワンポイント

第11回「誤ってラッチを生成する記述」(201303)

組み合わせ回路を記述したつもりが、シミュレーションでラッチ動作になってしまったり、論理合成でラッチが生成されてしまうなんてことがあります。今回は誤ってラッチを生成しないための組み合わせ回路記述の注意点について触れてみます。


"第11回「誤ってラッチを生成する記述」(201303)"の詳細»

第10回「固定小数点の演算」(201302)

HDLによる回路設計を行う場合、取り扱う数値は整数であることが多いかと思います。
しかしデジタルフィルタやモータ制御などの回路設計では小数を取り扱うことも少なくはありません。今回は小数を含めた固定小数点の演算について触れてみたいと思います。


"第10回「固定小数点の演算」(201302)"の詳細»

第9回「DFT」(201301)

LSIは機能の設計と検証を終えただけでは出荷することはできません。製造したLSIの品質を保証するための出荷テストを行なう必要があります。
LSIの出荷テストは、 回路機能の確認を行なう機能テストとは異なりLSI内部に物理的な故障があるかどうかをテストします。
尚、FPGAはメーカーから出荷される際にこの出荷テストが行なわれるので必要とはなりません。
出荷テストは、テスト回路の作成とテストパターンの作成が必要になります。これらを効率よく作成する技術をDFT(Design For testability、テスト容易化設計)と呼んでいます。


"第9回「DFT」(201301)"の詳細»

第8回「タイミング解析」(201212)

HDLを使用して回路を設計するようになってから久しいですが、「タイミング解析」なる用語もHDLの利用とともに設計者に一般的になってきました。
タイミング解析を簡単に言うと、「設計者の要求したクロック周波数で、その回路が正しく動作するかを確認すること」になります。回路素子には固有の遅延があるため、要求クロックが高かったり回路規模が大きかったりすると、回路の一部が動かない可能性があるのです。
そこでタイミング解析を行い、正しく動くことを確認します。この作業を怠れば、出来上がった回路(チップ)は動かない、と考えてもあながち間違いではありません。


"第8回「タイミング解析」(201212)"の詳細»

第7回「実機におけるデバッグ手法」(201211)

RTL設計・検証がひと段落つくと次に待ち構えているのが実機検証です。RTLで十分シミュレーションをしているから実機ではスムースに動くはず!っと思っていても、いざ実機検証を始めるといろいろなトラブルが発生するものです。同じ検証でもRTLと実機では環境、デバッグ方法、考え方などが少々異なります。今回は実機におけるデバッグ手法と題して、FPGAを使った実機検証について触れてみます。

"第7回「実機におけるデバッグ手法」(201211)"の詳細»

第6回「レーシングによるトラブル」(201210)

シミュレーション結果の波形をみると想定していたタイミングより1サイクル前で動作している。 記述をいくら見直してみても、1サイクル前にずれるような記述はないのだが・・・。 このような状況においては、レーシング(競合)問題が発生しています。


"第6回「レーシングによるトラブル」(201210)"の詳細»

第5回「検証項目の作成方法」(201209)

検証項目の作成は、検証環境の構築や実行時間の検討を行うためにも事前に作成したいものです。 効率よく項目を抽出するには、「機能のリストアップ」、「入出力/レジスタのリストアップ」、「動作フローのリストアップ」を行い、これらの組合せを考える必要があります。


"第5回「検証項目の作成方法」(201209)"の詳細»

第4回「システムシミュレーション環境の活用例(ソフトウェアの早期開発)」(201208)

★システムシミュレーションとは

ここではプロセッサやRAMだけでなくネットワークコントローラやI/Oなども含めて1つの製品を丸ごと模擬し、SWを実行できる環境をシステムシミュレーション環境と定義します。 OSS(Open Source Software)のQEMUのようにC言語ですべてを実装する方法や、SystemC+各種商用EDAツールを使う方法もあります。 HDLによるRTLシミュレーションも不可能ではありませんが、速度の観点からFPGAやエミュレータを活用しないと現実的ではありません。 本稿ではC/C++/SystemCによるシステムシミュレーションを主に扱います。


"第4回「システムシミュレーション環境の活用例(ソフトウェアの早期開発)」(201208)"の詳細»

第3回「アサーション」(201207)

近年のLSI/FPGAは製造技術の進歩により大規模化、多機能化が急速に進んでいます。
これに伴い回路を検証するポイントが増加する傾向ですが、検証ポイントが増えても開発工数は増えることはなく、激しい競争により開発期間は短くなっているのが現状です。
この限られた期間内に回路品質を向上させるために、沢山の検証ポイントを効率良くかつ精度良く行うことが非常に重要な課題になっています。
最近では制約付きランダムテスト、カバレッジ、アサーション検証といった検証手法が採用されており、今回は『アサーション検証』について説明したいと思います。

"第3回「アサーション」(201207)"の詳細»

第2回「可読性の高い記述」(201206)

回路設計はHDLによる設計が一般的であることから、もはや一種のプログラミングと言っても良いのかもしれません。そこで重視したいのが「ソースコードの質」です。
質の高いコードはバグがない(少ない)だけではなく、メンテナンスや機能拡張が容易であったり、検証しやすいなど多くのメリットをもたらします。
如何に質の高いソースコードを記述するか?
皆さんも色々な工夫をなされているかと思いますが、今回は「可読性」の観点でソースコードの質の向上を考えてみたいと思います。

基本的に(?)他人が書いたソースコードは読みにくく、理解しにくいものです。同じ言語であっても、ちょっとした個人の癖(記述スタイル)などにより第三者が読みにくいと感じてしまうことはよくあることです。最悪なのは「以前自分自身で書いたソースコードが解読できない」というような状況です。製品開発ではあってはならないことなのですが、意外に経験したことのある方も多いのでは?

可読性とは「読みやすさ」や「理解しやすさ」の指標ですが、この可読性は「検証のし易さ」や「メンテナンスのし易さ」に大きく影響します。デバッグ時の作業を考えてみて下さい。波形出力などを基に不具合箇所のソースコードを1行ずつ追いかけることがありますが、そこで「読みにくい」ソースコードだと余計に時間がかかってしまいます。特に検証や保守においては設計者以外にも第三者が対応するケースがあるだけに、誰が見ても分かりやすく読みやすいコードが求められるというわけです。

そこで、可読性を高めるための方法をいくつか取り上げてみます。

"第2回「可読性の高い記述」(201206)"の詳細»

第1回「非同期回路の設計」(201205)

「たまにレジスタがおかしな値になる。」「連続データのはずが、たまにデータが抜けることがある。」「指定していないアドレスのレジスタ値が書き変ってしまった。」実機検証でこのような経験をされたことはないでしょうか?こんな時はまず非同期クロック間のデータ転送を疑ってみたほうがよさそうです。
「そもそもなぜ設計において非同期クロックが必要となるのか?回路設計は単一クロックが基本のはずだが?」と思われる方もおられるかも知れません。確かにその通りで回路設計は単一クロック単一エッジの同期設計で行うのが基本です。
しかしながらシステム全体を見渡してみると、CPU、バス、通信インターフェース回路、画像表示回路、ユーザ回路などにおいて必要となるクロック周波数は様々であり、システム全体でクロックを統一することはほぼ不可能と言えます。
ということで非同期クロック間のデータ転送を行う回路(以下非同期回路と呼ぶ)はシステムでは不可欠な構成要素なのです。
では、冒頭のような不具合を発生させないためにどのような回路設計を行えばよいのでしょうか。ポイントは2つあります。

"第1回「非同期回路の設計」(201205)"の詳細»
XILINX
教育サービス
HDLABトレーニング(SystemC)
HDLABトレーニング(SystemVerilog)
HDLABトレーニング(Verilog HDL)
HDLABトレーニング(フレッシュマン向け)
HDLABトレーニング(専門分野)
HDLABトレーニング(組込み分野)
HDLABトレーニング(XILINX認定)
HDLABトレーニング日程表
HDLABトレーニング開催リクエスト
設計スキルアセスメント
設計技能検定試験「ESA」
設計技能検定試験「ESA Basic」
設計・コンサルティング
ARM CPUモデル環境
SystemC
Design Style Guide
e-Learning System「STIL」
設計・検証のワンポイント
購入・見積もり
ダウンロード
お問い合わせ

XAP