FC2カウンター FPGAの部屋 Vivado HLS

FPGAやCPLDの話題やFPGA用のツールの話題などです。 マニアックです。 日記も書きます。

FPGAの部屋

FPGAの部屋の有用と思われるコンテンツのまとめサイトを作りました。Xilinx ISEの初心者の方には、FPGAリテラシーおよびチュートリアルのページをお勧めいたします。

Vivado HLSで関数内のBRAMを関数外から制御する2(C++のクラスを使って書いてみた)

Vivado HLSで関数内のBRAMを関数外から制御する1”の続き。

前回は、Vivado HLS 勉強会で一緒だった学生さんからVivado HLSの関数内で宣言したBRAM を外から読み書きしたいのだけど、どう書いたら良いか?という質問があったので、C 言語でサンプルコードを書いてみた。今回は、C++ のクラスを使って、サンプルコードを書いてみた。

まずは、C++ のクラスを使用して書いた、Vivado HLSの関数内で宣言したBRAM を外から読み書きするサンプルコードの bram_test2.cpp を示す。

// bram_test2.cpp
// 2018/02/06 by marsee
//

class bram {
    int array[1024];
public:
    void bram_write(int &index, int &data);
    void bram_read(int &index, int &data);
};

void bram::bram_write(int &index, int &data){
    array[index] = data;
}

void bram::bram_read(int &index, int &data){
    data = array[index];
}

int bram_test(int &index, int &wr, int &data){
#pragma HLS INTERFACE s_axilite port=data
#pragma HLS INTERFACE s_axilite port=wr
#pragma HLS INTERFACE s_axilite port=index
#pragma HLS INTERFACE s_axilite port=return

    static bram bram_inst;

    if(wr == 0){ // Read
        bram_inst.bram_read(index, data);
    }else// Write
        bram_inst.bram_write(index, data);
    }

    return(0);
}


なお、テストベンチは”Vivado HLSで関数内のBRAMを関数外から制御する1”の bram_test1_tb.cpp のままだ。

Vivado HLS 2017.4 で bram_test2 プロジェクトを作成した。
bram_test_15_180207.png

C シミュレーションを行った。結果を示す。前回同様だ。
bram_test_16_180207.png

C コードの合成を行った。結果を示す。
bram_test_17_180207.png

前回と比較すると LUT が 15 個多い。その他は同じだ。

C/RTL 協調シミュレーションを行ったが、前回同様に終了しない。強制的にストップした。

C/RTL 協調シミュレーションの波形を示す。やはり、WDATAなどが表示されない。
bram_test_18_180207.png

Export RTL を行った。結果を示す。
なお、Vivado synthesis, place and route にチェックを入れてある。
bram_test_19_180207.png

IP 化はできている。

ここで前回土曜に指示子をコメントアウトして、デフォルトのI/Oプロトコルとブロックレベルのプロトコルにしてみよう。
bram_test_20_180208.png

C コードの合成を行った。結果を示す。
bram_test_21_180208.png

このリソース使用量は前回と一致している。

C/RTL 協調シミュレーションを行った。結果を示す。
bram_test_22_180208.png

C/RTL 協調シミュレーションの波形を示す。
bram_test_23_180208.png

Export RTL を行った。結果を示す。
なお、Vivado synthesis, place and route にチェックを入れてある。
bram_test_24_180208.png

これも前回と同様のリソース使用量となった。
  1. 2018年02月10日 21:01 |
  2. Vivado HLS
  3. | トラックバック:0
  4. | コメント:0

Vivado HLSで関数内のBRAMを関数外から制御する1

この前、Vivado HLS 勉強会で一緒だった学生さんからVivado HLSの関数内で宣言したBRAM を外から読み書きしたいのだけど、どう書いたら良いか?という質問があったので、サンプルコードを書いてみた。

bram_test1.cpp を示す。

// bram_test1.cpp
// 2018/02/06 by marsee
//

int bram_test(int &index, int &wr, int &data){
#pragma HLS INTERFACE s_axilite port=data
#pragma HLS INTERFACE s_axilite port=wr
#pragma HLS INTERFACE s_axilite port=index
#pragma HLS INTERFACE s_axilite port=return
    int array[1024];

    if(wr == 0){ // Read
        data = array[index];
    }else// Write
        array[index] = data;
    }

    return(0);
}


テストベンチの bram_test1_tb.cpp を示す。Read してWrite してRead というだけの単純なテストベンチだ。

