Electrical – Fastest way of transferring data from VHDL section to Microblaze processor

fpgamicroblaze

My basic application involves sending ADC samples to PC via Ethernet. The ADC sampling and storing is happening in VHDL section while the Ethernet socket programming code is in Microblaze processor.

Microblaze is running at 60MHz and the FPGA is at 100MHz (I've taken care of the CDC issue). For transferring 1k data it takes me 740us. I have a dual port BRAM where the samples are stored and upon an interrupt Microblaze will read it from the second port. For simplicity I have kept the BRAM read in always enabled state and I am reading the data based on address only.

Any ideas as to how I can transfer the data in a faster way.

I've added the BRAM connection details for more reference.
I've used the simple dual port type BRAM.

Buf_2k : Ethernet_test_data
  PORT MAP (
    clka => ADC_clock,                      --10MHz clock
    wea(0) => BRAM_wr_en,                   --Write enable generated synchronously to ADC_clock
    addra => buf_wr_addr(10 downto 0),      --BRAM address generated similarly as write enable
    dina => ADC_data_trig,                  --Registered ADC data to be stored in BRAM
    clkb => CLK_50M,                        --50MHz clock generated from DCM
    addrb => BRAM_addr(10 downto 0),        --Address coming from Microblaze to read the data
    doutb => BRAM_dout                      --This data out is directly connected to Microblaze
  );

Best Answer

Any ideas as to how I can transfer the data in a faster way.

You could potentially use the FSL (or AXI-Stream in newer microblazes), as that is a single cycle "read from FIFO" into register.

But really the question is what do you mean by faster transfers?

The data is already "in the Microblaze subsystem" once it is in a BRAM that the MB can access. The processor can only go as fast as it can go, you cannot get the data any more tightly coupled than it already is (assuming the BRAM is directly connected to an LMB), the BRAM access is very quick. Have a look at the assembly code for the loop in which you are reading the data - there is probably a lot of stuff going on (all of which is necessary if you have the C-optimiser turned on).

You are measuring 42 cycles per 32 bit read, which sounds quite slow. Some thoughts:

Are you processing the data in the loop which reads it?
Is your loop code in cache, or are you running from some external memory?

In the best case of just reading the data to a register and then ignoring it, you could achieve a few cycles per word.

Related Solutions

Synchronizing input and output

I think I'd have answered this interview question the same way you did. I believe the interviewer's requirement "to be done without a FIFO" was because a FIFO buffer is a valid, practical way to solve the problem of multiple clock domains -- but it can be done without the head/tail logic of a complete FIFO in many cases. And in the context of a job interview, simply instantiating a standard module doesn't demonstrate that you understand how to approach FPGA / HDL design. (I've interviewed candidates who couldn't even manage that small task.)

Passing data between different clock domains is usually done with three stages of flip-flops. The first stage is in the source clock domain (clkA), and the second and third stage flip-flops are in the receiver clock domain (clkB). The setup time of the second stage flip-flop is sometimes violated because the clocks are not synchronous, so the third-stage flip-flop is used to clean up the timing. Since there is a delay, the data_valid signal is passed in parallel with the data.

module SyncExample (
    input   wire            clkA,
    input   wire    [7:0]   Data_in,        // in clkA clock domain
    input   wire            Data_valid,     // in clkA clock domain
    input   wire            clkB,
    output  reg     [7:0]   Data_out,       // in clkB clock domain
    output  reg             Data_out_valid  // in clkB clock domain
    )

// First stage pipeline registers the clkA clock domain signals.
// pipeline_1_valid is set by Data_valid and remains set 
// until cleared by pipeline_1_valid_clear acknowledge from clkB domain.
reg [7:0] pipeline_1_data;
reg       pipeline_1_valid;
wire      pipeline_1_valid_clear;
initial begin
    pipeline_1_data <= 0;
    pipeline_1_valid <= 0;
end
always @(posedge clkA) begin
    if (Data_valid) begin
        // capture pipeline_1_data only when Data_in is valid
        pipeline_1_data <= Data_in;
    end
    // keep pipeline_1_valid set after Data_valid, until pipeline_1_valid_clear.
    pipeline_1_valid <= (Data_valid | (pipeline_1_valid & ~pipeline_1_valid_clear));
end

// Second stage pipeline registers the clkB clock domain signals.
// Because clkA and clkB are asynchronous clock domains, 
// setup time cannot be guaranteed for this stage.
// The previous pipeline_1 stage holds its data valid for
// more than one clkA cycle, to help achieve clkB setup requirement.
reg [7:0] pipeline_2_data;
reg       pipeline_2_valid;
initial begin
    pipeline_2_data <= 0;
    pipeline_2_valid <= 0;
end
always @(posedge clkB) begin
    pipeline_2_data <= pipeline_1_data;
    pipeline_2_valid <= pipeline_1_valid;
end

// Third stage pipeline registers the clkB clock domain signals.
initial begin
    Data_out <= 0;
    Data_out_valid <= 0;
end
always @(posedge clkB) begin
    Data_out <= pipeline_2_data;
    Data_out_valid <= pipeline_2_valid;
end

// pipeline_1_valid_clear timing feedback signals when the data-valid signal
// has propagated through all stages.
// For this simple example, we assume data_out is captured as soon as it is valid.
// A practical application should instead drive this with a read_data_out command.
assign pipeline_1_valid_clear = Data_out_valid;

endmodule;

You can also find similar example code in Xilinx ISE Language Templates under Verilog | Synthesis Constructs | Coding Examples | Misc | Asynchronous Input Synchronization.

edit: Added pipeline_1_valid_clear signal and set/clear behavior to meet the slower clock domain's minimum pulse width requirement. Capture pipeline_1_data only when Data_in is valid.

Electronic – Why won’t the Xilinx block RAM in a Spartan-3E consistently return data in a single clock cycle

Newly written data at the rising-edge is available directly after this edge only at the same port. Actually, the data input is internally forwarded to the data output of the same RAM port. Also called WRITE_FIRST mode.

But, it is never forwarded to the output of the other RAM port, regardless of the specified WRITE_MODE. It will be available for reading (of course at a another rising edge) after the internal write to the memory has been completed. In your example it is just the next rising clock edge, because the internal write time is always smaller (faster) than the minimum allowed clock period.

This behavior is described in XAPP 463 Using Block RAM in Spartan-3 Generation FPGAs in section Dual-Port RAM Conflicts and Resolution. The given example there uses different clocks, but is also applies whe the same clock is used for both ports.

This behaviour is still the same in current FPGAs from Xilinx and Altera.

The forwarding to the other RAM port has to be done by your one with surrounding logic.

Best Answer

Related Solutions

Synchronizing input and output

Electronic – Why won’t the Xilinx block RAM in a Spartan-3E consistently return data in a single clock cycle

Related Topic