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

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

FPGAの部屋

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

「Vivado HLS で DMA Read IP を作る2(絶対アドレス指定版)」を使って合成後の機能シミュレーション3

「Vivado HLS で DMA Read IP を作る2(絶対アドレス指定版)」を使って合成後の機能シミュレーション2”の続き。

前回は、Vivado HLS 2016.4 で Verilog でIP をExport RTL して、Vivado 2016.4 では、Target language を VHDL にしたら、Post-Synthesis Functional Simulation が正常になった。ここでは、IO ピンが足りるようにVirtex7 の xc7vx980tffg1928-2 を使用していたが、IO ピンが足りないZYBO (xc7z010clg400-1)ではどうか?を確かめてみた。ikzwm さんがやってくれたので、大丈夫とは思うが自分でも確かめてみる。

まずは、Vivado HLS 2016.4 で、”Vivado HLS で DMA Read IP を作る2(絶対アドレス指定版)”のソースコードで、xc7z010clg400-1 をターゲットとして、Verilog でExport RTL を行った。
DMA_Read_IP_29_170319.png

そのVivado HLS2016.4 のDMA Read IPを使用して、Project part を xc7z010clg400-1 に変更し、Project Settings のTarget language を VHDL にした Vivado 2016.4 プロジェクトを作った。
DMA_Read_IP_30_170319.png

論理合成を行った。IO ピンはオーバーフローになっている。
DMA_Read_IP_31_170319.png

Flow Navigator の Simulation -> Run Simulation -> Run Post-Synthesis Functional Simulation を選択して、論理合成後の機能シミュレーションを行った。
DMA_Read_IP_32_170319.png
問題なく波形が出ている。

次に、念のため、Flow Navigator の Simulation -> Run Simulation -> Run Behavioral Simulation を選択して、論理シミュレーションを行った。
DMA_Read_IP_33_170319.png
こっちも問題なく波形が出ている。

よって、ZYBO (xc7z010clg400-1)でも問題なく波形が出ている。
論理合成で IO ピンがオーバーフローでも Post-Synthesis Functional Simulation には影響ないことが分かった。
  1. 2017年03月19日 06:22 |
  2. Vivado HLS
  3. | トラックバック:0
  4. | コメント:0

「Vivado HLS で DMA Read IP を作る2(絶対アドレス指定版)」を使って合成後の機能シミュレーション2

「Vivado HLS で DMA Read IP を作る2(絶対アドレス指定版)」を使って合成後の機能シミュレーション”の続き。

ikwzm さんにVivado HLS のExport RTL のEvaluate Generated RTL をVHDL にしたら論理合成後の機能シミュレーションも動いたということでやってみたのだが、やはり結果は同様に動作していなかった。

Vivado RTL Synthesis のチェックを外して、Evaluate Generated RTL をVerilog でIP 化してやってみても同じだった。もう一度、Vivado RTL Synthesis のチェックを外して、Evaluate Generated RTL をVHDL でIP 化しても同様にダメだった。
DMA_Read_IP_24_170316.png

ikwzm さんからもう一度、教えてもらったところ、「Vivado-HLS の Export RTL as IP は Verilog かつ、Vivado の Target Language を VHDL にした場合」とのことだった。
もう一度、Vivado HLS 2016.4 で Evaluate Generated RTLVerilog に設定して、Export RTL を行った。
Vivado RTL Synthesis のチェックは外してあるが、IP になった後のファイルを見てみたところ、特に合成結果が入っているようには見えなかったので、やってみるだけなのだと思う。
DMA_Read_IP_25_170316.png

Vivado 2016.4 で DMA Read IP をリプレースして、Project Settings のTarget language VHDL にした。
DMA_Read_IP_26_170316.png

これで、論理合成(Run Synthesis)を行ってから、Flow Navigator の Simulation -> Run Simulation -> Run Post-Synthesis Functional Simulation を選択して、論理合成後の機能シミュレーションを行った。
やった~。波形が出た。。。
DMA_Read_IP_27_170316.png

DMA_Read_IP_28_170316.png

何でだろう?これで何で波形が出るの?
ともかくよかった。これはXilinx社にバグレポートしないと。。。

論理シミュレーションも問題なく波形が表示されている。。。
  1. 2017年03月18日 05:15 |
  2. Vivado HLS
  3. | トラックバック:0
  4. | コメント:0

「Vivado HLS で DMA Read IP を作る2(絶対アドレス指定版)」を使って合成後の機能シミュレーション

Vivado HLS で DMA Read IP を作る2(絶対アドレス指定版)”の続き。

前回は絶対アドレス指定のDMA Read IPをVivado HLS 2016.4 で作成した。今回は、そのDMA Read IPをVivado で論理シミュレーションと合成後の機能シミュレーションを行った。