// bram_test1_tb.cpp
// 2018/02/06 by marsee
//

#include <stdio.h>

int bram_test(int &index, int &wr, int &data);

int main(){
    int index, wr, data;

    wr = 0; index = 0;
    bram_test(index, wr, data);
    printf("data = %x\n", data);

    wr = 1; index = 0; data = 0x1;
    bram_test(index, wr, data);

    wr = 0; index = 0;
    bram_test(index, wr, data);
    printf("data = %x\n", data);

    wr = 0; index = 1;
    bram_test(index, wr, data);
    printf("data = %x\n", data);

    wr = 1; index = 1; data = 0x2;
    bram_test(index, wr, data);

    wr = 0; index = 1;
    bram_test(index, wr, data);
    printf("data = %x\n", data);

    return(0);
}


Vivado HLS 2017.4 で bram_test1 というプロジェクトを作成した。ターゲットはZYBO Z7-20 だ。
bram_test_1_180207.png

C シミュレーションを行った。配列のイニシャライズはされていないが、書き込んだ後は同じ値が読めている。
bram_test_2_180207.png

C コードの合成を行った。結果を示す。
bram_test_3_180207.png

BRAM_18K の使用量は 0 個だった。BRAM が実装されていない。
やはり、これは、C 言語では、関数内の宣言したローカル変数の配列はスタック領域にマップされて、関数から戻るときはクリアされる仕様が問題なんじゃないかな?ということで、static を配列の宣言に追加することにした。こうすれば、関数を抜けても配列は保持される。
bram_test_4_180207.png

// bram_test1.cpp
// 2018/02/06 by marsee
//

int bram_test(int &index, int &wr, int &data){
#pragma HLS INTERFACE s_axilite port=data
#pragma HLS INTERFACE s_axilite port=wr
#pragma HLS INTERFACE s_axilite port=index
#pragma HLS INTERFACE s_axilite port=return
    static int array[1024];

    if(wr == 0){ // Read
        data = array[index];
    }else// Write
        array[index] = data;
    }

    return(0);
}


これで、C シミュレーションを行った。結果を示す。
bram_test_5_180207.png

今度は配列がイニシャライズされていた。Read、Write も問題ない。

C コードの合成を行った。結果を示す。
bram_test_6_180207.png

BRAM_18K が 2 個実装されている。良さそうだ。

C/RTL 協調シミュレーションを行うと、終わらなかった。
なので、テストベンチをRead、Write 1 個のみにして、C/RTL 協調シミュレーションを行った。
bram_test_7_180207.png

でもやはり、終わらない。
bram_test_8_180207.png

途中で止めて波形を見てみよう。C/RTL 協調シミュレーションの波形を拡大してみてみよう。まずは、WVALID などのWrite の信号が表示されていない。これは、途中でC/RTL 協調シミュレーションを止めてしまったからなのか?
bram_test_14_180207.png

それじゃ、AXI4 Lite Slave インターフェースの予定だが、デフォルトでやってみよう。AXI4 Lite のインターフェースの指示子を取ってしまった。
bram_test_9_180207.png

これで、C コードの合成を行った。結果を示す。
bram_test_10_180207.png

FF、LUT は使用量が少なくなったが、BRAM_18K は 2 個使用されていて問題ないようだ。

C/RTL 協調シミュレーションを行った。結果を示す。
bram_test_11_180207.png

正常終了している。やはり、AXI4 Lite インターフェースの時だけおかしいのかな?

C/RTL 協調シミュレーションの波形を示す。
bram_test_12_180207.png

正常にアクセスできているようだ。

このまま、Export RTL を行った。結果を示す。
なお、Vivado synthesis, place and route にチェックを入れてある。
bram_test_13_180207.png

BRAM も 2 個使われていて、問題なさそうだ。
  1. 2018年02月07日 05:06 |
  2. Vivado HLS
  3. | トラックバック:0
  4. | コメント:0

Vivado HLS 2017.4 で片方が定数の場合の乗算の検討9(畳み込み演算6)

Vivado HLS 2017.4 で片方が定数の場合の乗算の検討8(畳み込み演算5)”の続き。

前回は、2 つの畳み込み演算を並列に行うようにC ソースコードを書き換えたのだが、積和演算はLUT だけを使用した演算だった。さて、なぜLUT を使った演算にしてみたかというと、畳み込みニューラルネットワークを1クロックで演算できるようにするためにはDSP48E を使用すると足りなくなるという推測に基づいていた。もう 1 クロック動作はあきらめているので、DSP48E を使用しても問題は無さそうだ。ということで、DSP48E を使用する通常の積和演算をやってみた。

