Verification Evangelistの戯言

Good Models

Verification Evangelistの戯言 : Twitter
SystemVerilogの世界へようこそ、すべては、SystemC v0.9公開から始まった

Good Men(初めてPV見た)なら、ここ数ヶ月、iPadでストリーミングで聞いていますが、
今回はGood Modelsのお話。

Synopsysのブログ：Good Modelsの

引用
    A good model, in my eyes, is one that serves the purpose of the user 
    at the right point, on time at a proper cost. 
    Here, the user task has to be carefully reviewed before selecting 
    or creating a TLM model. 

まさに。

なので、使う側の目的を明確にしないで、モデルありませんね！なんて、言ってはいけません。

本来、モデルは自分で作るもの。調達するのはそのようがトータルで安いから。
(トータルが重要、単価が安くてもメンテナンスに金がかかるのは、どうかな？）

検証、Verification、Virtual Platform

これが噂のGPUデモ

Verification Engineerの戯言 : Twitter
SystemVerilogの世界へようこそ、すべては、SystemC v0.9公開から始まった

DMPのGPUのデモを仮想環境でということで、
EDA Onlineのちょっとリアルな仮想プラットフォーム、富士通セミコンが構築して実演の記事を読みました。

SystemCベースの仮想プラットフォームに、FPGAボードを接続して、RTLコードのFPGAに焼き込んで、
SystemCと協調シミュレーションできるようです。

FPGAボードとの接続は、ProbeLinkを使ったいるようです。
ProbeLinkハードウェア・インターフェース・キットを使って、PCにPCIe Card を接続し、
このPCIe Cardとケーブルにて、ProbeLink Interface Cardを接続します。
FPGAボードとは、ProbeLink Interface Cardとパラレルケーブルにて接続します。

ProbeLinkはSCE-MIをサポートしているので、
SystemCシミュレータとProbeLink Interface Cardとは、SCE-MIにて接続します。

SystemCシミュレータとSCE-MIとで接続するので、トランザクションベースのプラットフォームが
構築できます。

このシステムがあれば、FPGAにいろいろなRTLを焼き込めるので、便利だと思います。

あとは、お値段次第でーす。いくらですか？　Hさーん。

検証、Verification、VirtualPlatform、SystemC

P.S
ProbeLinkの解説は、こちらにあります。

ARMのFastModelとCadenceのVSP

Verification Engineerの戯言 : Twitter
SystemVerilogの世界へようこそ、すべては、SystemC v0.9公開から始まった

Using the ARM Profiler with the Cadence Virtual System Platformでは、
CadenceのVirtual System Platform上でARMのFastModel + RVDS Professional + ARM Profiler を動作させるための方法について説明しています。

ターゲットCPUは、Cortex-M3で、Quantum Platformのフレームワークを使ったようです。
Cortex-M3レベルであれば、このようなS/Wでいいのでしょうかね？

P.S
ARMのRVDSって、Linuxで使うモノでしょうか？
まー、CadenceのVSPがLinuxでしか動かないのでそのようになっているのでしょうが、

検証、Verification、Virtual Platform、Cadence

Software Driven Verification ： Synopsys編

Verification Engineerの戯言 : Twitter
SystemVerilogの世界へようこそ、すべては、SystemC v0.9公開から始まった

Software Driven Verificationでは、
Synopsysが考えるSoftware Driven Verificationの事例を説明しています。

事例の内容は、Synopsysの定番であるUSB IPの検証。
今回は、同一デバイスのUSB OTG の検証を一方はHost、もう一方はDeviceにして対向にして検証。
共に、Linuxベースの環境。

Virtual Platformだけでなく、FPGA Prototype もSCE-MI 2.0を使って、VPに接続して使っています。
USB IPはFPGA Prototypeに接続する。
USB PHYは別ボードのものを接続し、USB Stickにアクセスするというもの。
いままでと何が違うというと、FPGA PrototypeがVirtual Platformに接続できること。

Synopsysは、VP単体については結構長くやっているし、FPGA PrototypeもHAPSやChipItがある。
別々ではもったいないので、繋げる。その方法は、SCE-MI 2.0。これだと、VCSとも繋がるので、二度美味しい。

このシステムをHybrid ExecutionとSynopsysは読んでいます。
結構使えると思います。

ということは、

    MentorもVistaとVeloceを繋げられる。
    CadenceもVirtual Platfrom と FPGA Protypeをアナウンスした

ので、またまた、3社、それぞれのソリューションというわけですね！

ただし、MentorはエミュレータのVeloceなので規模はOKですが、価格は桁が違うと思う。

検証、Verification、Synopsys、Virtual Platform

P.S
先日の「Questaが可能にする機能検証改革」セミナーにて、@HarryAtMentor さんにMentorはFPGA Prototypeをどう考えるようなことを質問しました。
どうして質問したかは、MentorはFPGA Prototypeを提供していないからです。

で、回答は「FPGA Prototypeは重要である」ということで、Mentorがどうするとまでは明言してくれませんでした。

A SystemC TLM 2.0 ARM Linux Boot Loader

Verification Engineerの戯言 : Twitter
SystemVerilogの世界へようこそ、すべては、SystemC v0.9公開から始まった

Virtual Platformを使って、SoCのソフトウェアの先行開発(早期開発)を行う。

今の流れは、これが基本。

それで、Virtual Platformで何を動かすのか？
ブートコードやOS、できれば、OSより上の層のソフトウェア。
確かに、で、一番最初にやるのが、ブートコードを呼び出すこと。
これって、どうやるのか、ASIC設計をしている人って、ほとんどしりません。

どうやればいいのでしょうか？

今回紹介するケイデンスのブログ、A SystemC TLM 2.0 ARM Linux Boot Loaderでは、
ARMシステムにおけるLinuxのブートローダーについて、詳しく？説明しています。
(詳しくといっても、ブートの仕組みを知らないとすれなりにはわかりませんが)

この記事で1箇所、
Linuxのブートローダーのアドレスを設定している下記のコード(引用)は、ちょっと間違っていると思います。

    // Load bootcode
    bootloader[1] |= info->board_id & 0xff;
    bootloader[2] |= (info->board_id >> 8) & 0xff;
    bootloader[5] = info->loader_start + KERNEL_ARGS_ADDR;
    bootloader[6] = entry;

何が間違っているかと言えば、bootloaderのインデックスが1から始まっています。

    // Load bootcode
    bootloader[0] |= info->board_id & 0xff;
    bootloader[1] |= (info->board_id >> 8) & 0xff;
    bootloader[4] = info->loader_start + KERNEL_ARGS_ADDR;
    bootloader[5] = entry;

だと、思います。

検証、Verification、SystemC、TLM 2.0、Virtual Platform