前回やったときの記事は、”DMA Read IP を単体でシミュレーション3(DMA Read IP単体で論理合成後にシミュレーション)

このプロジェクトを使用した。
DMA_Read_IP_9_170316.png

ただし新しく生成した DMA Read IPに入れ替えてある。それに、DMA Read IPのレジスタ設定を行う reg_write_read IP が一度設定を終了しても、また設定を繰り返し行っていたので、修正を行った。上に示す図は論理合成が終了している。
論理合成後のレポートを示す。
DMA_Read_IP_10_170316.png

IOポートはすべて割り振られている。これで論理合成後の機能シミュレーションは問題ない。しかし、IOがオーバーフローしていても論理合成後の機能シミュレーションがうまく行くのかもしれない?確実に動作する回路で試していないので、よくわからない?

ブロックデザインを示す。
DMA_Read_IP_11_170316.png

DMA Read IPとAXI Interconnect 2つだけのシンプルな構成だ。

Address Editor を示す。
DMA_Read_IP_12_170316.png

テストベンチとして、DMA Read IPのレジスタを設定する reg_write_read IP と AXI4 Slave BFM をメモリとして接続している。そのブロック図を下に示す。
DMA_Read_IP_13_170316.png

さて次に、論理シミュレーションを行う。
Flow Navigator の Simulation -> Run Simulation -> Run Behavioral Simulation を選択する。
DMA_Read_IP_14_170316.png

論理シミュレーション結果の全体波形を示す。
DMA_Read_IP_15_170316.png
波形1

DMA_Read_IP_17_170316.png
波形2

波形の数が多いので、2つの画像になってしまった。最初の画像は主にDMA Read IPのAXI4 Master Read アクセスが表示されている。2つ目の波形には、DMA Read IPのレジスタを設定するAXI4-Lite Slave アクセスとAXI4-Stream 出力が表示されている。

最初の波形を拡大してみよう。
DMA_Read_IP_16_170316.png
波形3

バーストに1クロックの Wait はあるがほとんどフルバーストでAXI4 Master Read が行われている。

次に、DMA Read IPを設定するのレジスタを設定するAXI4-Lite Slave アクセスを下に示す。
DMA_Read_IP_18_170316.png
波形4

まずは、DMA Read IPのレジスタマップを示す。

//------------------------Address Info-------------------
// 0x00 : Control signals
//        bit 0  - ap_start (Read/Write/COH)
//        bit 1  - ap_done (Read/COR)
//        bit 2  - ap_idle (Read)
//        bit 3  - ap_ready (Read)
//        bit 7  - auto_restart (Read/Write)
//        others - reserved
// 0x04 : Global Interrupt Enable Register
//        bit 0  - Global Interrupt Enable (Read/Write)
//        others - reserved
// 0x08 : IP Interrupt Enable Register (Read/Write)
//        bit 0  - Channel 0 (ap_done)
//        bit 1  - Channel 1 (ap_ready)
//        others - reserved
// 0x0c : IP Interrupt Status Register (Read/TOW)
//        bit 0  - Channel 0 (ap_done)
//        bit 1  - Channel 1 (ap_ready)
//        others - reserved
// 0x10 : Data signal of ap_return
//        bit 31~0 - ap_return[31:0] (Read)
// 0x18 : Data signal of frame_buffer0
//        bit 31~0 - frame_buffer0[31:0] (Read/Write)
// 0x1c : reserved
// 0x20 : Data signal of frame_buffer1
//        bit 31~0 - frame_buffer1[31:0] (Read/Write)
// 0x24 : reserved
// 0x28 : Data signal of frame_buffer2
//        bit 31~0 - frame_buffer2[31:0] (Read/Write)
// 0x2c : reserved
// 0x30 : Data signal of mode_V
//        bit 0  - mode_V[0] (Read/Write)
//        others - reserved
// 0x34 : reserved
// (SC = Self Clear, COR = Clear on Read, TOW = Toggle on Write, COH = Clear on Handshake)


レジスタを設定する reg_write_read IP の設定を示す。

// reg_write_read.h
// 2016/06/10 by marsee
//
// reg_addr_data フォーマット、
// 第1フィールド(reg_ad[x][0]):Write - 0, Read - 1
// 第2フィールド(reg_ad[x][1]):Delay、単位はクロック数
// 第3フィールド(reg_ad[x][2]):アドレス、16進数
// 第4フィールド(reg_ad[x][3]):データ、16進数
//
// 終了は第2フィールド:Delayに 0xffffffff が書いてあったとき

#define AD_ARRAY_LIMIT 256
#define REG_WRITE 0
#define REG_READ 1

#define R_W_FIELD 0
#define DELAY_FIELD 1
#define ADDRESS_FIELD 2
#define DATA_FIELD 3