multi_test4.cpp で

#pragma HLS RESOURCE variable=out_temp core=AddSub

をコメントアウトした。
multi_test_66_180206.png

C コードの合成を行った。結果を示す。
multi_test_67_180206.png

Estimated は 10.68 ns で Target の 10 ns を超えてしまっているが、Latency は 2 クロックで、これは短い。
リソース使用量は、DSP48E を使用され、14 個、FF は 350 個、LUT は 1,304 個使用している。
Latency が 2 クロックは短いな。。。

C/RTL 協調シミュレーションを行った。結果を示す。
multi_test_68_180206.png

やはり Latency は 2 クロックだった。

C/RTL 協調シミュレーションの波形を示す。
multi_test_69_180206.png

2 つの畳み込み演算器がデータを受け取ってから、演算を行い、出力の値をその先の回路が受け取るまでに 2 クロックだった。

Export RTL を行った。結果を示す。
なお、Vivado synthesis, place and route にチェックを入れてある。
multi_test_70_180206.png

LUT は 392 個、FF が 179 個、何故か?DSP が 23 個だった?
インプリメント後の遅延時間は 9.404 ns でギリギリだが、Vivado で合成してもうまく行くかもしれない?

さて、Estimated は 10.68 ns なので、10 ns 以下にしようとして、Uncertainty を 3 ns にした。
その合成結果を示す。
multi_test_71_180206.png

Latency は 3 クロックに増加した。
リソース使用量は、DSP48E が 14 個で変わらなかった。FF は 600 個で 350 個から増えている。LUT は1,304 個で変わらなかった。

Export RTL を行った。結果を示す。
なお、Vivado synthesis, place and route にチェックを入れてある。
multi_test_72_180206.png

LUT は 578 個で、392 個から増えていた。FF は 256 個で、これも179 個から増えた。DSP48E は 14 個でこれは合成の時と同じ数だ。DSP48E は本来合成の時と同じ数のはずだ。なぜ、前は増えたのだろうか?
  1. 2018年02月06日 05:03 |
  2. Vivado HLS
  3. | トラックバック:0
  4. | コメント:0

Vivado HLS 2017.4 で片方が定数の場合の乗算の検討8(畳み込み演算5)

Vivado HLS 2017.4 で片方が定数の場合の乗算の検討7(畳み込み演算4)”の続き。

前回は、2 個目の畳み込み演算の重みの配列を使用して違いを確認した。今回は、2 つの畳み込み演算を並列にやってみよう。

2 つの畳み込み演算を並列に行うためにC ソースコードを少し変更した。プロジェクトも新しく作成した。
multi_test4 プロジェクトを示す。
multi_test_60_180205.png

multi_test4.cpp を示す。

// multi_test4.cpp
// 2018/02/04 by marsee
//

#include <ap_fixed.h>
#include "multi_test4.h"
#include "conv1_weight.h"

int multi_test4(ap_ufixed_in in[25], ap_fixed_add &out0, ap_fixed_add &out1){
#pragma HLS ARRAY_PARTITION variable=in complete dim=1

    ap_fixed_madd out_temp = 0.0;

#pragma HLS RESOURCE variable=out_temp core=AddSub
#pragma HLS PIPELINE II=1

    conv0: for(int k=0; k<2; k++){
        conv1: for(int m=0; m<5; m++){
            conv2: for(int n=0; n<5; n++){
                out_temp += in[m*5+n] * conv1_weight[k][0][m][n];
            }
        }
        if(k==0)
            out0 = out_temp;
        else
            out1 = out_temp;
        out_temp = 0.0;
    }

    return(0);
}


これは前と同じだが、multi_test4.h を示す。

// multi_test4.h
// 2018/02/04 by marsee
//

#ifndef __multi_test_H__
#define __multi_test_H__
#include <ap_fixed.h>

typedef ap_ufixed<80, AP_TRN, AP_WRAP> ap_ufixed_in;
typedef ap_fixed<91, AP_TRN, AP_WRAP> ap_fixed_weight;
typedef ap_fixed<226, AP_TRN, AP_WRAP> ap_fixed_madd;
typedef ap_fixed<166, AP_TRN_ZERO, AP_SAT> ap_fixed_add;

#endif


muti_test4_tb.cpp を示す。

