• F-I-L
  • Wiki
  • Source
  • Contact
  • Interface

    Modified by 2015.05.11

    Interface in all IPCores in F-I-L include some similar and basal ports, and some extended ports. The basal ports, otherwise, the ports in each module, can support all functions for some modules, but for others they are not enuogh, in that time, the extended ports is needed. Moreover, because of the two different working mode in each module, two interface protocols are needed.


    Basal ports

    These port are designed as follows:

    1. clk: Synchronous clock.
    2. rst_n: Global reset, active low.
    3. in_enable: Input enable signal, for controlling input data stream.
    4. in_data: Input data stream, the source for processing.
    5. out_ready: Output ready signal, a sign of end of processing.
    6. out_data: Output data stream, the result by processing.

    These ports ensured the basal functions of each module:
    Basal interface
    All modules work as follows:
    At first, module must be reseted and initialized, then the in_data will input with the in_enable enable. After many cycles, the out_data can be read, then out_ready will be high.

    Extended ports

    Because of the uniqueness of every module, basal ports can not meet the demand, so many extended ports are needed, these ports are designed al follows:

    1. x: Indefinite ports, they depend on the demand of module's function.
    2. in_count_x: The x component of input coordinate, always used for geometric transformation.
    3. in_count_y: The y component of input coordinate, always used for geometric transformation.
    4. out_count_x: The x component of output coordinate, always used for geometric transformation.
    5. out_count_y: The y component of output coordinate, always used for geometric transformation
    6. frame_addr: For controlling frame, giving the address with a data.

    Combine the basal ports and extended ports are, all demand will be meet:
    Complete interface

    Interface protocols

    After defining the hardware of interface, we must define the protocols. Because of every module's two working mode, and compatible with existing interface, for the simplest design, I make the two working mode conforming a same interface.

    Pipline mode

    In pipline mode, if the in_enable is enable, as the out_ready is enable, out_data will follow the change of in_data:
    Pipline mode
    This mode is used for applications which need data stream, because of the buffers of pipline, it can reach the max Fmax in theory.

    Req-Ack mode

    In the mode, the in_enable is used as "req", and the out_ready is used as "ack", only in the rising edge of in_enable the in_data will be inputed, and after the out_ready enable, the out_data will be held until the next in_enable's changing:
    Req-Ack mode
    This mode is always used for some special module, like "Histogram", because there is not meanning for these module. Moreover, this mode can be used for interaction between FPGA and software by AXI-Interface.