25093
あるLSIで使用できるDMAの転送速度について調査を行っています。  
データシートなどで直接的に転送速度に関する記述が見つけられなかった為、困っています。  
DMAの転送速度について、一般的にどのような情報があれば算出できるでしょうか。

具体的な製品で言うと例えば Texas Instruments の CC1310 というLSIです。  
<http://www.tij.co.jp/product/jp/CC1310>

以下の資料で「Data sizes of 8, 16, and 32
bits」という文言を見つけられたので、一度に書き込めるサイズはこれなのかなと思いました。  
この値にクロック周波数などをかければ、bpsに結びつきますでしょうか。  
・CC1310 SimpleLink Ultralow Power Sub-1-GHz Wireless MCU  
<http://www.tij.co.jp/jp/lit/ds/symlink/cc1310.pdf>

* * *

@774RR  
回答頂きありがとうございます。  
ご認識のとおりです。

また、最近のマイコンについても教えて頂きありがとうございます。

> DMA TransferSize * (1/Clock) /2

こちらなのですが、以下の場合、認識に相違ないでしょうか。  
・DMA TransferSize = 1024  
・Clock = 10kHz  
1024 * (1/10000) / 2 = 転送レート：0.0512  
どこかで計算を間違えてる気がするのです、、すみません、、H/Wについて知識が浅いもので、ご教示頂けると幸いです。

> (だからデータシートにも載っていないし載せることが不可能)

こちらについては、わからないと DMA を使う意味がわからないと思いました。  
その為、厳密な値でなくても、参考値みたいなものまではたどり着ける必要があるかなと思いました。  
こういった場合によく使う求め方があったりしないかなぁと思い、質問した次第です。

* * *

追記

> それはその通りなんですが、データシートを深く理解する時間が取れない場合も多々あります。  
>  最近はマイコンラインアップも充実してますし、最初の設計段階では深く考えずに  
>  「このマイコンのこのクロックで処理速度を実測して間に合わないなら、  
>  上位マイコンにしてクロック上げちゃえ」  
>  などという恥ずべき設計者もかなり居る様子っす。

なんと、そうなんですね。。非常に残念な実態です。。  
自身が実装しようとしている物の上位にあたるシステムを理解せずに開発を進めるということですよね。。  
WEBアプリなどでも言えることですが、フレームワークのふるまいを理解せずに開発するのって、バグの温床だと思っています。。  
また、リソースを増やすことで問題解決って、、なんか残念ですね。。まあ、よくある話なのはわかっています。。笑

> 実際それで行けちゃう（コスト的に）場合も多いので、それなら開発期間短縮のほうが優先、  
>  なんてのが多いようですね。

ちょっと、ショックですがコストなど含めて問題ないのであれば、そうなってしまうのかもしれないですね。。

> あるいは通常の割り込み処理でソフトウエア処理しても間に合うマイコンを採用するとか。  
>  ソフトウエア処理では間に合わなくて DMA だと間に合う、ようなぎりぎりの設計することは  
>  オイラの周りでは稀っす。

そうなのですね。  
今回は、「ある時間」内に、ADCからの音声データをソフトコーデックしながら...というシステムなのですが、ADCからのデータをマイコンに割り込みで渡していてはソフトコーデックに支障が出て、間に合わないのでは？という推測により、DMAの利用を検討していました。  
私の個人的意見になってしまうのですが、今回の様な要件については「DMA
だと間に合う」っていうのはH/Wを有効に使えているのでシステムとして良いかなと思いました。

> そこまでぎりぎりだと機能追加していくと破綻すること必至だし。

"ソフト"の機能追加という意味ならば、DMAで処理を分散したほうが、マイコンの余裕もできて、むしろ拡張性もあるかなと感じました。

> DMA TransferSize / (1/Clock) / (1+1)

すみません、ちょっと分からないのですが、周波数は１秒間のサイクル数ですよね？  
そうなると、「DMA TransferSize * Clock」ではダメでしょうか？  
要するに、例だと「32bit * 48MHz」かなと思いました。  
それから、1clockで1bitだけのRead/Writeって考えにくくないでしょうか？  
だいたい、1clockでワード単位ではないですか？なので「/
(1+1)」について疑問に思ってしまいました。あえて、計算に加えなくても良いかなとも思えました。  
（検討違いなこと言っていたら、すみません。。）
CC BY-SA 3.0
2016-05-18T08:24:58.513
24964
2016-05-23T04:44:50.343
2016-05-19T01:38:40.530
15316
15316
question
c
Direct Memory Access (DMA)の転送速度の計算方法について
DMA ってことは周辺装置の FIFO から RAM へ RAM から FIFO へ転送したいってことだと思うのですが  
周辺装置/RAM/ROM のアクセスクロックが同じで、アクセスウエイトが 0 ならば

```

    DMA TransferSize / (1/Clock) / (1+1)
    
```

で転送レートになるでしょうね (１ビットの転送には Read+Write が必要なので /(1+1) っす)

実際には、最近のマイコンは core だけやたら速くて周辺回路は遅いのが多く  
例えば Renesas の例では RX マイコンとか SH マイコンとかだと  
RAM のクロック (ICLK) と周辺回路のクロック (PCLK) は異なるように使うのが普通です。  
しかも例えば ICLK=96MHz PCLK=48MHz にて動作させると  
RAM は ICLK で 0wait なのに対して (1ICLK 動作)  
I/O は PCLK で 3wait を要する (4PCLK 動作 = 8ICLK 相当)  
などとなっています。