// multi_test4_tb.h
// 2018/02/04 by marsee
//

#include "multi_test4.h"

int multi_test4(ap_ufixed_in in[25], ap_fixed_add &out0, ap_fixed_add &out1);

int main(void){
    ap_ufixed_in in[25];
    ap_fixed_add out0, out1;
    ap_ufixed_in v = 0.5;

    for(int i=0; i<25; i=i++){
        in[i] = (ap_ufixed_in)v;
        v += (ap_ufixed_in)0.00390625;
        printf("in[%d] = %f\n", i, (float)v);
    }

    multi_test4(in, out0, out1);

    printf("out0 = %f\n", (float)out0);
    printf("out1 = %f\n", (float)out1);

    return(0);
}


これで C シミュレーションを行った。結果を示す。
multi_test_61_180205.png

出力値は正常だ。

C コードの合成を行った。結果を示す。
multi_test_62_180205.png

Latency は 7 クロックだった。2 つの畳み込み演算を並列にできているようだ。
なお、conv0 の for ループに UNROLL 指示子を入れても、入れなくても結果は変わらなかった。
BRAM_18K や DSP48E は使用していない。FF は 1,424 個、LUT は 2,767 個使用している。

次に、C/RTL 協調シミュレーションを行った。結果を示す。
multi_test_63_180205.png

C/RTL 協調シミュレーションの波形を示す。
multi_test_64_180205.png

2 つの畳み込み演算器がデータを受け取ってから、演算を行い、出力の値をその先の回路が受け取るまでに 7 クロックだった。

Export RTL を行った。結果を示す。
なお、Vivado synthesis, place and route にチェックを入れてある。
multi_test_65_180205.png

こちらは、1 個目の畳み込み演算器の影響を受けるだろうから、この値になっていると思う。少し、危なさそうな数値だ。
  1. 2018年02月05日 05:13 |
  2. Vivado HLS
  3. | トラックバック:0
  4. | コメント:0

Vivado HLS 2017.4 で片方が定数の場合の乗算の検討7(畳み込み演算4)

Vivado HLS 2017.4 で片方が定数の場合の乗算の検討6(畳み込み演算3)”の続き。

前回は、従来通りの畳み込み演算の重みの配列を使用して、LUT にマップされた畳み込み演算を行うことができた。今回は、畳み込みフィルタは 2 個ある。前回はそのうちの 1 個目を使用していたので、今回は、2 個目の畳み込み演算の重みの配列を使用して違いを見てみよう。

まずは、2 個目の畳み込み演算の重みの配列を使用するために、19 行目の

conv1_weight[0][0][m][n]

conv1_weight[1][0][m][n]

に変更して、2 個目の畳み込み演算の重みの配列を使用する。
multi_test_54_180204.png

これで C シミュレーションを行った。結果を示す。
multi_test_55_180204.png

出力 out = -0.18555 だった。これだとマイナスの値なので、ReLU で 0 になるはずだ。

C コードの合成を行った。左に今回の 2 個目の畳み込み演算の重みの配列を使用した場合、右に前回の 1 個目の畳み込み演算の重みの配列を使用した場合の合成結果を示す。
multi_test_56_180204.pngmulti_test_50_180203.png

Latency は前回は 7 クロックだったが、今回は 4 クロックに減っている。Interval は変わらずに 1 クロックのままだ。
リソース使用量の FF も前回は、1,286 個だったが、今回は 478 個で約 37 % に減っている。LUT も前回は、2,106 個だったが、今回は805 個で、約 38 % に減っていた。
2 個目の畳み込み演算の重みの配列を見ると、0 が多く入っていた。そして他の重みもたぶんリソース使用量が少なくなる値だったんだと思う。
このように、DSP48E を使用せずに片方が定数の場合は演算を簡単化することができるのだが、重みの値によって圧縮率が異なる。2つに畳み込みフィルタを使用する場合に、2つ独立にインスタンスするとLatency が異なると結果が出てくるクロックが異なるので、Latency を合わせる必要がある。

次に、C/RTL 協調シミュレーションを行った。結果を示す。
multi_test_57_180204.png

やはり、Latency は 4 クロックだった。
C/RTL 協調シミュレーションの波形を示す。
multi_test_58_180204.png

畳み込み演算器がデータを受け取ってから、演算を行い、出力の値をその先の回路が受け取るまでに 4 クロックだった。

Export RTL を行った。結果を示す。
なお、Vivado synthesis, place and route にチェックを入れてある。
multi_test_59_180204.png

