Verilog-HDL 両エッジ対応
両エッジ対応ですが使いどころがイメージしにくいと思いますが、例えばI2Sフォーマット（受信）のLR信号でデータのラッチをかけたい場合などに必要となります。
さて↓のタイミングチャートをご覧ください。
上記フォーマットでLRCK変化時にデータをラッチしてあわせて完了パルスを出力します。パルスのクリアにはBCKを使うことにします。これをコードにすると
always @ (lrck or negedge bck)
// 処理
という記述にで対応できますが、Model-Simでは問題ありませんが、Quartus IIではエラーとなります。
ダブルエッジとシングルエッジをorできないということのようです。
Webをいろいろと調べましたが、これといった解決法を見つけられませんでしたが、案外解決方法は簡単でしたのでここで紹介します。
↓のコードをご覧ください
//第１段階
wire n_lrck = ~lrck;
always @ (posedge lrck or posedhe n_lrck or posedge bck)
// 処理
２つ目のn_lrckはnegedge lrckとすればよいと思ったかもいるかと思いますが、それもエラーでした。
ただし、上記だけでは、bckの立上りで完了パルスをクリアしたいのですが、これでもまだ不完全です。
lrckの変化で呼ばれたのかbckの変化で呼ばれたのかが判断できないためです。
ですので、下記のように改良します。
//第２段階
always @ (posedge bck)
if (done)
done_clr <= 1'h1;
else
done_clr <= 1'h0;
always @ (posedge lrck or posedge n_lrck or posedge done_clr)
if (done_clr)
done <= 1'h0;
else
done <= 1'h1;
//データラッチはdoneの立ち上がりエッジで
少々ややこしいですが、じっくり考えればわかると思います。
分からないという方のために解説します。
bckの立下りでクリアしたいのでbckの立上り時に完了フラグ（done）が立っているときはクリアフラグ（done_clr)をあげます。
クリアフラグが上がったときは完了フラグをクリアします。
それいがいのLRCKの立ち上がり立下りで呼ばれたときは完了フラグを上げます。
また完了フラグが下がっている場合はクリアフラグもクリアします。
↓の図はModel-simでもシミュレート結果（lrckの立下りだけですが、立ち上がりも同様）
ご参考まで～
trollimグルっぽ始動！(アメブロ)
trollim.com始めてみたけど使い方がよくわからない、バトル挑戦者募集、なんか動作がおかしい
などなどtrollimがらみの話題や質問を気楽に楽しむコミュニティを作りました(^^)
ご登録お待ちしております！
コードレビューとテスト設計の失敗事例
KLOC当たりのレビュー時間はIPA/SEC刊行の書籍(品質作り込みガイド)が参考になりますが、品質の劣化なしに更なる効率化ができないかとマネージャーの皆さんは思われてるのではないでしょうか？
今回は重複作業の一本化と言う趣旨で、コードレビューとテスト設計(テスト設計レビュー含む)を一緒に行うことにしました。２つの作業の成果物は異なりますが、『設計書』，『ソースコード』を眺めながら進めると言う意味では共通点があります。ここまで読んで何いってんだと笑われる方が多数かと思いますが、本気で効率化出来ないものかと考えています(^-^)
さてさて、繰返しですが、コードレビューもテスト設計も設計書とコードを精査します。
よってコードの正確性を確認しながらどのようにその正確性が保証されるかを考えたら良いわけです。つまりV&V(Verification and Validation：検証と妥当性の確認)の考え方そのものです。
今回４人でのコードレビューで、事前に趣旨の説明は口頭でしており、レビュー開始時にも趣旨説明をし同意を得た上で行いました。
全員がコードレビューの経験もテスト設計の経験もあり３人はベテランです。
さて！結果はというと、タイトルの通り失敗でテスト設計に関しては失敗でした。
失敗の原因は３つと分析しています。
１．疲労
コードレビュー単体でも疲労するのにテスト設計を含めた体力(気力)が湧かない
２．担当者は無意識中にコードレビューを完了させたいという意識が働き、テスト設計まで気が回らない
３．準備不足
準備８割とはよくいったものです。テスト設計を一緒に行うと言ったもののその準備が出来ていなかった。
これではテスト設計できるわけないですよね
次回機会があれば３の対策に力を入れてみたいと思います(^^)