マイコンの動作クロックは応用目的でみな違うように使うものですし、  
あなたが動作させているクロックモードでマイコンコア・周辺回路がどう振る舞うかを  
データシートを厳密に読んで分析しないと正しい答えが出せません。

結論的には簡単には求まらないってことになりそうです。  
(だからデータシートにも載っていないし載せることが不可能)

以下追記・すみません最初の式が間違ってますよね。読み直してください。

ちょっと例を計算してみましょう。  
転送バイト数は計算に入れなくていいの OK ですか？  
(１回の転送で何ビット転送できるかだけが要考慮)

RX マイコンのような ICLK と PCLK が違うマイコンを想定します。 RAM は 0wait とします。

ICLK=48MHz で RAM から RAM へ DMA (意味がないけど) 32bit Transfer とすると  
DMA の１転送に RAM READ 1ICLK と RAM WRITE 1ICLK を要するので

```

    32bit / (1/48MHz) sec / (1+1) = 768 Mbit/s (除数は 1000)
    
```

同様 PCLK=24MHz でアクセスに 3wait が必要な 16bit FIFO から RAM へ転送するとして

DMAC が I/O と RAM をオーバーラップアクセスできない場合  
最初の FIFO の READ に 4PCLK=8ICLK  
最初の RAM の WRITE に 1ICLK  
次の FIFO の READ のためには PCLK/ICLK の同期が必要で +1ICLK  
ということは

```

    16bit / (1/48MHz) sec / (8+1+1) = 76.8Mbit/sec (除数は 1000)
    
```

DMAC が I/O と RAM をオーバーラップアクセスできる場合  
最初の FIFO の READ に 4PCLK=8ICLK  
次の FIFO の READ をしながら最初の RAM WRITE ができるので  
RAM 側のアクセス時間は FIFO のアクセス時間に吸収されてしまうことになり

```

    16bit / (1/48MHz) sec / (8) = 96Mbit/sec (除数は 1000)
    
```

なんかえらい差が出てますね。  
実際のマイコンがどっちなのかはデータシートの深い読み込みが必要です。

> わからないと DMA を使う意味がわからないと思いました。

それはその通りなんですが、データシートを深く理解する時間が取れない場合も多々あります。  
最近はマイコンラインアップも充実してますし、最初の設計段階では深く考えずに  
「このマイコンのこのクロックで処理速度を実測して間に合わないなら、  
上位マイコンにしてクロック上げちゃえ」  
などという恥ずべき設計者もかなり居る様子っす。  
実際それで行けちゃう（コスト的に）場合も多いので、それなら開発期間短縮のほうが優先、  
なんてのが多いようですね。

あるいは通常の割り込み処理でソフトウエア処理しても間に合うマイコンを採用するとか。  
ソフトウエア処理では間に合わなくて DMA だと間に合う、ようなぎりぎりの設計することは  
オイラの周りでは稀っす。  
そこまでぎりぎりだと機能追加していくと破綻すること必至だし。
CC BY-SA 3.0
2016-05-18T10:25:51.107
24968
2016-05-18T13:11:03.220
2016-05-18T13:11:03.220
8589
8589
24964
answer
コメントでは引用しづらいので別回答の形式で

> そうなると、「DMA TransferSize * Clock」ではダメでしょうか？

はい、問題ないです。個人的に、オイラがこの手の計算するときの考え方として、  
求めたい解が bit / sec であれば「 ビット数 割る 時間 」になるよう式を考えるので  
ああいう書き方をしました。  
ただし、この式はバスアクセスに何クロックかかるかを計算していませんので未完成です。

> それから、1clockで1bitだけのRead/Writeって考えにくくないでしょうか？  
>  だいたい、1clockでワード単位ではないですか？

CPU core にせよ DMAC にせよ、考え方は  
\- １回のバスアクセス何ビットが転送できるか  
\- １回のバスアクセスで何クロックがかかるか  
(速度の考察ならここまで。必要時間の計算なら下記も)  
\- バスアクセス何回が必要か  
です。

１回のバスアクセスで１ビット転送というのは指摘のとおりまずありえません。  
では何ビットの転送ができるか、というと周辺装置のアクセスにはハードウエアによる制約が  
課せれていることが多く、それで決まってしまいます。  
32bit なマイコンでも、特定ポートは 8bit アクセスのみ許可なんてのはよくあります。  
その場合先の DMA TransferSize=8 になってしまいます。  
もちろん 32bit アクセス可能なポートなら 32bit DMA できて DMA TransferSize=32 っす。

> なので「/ (1+1)」について疑問に思ってしまいました。

この除算は１回のバスアクセスに何クロックかかるか、の考慮分ですので必要です。  
Read と Write が同時にできないなら Read に１クロック Write に１クロック必要なので  
「１回の転送」には２クロックが必要です。

RAM/ROM は 0wait (1clock) でアクセスできるとしても、  
周辺回路のアクセスには複数クロックが必要なことが多いです。  
実際に何クロックかかるかはデータシートを見る必要があります。

で、最終的にどのくらいの性能が出るかの例は前のコメントで計算したような感じになりますね。
CC BY-SA 3.0
2016-05-23T04:44:50.343
25093
2016-05-23T04:44:50.343
8589
24964
answer