LUT は247 個、SRL は0 個なので、LUT は247 個使用する。こちらのFinal Timing は問題なさそうだ。
  1. 2018年02月04日 04:55 |
  2. Vivado HLS
  3. | トラックバック:0
  4. | コメント:0

Vivado HLS 2017.4 で片方が定数の場合の乗算の検討6(畳み込み演算3)

Vivado HLS 2017.4 で片方が定数の場合の乗算の検討5(畳み込み演算2)”の続き。

前回は、乗算記号の * を使用して、畳み込みニューラルネットワークの畳み込み演算の重みを定数と置いたときの乗算で途中の演算の小数点以下の精度を下げてやってみた。今回は、従来通りの畳み込み演算の重みの配列を使用して、LUT にマップした演算ができないかどうか?を確かめてみた。

さて、Vivado HLS 2017.4 で multi_test3 プロジェクトを作成した。
multi_test_48_180203.png

multi_test3.cpp を貼っておく。

// multi_test3.cpp
// 2018/01/30 by marsee
//

#include <ap_fixed.h>
#include "multi_test3.h"
#include "conv1_weight.h"

int multi_test3(ap_ufixed_in in[25], ap_fixed_add &out){
#pragma HLS ARRAY_PARTITION variable=in complete dim=1
#pragma HLS PIPELINE II=1

    ap_fixed_madd out_temp = 0.0;
#pragma HLS RESOURCE variable=out_temp core=AddSub

    conv1: for(int m=0; m<5; m++){
#pragma HLS UNROLL
        conv2: for(int n=0; n<5; n++){
            out_temp += in[m*5+n] * conv1_weight[0][0][m][n];
        }
    }

    out = out_temp;

    return(0);
}


ご覧の様に、今までやってたように for ループを使用しているが、unroll 指示子でループを展開して、RESOURCE 指示子で AddSub を指定すれば、LUT を使用してくれるようだ。

次に、multi_test3.h を示す。

// multi_test3.h
// 2018/01/30 by marsee
//

#ifndef __multi_test_H__
#define __multi_test_H__
#include <ap_fixed.h>

typedef ap_ufixed<80, AP_TRN, AP_WRAP> ap_ufixed_in;
typedef ap_fixed<91, AP_TRN, AP_WRAP> ap_fixed_weight;
typedef ap_fixed<226, AP_TRN, AP_WRAP> ap_fixed_madd;
typedef ap_fixed<166, AP_TRN_ZERO, AP_SAT> ap_fixed_add;

#endif


conv_weight.h を示す。

// conv1_weight.h
// 2017/12/06 10:54:11 by marsee

const float conv1_fweight[2][1][5][5] = 
{
    {
        {
            {0.764403421227,0.658424746889,0.595604201652,0.554044871161,0.367767232883},
            {0.582414155838,0.413274869036,0.31659268154,0.3508390519,0.331194144626},
            {0.589182274309,0.462105790282,-0.241299390378,-0.10093021104,0.233291757594},
            {0.792411286764,0.315893121865,0.0397628864727,0.356726636694,0.426826537165},
            {0.634481192118,0.651475977113,0.688949928547,0.707285991358,0.681420943406}
        }
    }
    ,
    {
        {
            {0.00564732125401,-0.012955272371,-0.0231571581103,-0.00289983746176,0.0281080593816},
            {-0.0115360072012,0.00253310449813,-0.00860163957467,0.00112793810127,-0.01455040341},
            {-0.00881717612899,-0.00902248113722,0.0004194288468,0.00110240651437,-0.0140454059394},
            {0.00271556513713,-0.00307791921855,0.000117170379207,-0.00891721414879,0.0173026634286},
            {0.000808453898046,0.000116327205532,-0.00275343050716,-0.00683461392689,-0.0169130858704}
        }
    }
};

const ap_fixed<91, AP_TRN, AP_WRAP> conv1_weight[2][1][5][5] =
{
    {
        {
            {0.765625,0.66015625,0.59375,0.5546875,0.3671875},
            {0.58203125,0.4140625,0.31640625,0.3515625,0.33203125},
            {0.58984375,0.4609375,-0.23828125,-0.09765625,0.234375},
            {0.79296875,0.31640625,0.0390625,0.35546875,0.42578125},
            {0.6328125,0.65234375,0.6875,0.70703125,0.6796875}
        }
    }
    ,
    {
        {
            {0.00390625,-0.0078125,-0.01953125,0.0,0.02734375},
            {-0.0078125,0.00390625,-0.00390625,0.0,-0.01171875},
            {-0.00390625,-0.00390625,0.0,0.0,-0.01171875},
            {0.00390625,0.0,0.0,-0.00390625,0.015625},
            {0.0,0.0,0.0,-0.00390625,-0.01171875}
        }
    }
};


