これらを解決すべく、下記の３点を基本コンセプトにuSDCONFソリューションを開発しました。 ①簡単に操作できること。 ②書き換えに時間がかからないこと。 ③複数のバイナリファイルを取り扱えて、瞬時に切り替えが可能なこと。 以下、その効用などを列挙してみました。
◇	右図はデバッグではお馴染みのバグ成長曲線です。 デバッグを始めた初期は基本機能の確認や設備の不慣れで緩やかな立ち上がりですが、中盤にバグの検出が集中し、終盤は緩やかに漸近線に近づいていきます。 グラフがしっかりねれば、ようやく製品出荷となります。
◇	さて、FPGAを使ったシステムにおいて、このグラフをもっと俊敏に立ち上げることはできないのでしょうか。 デバッグ作業においては、   ①RTL修正   ②シミュレーション検証   ③コンパイル   ④コンフィグレーション   ⑥実動作検証 の一連の作業を、グラフがしっかりとねるまで延々と繰り返します。
	これらの５つの作業に要する時間を短縮すること、回数そのものを減らすことができれば、グラフはもっと俊敏に立ち上がり、より早く漸近線に近づけることができることでしょう。 uSDCONFはこれら５つの作業のうちの④のコンフィグレーションと⑤の実動作検証の時間および質を改善させるのに貢献します。
◇	まず④のコンフィグレーション時間の短縮については、メリット１で紹介してある、簡単操作・高速書き込み機能により実現できます。 既存のシステムでは、JTAGケーブルによってROMにコンフィグレーションデータを書き込んでおり、ケーブルのセットアップから転送完了まで１０分以上要してしまいますが、microSDCardを採用することで、バイナリデータを数十秒で書き込むことが可能となり、それを数秒でシステムに移し替えることができるので、大幅な時間短縮が図れます。 FPGAの論理サイズも日々巨大化し、現時点でもバイナリデータが数十メガバイトと膨れ上っており、microSDCardを媒介とすることは、有益な方法の１つといえるでしょう。
◇	次に⑤の実動作検証の時間短縮及び質を高める手段はメリット２で紹介してある機能により改善できます。 実動作検証で発見されるバグは、シミュレーション検証をかいくぐってきた厄介な代物です。 シミュレーション検証でこのバグを潰すには、その発生メカニズムを把握し、それをシミュレーションで再現してあげない限り、シミュレータの画面にその姿を現わすことはないでしょう。 厄介なバグになると、例えば電源投入１万回に1回現れるといった代物です。ごく稀の現象も、システムが１００万台出荷されれば、最初の電源投入時だけでも１００台のシステムでその症状が現れることになります。 この症状を捕えるためには、過去のVer間の出現頻度の差を見て相関性を把握する必要があるでしょうし、様々なトラップ回路を埋め込んだバイナリデータを準備して、その出現をしっかりと捕える方法などが考えられます。 このような手段の実現に、uSDCONFのロータリーＳＷによるバイナリデータの選択機能は威力を発揮します。 microSDCard上に過去のVerのバイナリデータや、様々な想定のもと、トラップ回路を埋め込んだバイナリデータを複数準備しておくことにより、ロータリーSWの設定を変えて再コンフィグレーションを繰り返すことにより、思考の中断をすることなく、まるで残像を比較するかのようにアプローチして、効率的にバグを捕えることが可能になるでしょう。
◇	これら２点の効用は、バイナリデータのサイズにもよりますが、１回のターンアラウンドで１０分以上の時間短縮が図れるでしょう。 この効果はターンアラウンド回数を掛け合わせただけ現れます。 また、デバッグの作業に関わっているリソース数に対して現れます。 このように人件費の削減に大きく貢献することでしょう。 また、早期の売上確保にも貢献することでしょう。
	以上、uSDCONFの効用はご理解いただけましたでしょうか。
	もう、基板が上がってきているから、今回は採用できないや、とか、
	次の案件はまだ先だから、そのとき考える、とか、よく耳にします。
	でも大丈夫。モジュールですから。
	既製品の基板に対しては、ROMを取り外して、あるいはROMを実装する代わりにuSDCONFをジャンパ配線する方法を提案します。
	また、次の案件までに時間が取れるのなら、今のうちに試してみて、リスクと見なされている内容をクリアして下さい。
	一度使っていただくと、手放せなくなること請け合いです。