const unsigned int reg_ad[AD_ARRAY_LIMIT][4]={
        {000x44A00018, 0x10000000},
        {000x44A00020, 0x10000000},
        {000x44A00028, 0x10000000},
        {000x44A00030, 0},
        {100x44A00000, 0},
        {000x44A00000, 1},
        {00xfffffffe, 00},
        {00xffffffff, 00},


つまり、0x44A00018、0x44A00020、0x44A00028 に 0x10000000 を書いているが、3つのフレームバッファのアドレスを書いている。
0x44A00030 でDMA Read IPのモードを書いている。 0 なので、DMA_WRITE_MODE だ。
0x44A00000 をRead してから、0x44A00000 に 1 を書いてDMA Read IPをスタートさせている。

DMA Read IPのAXI4-Stream 出力の波形を示す。
DMA_Read_IP_19_170316.png
波形5

前に示した全体波形では、outs_tlast が時々 1 変化していたのが見えたと思うが、画像フレームのスタート時には、outs_tuser が 1 クロック間だけ 1 となっているのがわかる。
と言う訳で完全に動作しているようだ。

次に、論理合成後の機能シミュレーションを行う。
Flow Navigator の Simulation -> Run Simulation -> Run Post-Synthesis Functional Simulation を選択する。

Post-Synthesis Functional Simulation での全体波形を示す。
DMA_Read_IP_21_170316.png
波形6

DMA_Read_IP_22_170316.png
波形7

やはり、Post-Synthesis Functional Simulation で波形が出てこない。

DMA Read IPのレジスタを設定するAXI4-Lite Slave アクセスを拡大してみよう。
DMA_Read_IP_23_170316.png
波形8

こちらは問題ないようだ。
  1. 2017年03月17日 05:32 |
  2. Vivado HLS
  3. | トラックバック:0
  4. | コメント:0

Vivado HLS で DMA Read IP を作る2(絶対アドレス指定版)

Vivado HLS で DMA Read IP を作る(絶対アドレス指定版)”の続き。

Vivado HLS で DMA Read IP を作る(絶対アドレス指定版)”では、DMA Read IPを作成したが、”Vivado HLSで作ったDMA Read IP を実機でテスト1(動作しない)”で実機で動作を確認しても動作しなかった。
DMA Read IP を単体でシミュレーション3(DMA Read IP単体で論理合成後にシミュレーション)”では、DMA Read IPを単体でシミュレーションしたが、論理シミュレーションはそれらしく動いても Post-Synthesis Fuctional Simulation では、動作しないという問題があった。これは、IOがオーバーフローしているからかもしれないということで、Vivado 2016.4 でテストしてすることにした。

DMA_Read_Addr_Virtex を示す。シミュレーション用のVivado 2016.4 プロジェクトを論理合成したときに、IOがオーバーフローしないように、Virtex7 の xc7vx980tffg1928-2 を使用している。
DMA_Read_IP_1_170316.png

なお、”Vivado HLS で DMA Read IP を作る(絶対アドレス指定版)”では、3フレームを一度に処理していたのだが、今回は、1フレーム分の処理に変更した。

C シミュレーションを行った。
DMA_Read_IP_2_170316.png

dma_result0.bmp を見ると正常に「A」の文字が見える。

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

Latency は 3083 クロックで、64 ピクセル x 48 行の「A」という画像の総ピクセル値 3072 から 11 クロックしか離れていないので、ほぼ 1 クロックで 1 ピクセルを処理することができている。

C/RTL協調シミュレーションを行ったところ、エラーになってしまった。
DMA_Read_IP_4_170316.png

「ERROR: [COSIM 212-4] *** C/RTL co-simulation finished: FAIL ***」を調べると、”AR# 61063 Vivado HLS 2014.2 : C/RTL 協調シミュレーションに関する問題を調査するためのデバッグ ガイド”が見つかった。そこに”Vivado HLS: Debug Guide for investigating C/RTL co-simulation issues”のリンクがあった。Vivado HLS: Debug Guide for investigating C/RTL co-simulation issuesを見ても原因はよくわからない?

IP 化を行った。
Vivado RTL Synthesis にチェックを入れた。
DMA_Read_IP_5_170316.png

結果を示す。
DMA_Read_IP_6_170316.png

Resource Usage のLUT が合成結果(1269 ) の半分程度の 695 になっている。ロジックが消されている恐れがある。

今までは、テスト用の64 ピクセル x 48 行の「A」という画像でやっていたので、800 ピクセル x 600 行の実際に処理する画像用に値を切り替えた。
もう一度、C コードの合成を行った。
DMA_Read_IP_7_170316.png

IP 化を行った。やはり LUT は合成時の約半分になっている。
DMA_Read_IP_8_170316.png

DMA_Read.h を示す。

// DMA_Read.h
// 2016/07/14 by marsee
// 2016/09/18 : BURST_LENGTH を追加
//

#ifndef __DMA_READ_H__
#define __DMA_READ_H__

#define HORIZONTAL_PIXEL_WIDTH    800
#define VERTICAL_PIXEL_WIDTH    600

//#define HORIZONTAL_PIXEL_WIDTH    64
//#define VERTICAL_PIXEL_WIDTH    48

#define ALL_PIXEL_VALUE    (HORIZONTAL_PIXEL_WIDTH*VERTICAL_PIXEL_WIDTH)

#define MAX_FRAME_NUMBER    3

#define DMA_WRITE_MODE    0
#define FREE_RUN_MODE    1

#define MEMCPY_LENGTH    (HORIZONTAL_PIXEL_WIDTH*4)

#endif


DMA_Read_addr.cpp を示す。

// DMA_Read_addr.cpp
// 2016/07/13 by marsee
//
// frame_buffer0, frame_buffer1, frame_buffer2 には3つのフレームバッファのアドレスを入れる
// mode = 0 : DMA Write IP の active_frame を見て、その1つ前のフレームをDMA Readするモード(DMA_WRITE_MODE)
// mode = 1 : フリーラン モード(FREE_RUN_MODE)
//
// 2017/03/15 : 1フレーム分のDMAに変更
//

#include <stdio.h>
#include <string.h>
#include <ap_int.h>
#include <hls_stream.h>
#include <ap_axi_sdata.h>

#include "DMA_Read.h"

int DMA_Read_addr(volatile int *in, hls::stream<ap_axis<32,1,1,1> >& outs,
        unsigned int frame_buffer0, unsigned int frame_buffer1,
        unsigned int frame_buffer2, ap_uint<2> & active_frame,
        ap_uint<1> mode){
#pragma HLS INTERFACE s_axilite port=mode
#pragma HLS INTERFACE ap_none register port=active_frame
#pragma HLS INTERFACE s_axilite port=frame_buffer0
#pragma HLS INTERFACE s_axilite port=frame_buffer1
#pragma HLS INTERFACE s_axilite port=frame_buffer2
#pragma HLS INTERFACE m_axi depth=3072 port=in offset=off
#pragma HLS INTERFACE axis port=outs
#pragma HLS INTERFACE s_axilite port=return

    ap_axis<32,1,1,1> pix;
    int dma_index;
    static int n = 0;

    if (mode == DMA_WRITE_MODE){
        n = (int)active_frame;
    }else{
        n++;
        if (n > 2)
            n = 0;
    }

    switch (n){ // 1つ前のフレームバッファを読みだす
        case 0 :
            dma_index = frame_buffer2/sizeof(int);
            break;
        case 1 :
            dma_index = frame_buffer0/sizeof(int);
            break;
        case 2 :
            dma_index = frame_buffer1/sizeof(int);
            break;
        default :
            dma_index = frame_buffer0/sizeof(int);
            break;
    }

    for (int y=0; y<VERTICAL_PIXEL_WIDTH; y++){
        for (int x=0; x<HORIZONTAL_PIXEL_WIDTH; x++){
#pragma HLS PIPELINE II=1
            pix.data = in[dma_index+(y*HORIZONTAL_PIXEL_WIDTH)+x];

            if (y==0 && x==0)
                pix.user = 1;
            else
                pix.user = 0;

            if (x == (HORIZONTAL_PIXEL_WIDTH-1))
                pix.last = 1;
            else
                pix.last = 0;

            outs << pix;
        }
    }

    return 0;
}


DMA_Read_addr_tb.cpp を示す。

// DMA_Read_addr_tb.cpp
// 2016/07/15 by marsee
// 2017/03/16 : 3フレーム処理から1フレーム処理に変更
//

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <ap_int.h>
#include <hls_stream.h>
#include <iostream>
#include <fstream>
#include <ap_axi_sdata.h>

#include "DMA_Read.h"
#include "bmp_header.h"

int DMA_Read_addr(volatile int *in, hls::stream<ap_axis<32,1,1,1> >& outs,
        unsigned int frame_buffer0, unsigned int frame_buffer1,
        unsigned int frame_buffer2,  ap_uint<2> & active_frame,
        ap_uint<1> mode);

int main()
{
    using namespace std;

    hls::stream<ap_axis<32,1,1,1> > outs_dummy;
    hls::stream<ap_axis<32,1,1,1> > outs;
    ap_axis<32,1,1,1> pix;
    ap_axis<32,1,1,1> vals, vals_dummy;

    BITMAPFILEHEADER bmpfhr; // BMPファイルのファイルヘッダ(for Read)
    BITMAPINFOHEADER bmpihr; // BMPファイルのINFOヘッダ(for Read)
    FILE *fbmpr, *fbmpw;
    int *rd_bmp, *hw_lapd;
    int blue, green, red;
    ap_uint<2> active_frame = 0;
    int *frame_buffer;

    if ((fbmpr = fopen("test.bmp""rb")) == NULL){ // test.bmp をオープン
    //if ((fbmpr = fopen("road_1.bmp", "rb")) == NULL){ // test.bmp をオープン
        fprintf(stderr, "Can't open test.bmp by binary read mode\n");
        exit(1);
    }
    // bmpヘッダの読み出し
    fread(&bmpfhr.bfType, sizeof(char), 2, fbmpr);
    fread(&bmpfhr.bfSize, sizeof(long), 1, fbmpr);
    fread(&bmpfhr.bfReserved1, sizeof(short), 1, fbmpr);
    fread(&bmpfhr.bfReserved2, sizeof(short), 1, fbmpr);
    fread(&bmpfhr.bfOffBits, sizeof(long), 1, fbmpr);
    fread(&bmpihr, sizeof(BITMAPINFOHEADER), 1, fbmpr);

    // ピクセルを入れるメモリをアロケートする
    if ((rd_bmp =(int *)malloc(sizeof(int) * (bmpihr.biWidth * bmpihr.biHeight))) == NULL){
        fprintf(stderr, "Can't allocate rd_bmp memory\n");
        exit(1);
    }

    int *buf;
    if ((buf =(int *)malloc(3 * sizeof(int) * (bmpihr.biWidth * bmpihr.biHeight))) == NULL){
        fprintf(stderr, "Can't allocate buf memory\n");
        exit(1);
    }

    // rd_bmp にBMPのピクセルを代入。その際に、行を逆転する必要がある
    for (int y=0; y<bmpihr.biHeight; y++){
        for (int x=0; x<bmpihr.biWidth; x++){
            blue = fgetc(fbmpr);
            green = fgetc(fbmpr);
            red = fgetc(fbmpr);
            rd_bmp[((bmpihr.biHeight-1)-y)*bmpihr.biWidth+x] = (blue & 0xff) | ((green & 0xff)<<8) | ((red & 0xff)<<16);
        }
    }
    fclose(fbmpr);

    // frame buffer をアロケートする、3倍の領域を取ってそれを3つに分ける
    if ((frame_buffer =(int *)malloc(MAX_FRAME_NUMBER * sizeof(int) * (bmpihr.biWidth * bmpihr.biHeight))) == NULL){
        fprintf(stderr, "Can't allocate frame_buffer0 ~ 2\n");
        exit(1);
    }

    // 3 つのフレームバッファにそれぞれ'A' を入力する(1つに変更)
    memcpy(frame_buffer, rd_bmp, bmpihr.biHeight * bmpihr.biWidth * sizeof(int));

    memcpy((int *)((unsigned int)frame_buffer + bmpihr.biHeight * bmpihr.biWidth * sizeof(int)),
        rd_bmp, bmpihr.biHeight * bmpihr.biWidth * sizeof(int));

    memcpy((int *)((unsigned int)frame_buffer + 2 * bmpihr.biHeight * bmpihr.biWidth * sizeof(int)),
        rd_bmp, bmpihr.biHeight * bmpihr.biWidth * sizeof(int));

    DMA_Read_addr((volatile int *)0, outs_dummy, (unsigned int)frame_buffer,
        (unsigned int)frame_buffer+(bmpihr.biWidth * bmpihr.biHeight * sizeof(int)),
        (unsigned int)frame_buffer+(2 * (bmpihr.biWidth * bmpihr.biHeight) * sizeof(int)),
        active_frame, DMA_WRITE_MODE);

    DMA_Read_addr((volatile int *)0, outs, (unsigned int)frame_buffer,
        (unsigned int)frame_buffer+(bmpihr.biWidth * bmpihr.biHeight * sizeof(int)),
        (unsigned int)frame_buffer+(2 * (bmpihr.biWidth * bmpihr.biHeight) * sizeof(int)),
        active_frame, FREE_RUN_MODE);

    // outs ストリームのデータを buf に入力する
    //for (int k=0; k<3; k++){
        int k = 0;
        for(int j=0; j < bmpihr.biHeight; j++){
            for(int i=0; i < bmpihr.biWidth; i++){
                outs >> vals;
                outs_dummy >> vals_dummy;
                ap_int<32> val = vals.data;
                buf[(k*bmpihr.biWidth*bmpihr.biHeight)+(j*bmpihr.biWidth)+i] = (int)val;
            }
        }
    //}

    // DMAされたデータをBMPフィルに書き込む
    char output_file[] = "dma_result0.bmp";
    //for (int i=0; i<MAX_FRAME_NUMBER; i++){
        int i=0;
        switch (i){
            case 0:
                strcpy(output_file,"dma_result0.bmp");
                break;
            case 1:
                strcpy(output_file,"dma_result1.bmp");
                break;
            case 2:
                strcpy(output_file,"dma_result2.bmp");
                break;
        }
        if ((fbmpw=fopen(output_file, "wb")) == NULL){
            fprintf(stderr, "Can't open %s by binary write mode\n", output_file);
            exit(1);
        }
        // BMPファイルヘッダの書き込み
        fwrite(&bmpfhr.bfType, sizeof(char), 2, fbmpw);
        fwrite(&bmpfhr.bfSize, sizeof(long), 1, fbmpw);
        fwrite(&bmpfhr.bfReserved1, sizeof(short), 1, fbmpw);
        fwrite(&bmpfhr.bfReserved2, sizeof(short), 1, fbmpw);
        fwrite(&bmpfhr.bfOffBits, sizeof(long), 1, fbmpw);
        fwrite(&bmpihr, sizeof(BITMAPINFOHEADER), 1, fbmpw);

        // RGB データの書き込み、逆順にする
        int offset = i * bmpihr.biWidth * bmpihr.biHeight;
        for (int y=0; y<bmpihr.biHeight; y++){
            for (int x=0; x<bmpihr.biWidth; x++){
                blue = buf[offset+((bmpihr.biHeight-1)-y)*bmpihr.biWidth+x] & 0xff;
                green = (buf[offset+((bmpihr.biHeight-1)-y)*bmpihr.biWidth+x] >> 8) & 0xff;
                red = (buf[offset+((bmpihr.biHeight-1)-y)*bmpihr.biWidth+x]>>16) & 0xff;

                fputc(blue, fbmpw);
                fputc(green, fbmpw);
                fputc(red, fbmpw);
            }
        }
        fclose(fbmpw);
    //}
    free(rd_bmp);
    free(frame_buffer);
    return 0;
}

  1. 2017年03月16日 05:17 |
  2. Vivado HLS
  3. | トラックバック:0
  4. | コメント:0

Vivado HLS 2016.4 でUNROLL指示子を試してみた

Vivado HLS 2016.4 でUNROLL指示子を試してみた。

UNROLL指示子については、Vivado HLS のユーザーズガイド、”高位合成 UG902 (v2016.4) 2016 年 11 月 30 日”の 133 ページの”最適なループ展開によるパイ プ ラ イ ンの改善”を参考にした。

まずは、134 ページの”図 1‐60: ループの展開”がUNROLL指示子の説明の図となっている。その図を引用する。引用した図にわかりやすいように軸を付け加えさせて頂いた。
unroll_test_1_170218.png

ラプラシアンフィルタの実装による UNROLL 指示子の効果について調べてみよう。まずは、すべての要素を足し算するだけの簡単な 3 x 3 のフィルタを AXI4-Stream で実装した。その unroll_test.cpp を示す。

// unroll_test.cpp
// 2017/02/17 by marsee
//

#include <hls_stream.h>

#define HORIZONTAL_PIXEL_WIDTH 5
#define VERTICAL_PIXEL_WIDTH 5

int unroll_test(hls::stream<int>& ins, hls::stream<int>& outs){
#pragma HLS INTERFACE s_axilite port=return
#pragma HLS INTERFACE axis register both port=outs
#pragma HLS INTERFACE axis register both port=ins
    int pix;
    int usm;

    int line_buf[2][HORIZONTAL_PIXEL_WIDTH];
#pragma HLS array_partition variable=line_buf block factor=2 dim=1
#pragma HLS resource variable=line_buf core=RAM_2P

    int pix_mat[3][3];
#pragma HLS array_partition variable=pix_mat complete

    Loop_y : for (int y=0; y<VERTICAL_PIXEL_WIDTH; y++){
        Loop_x : for (int x=0; x<HORIZONTAL_PIXEL_WIDTH; x++){
//#pragma HLS PIPELINE II=1
            ins >> pix;

            Loop_i : for (int i=0; i<3; i++){
//#pragma HLS UNROLL factor=3
                Loop_j : for (int j=0; j<2; j++){
//#pragma HLS UNROLL factor=2
                    pix_mat[i][j] = pix_mat[i][j+1];
                }
            }
            pix_mat[0][2] = line_buf[0][x];
            pix_mat[1][2] = line_buf[1][x];

            pix_mat[2][2] = pix;

            line_buf[0][x] = line_buf[1][x];    // 行の入れ替え
            line_buf[1][x] = pix;
        }
        usm = pix_mat[0][0] + pix_mat[0][1] + pix_mat[0][2]
            + pix_mat[1][0] + pix_mat[1][1] + pix_mat[1][2]
            + pix_mat[2][0] + pix_mat[2][1] + pix_mat[2][2];

        outs << usm;
    }
    return(0);
}


Vivado HLS 2016.4 の unroll_test プロジェクトを示す。
unroll_test_2_170218.png

合成結果を示す(図A)。
unroll_test_3_170218.png

Latency が 416 クロックかかっている。内訳はLoop に示されている。Loop_y, Loop_x, Loop_i, Loop_j が表示されていて、UNROLL されいていないのがわかる。

次に、Loop_j の「#pragma HLS UNROLL factor=2」を生かした。
どうも、Vivado HLS 2016.4 では、factor を書かないとまずいようだ。ディレクティブ・エディタで修正できない。不正だと言われてしまう。
unroll_test_6_170218.png

合成結果を示す(図B)。
unroll_test_7_170218.png

UNROLL指示子を全く入れていない時(図A)に比べてLatency が 416 クロックのところ、191 クロックに縮小した。Loop を見ると Loop_j が展開されて無くなっている。

次に、Loop_i の「#pragma HLS UNROLL factor=3」を生かした。
unroll_test_8_170218.png

合成結果を示す(図C)。
unroll_test_9_170218.png

Loop_j も無くなって、Latency が図B の 191 クロックから 66 クロックに縮小した。Loop を見ると、Loop_j も無くなっている。

Loop_x にPIPELINE 指示子の「#pragma HLS PIPELINE II=1」を入れた。
unroll_test_10_170218.png

合成結果を示す(図D)。
unroll_test_11_170218.png

Latency が 29 クロックに縮小した。Loop を見ても Loop_y_Loop_x になっている。

最後に、Loop_j と Loop_i の UNROLL 指示子をコメントアウトした。
unroll_test_12_170218.png

合成結果を示す(図E)
unroll_test_13_170218.png

図D と同じになった。

つまり、この状況では、PIPELINE 指示子を入れれば下の for ループが展開されるようだ。つまり、PIPELINE 指示子の下にはUNROLL指示子は要らないということになる。
  1. 2017年02月18日 15:20 |
  2. Vivado HLS
  3. | トラックバック:0
  4. | コメント:0

Vivado HLS 2016.4 における assert() 文の効果5(AXI4-Stream版での比較)

Vivado HLS 2016.4 における assert() 文の効果4(自分定義した固定小数点)”の続き。

前回は、アンシャープマスキング・フィルタ単体では、任意精度固定小数点型の方が自分で定義した固定小数点型に比べてリソース使用量が少なくなったという結果だったが、AXI4-Stream インターフェースを被せた状態ではどうなるか?をやってみた。

まずは、変数の変域を指定するために、pow() を使用して、定義値からの生成を行うようにコードを変更した。
それを利用してassert() を書いた。
まずは、任意精度固定小数点型を試してみた。ピンクの枠で示した assert() を追加した。
assert_35_170216.png

C コードの合成結果を示す。
assert_36_170216.png

Analysis 結果を示す。
assert_37_170216.png

37ステートだった。

Analysis 結果で、unsharp_masking() の使用リソースとステート見てみよう。
右上のModule Hierarchy で unsharp_masking をクリックした。
assert_38_170216.png

unsharp_masking() の使用リソースは、FF が 1313 個、LUT が 1331 個だそうだ。ステートは 31 ステートだった。

次に、assert() 文をコメントアウトしてみた。
合成結果を示す。
assert_39_170216.png

LUT が 2244 個から、2262 個に増えていた。FF も 1995 個から 2021 個に増えていた。Latency は同じだった。

Analysis 結果を示す。
assert_40_170216.png

ステートは 38 ステートで変更はない。

Analysis 結果で、unsharp_masking() の使用リソースとステートを見た。
assert_41_170216.png

31ステートで変化はない。FF が 1331 個、LUT が 1357 個だった。assert() が入っているときは、FF が 1313 個、LUT が 1331 個なので、明らかに assert() が無いほうが増えている。

次に、自分で定義した固定小数点型をやってやってみよう。このようにassert() が入っている。
assert_42_170216.png

合成結果を示す。
assert_43_170216.png

FF が 1986 個 、LUT が 1895 個だった。任意精度固定小数点型では、FF が 2244 個、LUT が 1995 なので、明らかに自分で定義した固定小数点型の方がリソース使用量が少ない。単体でテストしたのとは逆の結果になった。
Latency も 3104 クロックに対して、任意精度固定小数点型では 3108 クロックとなっている。

Analysis 結果を示す。
assert_44_170216.png

ステートも 33 ステートだった。こちらも任意精度固定小数点型では、37 ステートだったので、自分で定義した固定小数点型のほうがステートが少ない。

Analysis 結果で、unsharp_masking() の使用リソースとステートを見た。
assert_45_170216.png

FF は 1083 個、LUT は 1245 個だった。任意精度固定小数点型ではFF が 1313 個、LUT が 1331 個だった。

次に、自分で定義した固定小数点型で、assert() をすべてコメントアウトした。
assert_46_170217.png

合成結果を示す。
assert_47_170217.png

FF 、LUT 共に、assert() を入れてあるときと変化が無かった。assert() は効いていない。

AXI4-Stream インターフェースを被せた状態でアンシャープマスキング・フィルタの任意精度固定小数点型と自分で定義した固定小数点型はどっちが使用量が少ないか比べてみたが、自分で定義した固定小数点型の方が少ないという結果になった。これは、アンシャープマスキング・フィルタ単体とは逆の結果だ。

前回は、自分で定義した固定小数点型の方がリソース使用量が少ないという結果になって、自分で定義した固定小数点型を使おうという話になったが、assert() でリソース使用量を減らすことができるし、演算の間違いも少なくなるので、積極的に任意精度固定小数点型を使っていこうと思う。
  1. 2017年02月17日 04:28 |
  2. Vivado HLS
  3. | トラックバック:0
  4. | コメント:0

Vivado HLS 2016.4 における assert() 文の効果4(自分で定義した固定小数点)

Vivado HLS 2016.4 における assert() 文の効果3”の続き。

これまでは、任意精度固定小数点型で assert() 文で変数の変域を指定するリソース使用量の低減効果を見てきたが、今回は、任意精度固定小数点型を使用しない自分で定義した固定小数点演算との比較をしてみた。

最初にC ソースコードを示す。これは、int 型を使用して、PRECISION の 6 ビット左シフトを行って小数桁を確保している。最後には 6 ビット右シフトして整数に戻す。

// unsharp_mask_axis.cpp
// 2015/09/24 by marsee
// assertテスト用

#include <stdio.h>
#include <string.h>
#include <ap_int.h>
#include <hls_stream.h>
#include <ap_axi_sdata.h>

#include "unsharp_mask_axis.h"

// アンシャープマスキング・フィルタ
// x0y0 x1y0 x2y0 -k   -j  -k
// x0y1 x1y1 x2y1 -k  9+8k -k x 1/9
// x0y2 x1y2 x2y2 -k   -k  -k
//
// k : 鮮鋭化の強さ(固定小数点) , k != 0
// num_adec_k : Kの小数点の位置
// 2015/09/27 : 演算の小数部は num_adec_k*2 ビットとする。
//

#define PRECISION    6    // 小数点以下の桁数、精度(1以上)

int unsharp_masking(int pix_mat[3][3], int k, int num_adec_k)
{
    int y;
    int xy[3][3];
    int result=0;
    int z;

    int x1y1 = (9<<(PRECISION+num_adec_k))/k + (8<<PRECISION);

    for (int i=0; i<=16; i += 8){
        for (int j=0; j<3; j++){
            for (int k=0; k<3; k++){
                xy[j][k] = (pix_mat[j][k] >> i) & 0xff; // RGBのいずれかを抽出
            }
        }

        y = -(xy[0][0]<<PRECISION) -(xy[0][1]<<PRECISION) -(xy[0][2]<<PRECISION)
            -(xy[1][0]<<PRECISION) +x1y1*xy[1][1]         -(xy[1][2]<<PRECISION)
            -(xy[2][0]<<PRECISION) -(xy[2][1]<<PRECISION) -(xy[2][2]<<PRECISION);

        y = ((k * y)/9) >> num_adec_k; // k は num_adc_k だけ左シフトされているので戻す

        z = y + (1<<(PRECISION-1)); // 四捨五入 +0.5
        z = z >> PRECISION; // 小数点以下切り捨て

        if (z<0// 飽和演算
            z = 0;
        else if (z>255)
            z = 255;

        result += z<<i; // i=0 : blue, i=8 : green, i=16 : red
    }

    return(result);
}


プロジェクトを示す。
assert_26_170215.png

C コードの合成結果を示す。
assert_27_170215.png

任意精度固定小数点型で実装したときの assert() 無しに比べて、int 型を使用してシフトで小数を表した時のほうがリソース使用量が多い。それにLatency も長い。

Analysis 結果を示す。
assert_28_170215.png

こちらも、58 ステートで任意精度固定小数点型の38 ステートよりも多い。

次に assert.h をインクルードして、適当な assert() を入れてみた。
assert_29_170215.png

C コードlの合成を行った。
assert_30_170215.png

ものすごくリソース使用量が減った。やはり、assert() が効いているようだ。

Analysis 結果を示す。
assert_31_170215.png

4 ステートになってしまった。

最後に、まともに変域を考えて指定した。
assert_32_170215.png

C コードlの合成を行った。
assert_33_170215.png

元の合成結果と比べて、1353 個が 1291 個に減った。

Analysis 結果を示す。
assert_34_170215.png

58ステートになった。元と変化が無かった。

結果として、自分で定義した固定小数点演算をするよりも任意精度固定小数点型を使ったほうが、リソース使用量が少なかった。更に assert() を使うとリソース使用量が削減できるので、固定小数点を使うときは任意精度固定小数点型を使ったほうが良いと思う。
  1. 2017年02月15日 07:05 |
  2. Vivado HLS
  3. | トラックバック:0
  4. | コメント:0