multi_test3_tb.cpp を示す。

// multi_test3_tb.h
// 2018/01/30 by marsee
//

#include "multi_test3.h"

int multi_test3(ap_ufixed_in in[25], ap_fixed_add &out);

int main(void){
    ap_ufixed_in in[25];
    ap_fixed_add out;
    ap_ufixed_in v = 0.5;

    for(int i=0; i<25; i=i++){
        in[i] = (ap_ufixed_in)v;
        v += (ap_ufixed_in)0.00390625;
        printf("in[%d] = %f\n", i, (float)v);
    }

    multi_test3(in, out);

    printf("out = %f\n", (float)out);

    return(0);
}


C シミュレーションを行った。結果を示す。
multi_test_49_180203.png

C コードの合成を行った。結果を示す。
multi_test_50_180203.png

Latency は 7 クロックだった。Interval は 1 で 1 クロックごとに次のデータを入れることができる。
リソース使用量は、BRAM_18K が 0 個、DSP48E も 0 個で、演算を LUT にマップできていることが分かった。FF は 1,286 個、LUT は 2,106 個使用している。うまく行っている。

C/RTL 協調シミュレーションを行った。
multi_test_51_180203.png

Latency は 7 クロックだった。

C/RTL 協調シミュレーションの波形を示す。
multi_test_52_180203.png

畳み込み演算器がデータを受け取ってから、演算を行い、出力の値をその先の回路が受け取るまでに 7 クロックだった。

Export RTL を行った。結果を示す。
なお、Vivado synthesis, place and route にチェックを入れてある。
multi_test_53_180203.png

LUT 使用数は 852 個だった。でもSRL の 36 もLUTとしての数に含めるべきかもしれない?
そうすると、852 + 36 = 888 個だった。
  1. 2018年02月03日 05:44 |
  2. Vivado HLS
  3. | トラックバック:0
  4. | コメント:0

Vivado HLS 2017.4 で片方が定数の場合の乗算の検討5(畳み込み演算2)

”Vivado HLS 2017.4 で片方が定数の場合の乗算の検討4(畳み込み演算1)”の続き。

前回は、乗算記号の * を使用して、畳み込みニューラルネットワークの畳み込み演算の重みを定数と置いたときの乗算を検討した。今回は、同様に演算をするのだが、途中の演算の小数点以下の精度を下げてみようと思う。

multi_test2.cpp、multi_test2_tb.cpp はそのままで、multi_test2.h だけ変更した。

typedef ap_fixed<9, 1, AP_TRN, AP_WRAP> ap_fixed_multi;


multi_test_42_180202.png

つまり、17 ビットだった乗算のビット幅を 9 ビットに変更した。減らした 8 ビットはすべて小数部のビット数となる。これで、飽和は関係なく、量子化モードだけが効くことになる。
これで C シミュレーションを行った。結果を示す。
multi_test_43_180202.png
出力は、out = 6.070313 となった。前回の結果が out = 6.113281 だったため、減ってしまっている。

C コードの合成を行った。結果を示す。
multi_test_44_180202.pngmulti_test_39_180131.png
左が今回の結果、右が前回の結果だ。
Latency が 8 クロックだったのが、6 クロックになっている。FF が 1305 個から 1193 個に減少した。 LUT は 2251 個から 2022 個に減少した。

C シミュレーションを行った。結果を示す。
multi_test_45_180202.png

C シミュレーションの波形を示す。
multi_test_46_180202.png

Export RTL を行った。その際に、Vivado synthesis, place and route にチェックを入れた。
結果を示す。
multi_test_47_180202.png

実際にVivado で論理合成、インプリメントしたときのリソース使用量は、だいぶ少なくなっている。FF は 1193 個だったのが、639 個に、LUT は 2022 個だったのが、853 個に減少した。
Final Timing を見ると、これでVivado にIP として持っていくとタイミングエラーが出そうだが、とりあえずの仮のIP 化なので、そのままとする。
  1. 2018年02月02日 05:22 |
  2. Vivado HLS
  3. | トラックバック:0
  4. | コメント:0