Electronic – Help with multiple receiver channels and single storage architecture

computer-architecturefpgaserialspartan 6

I want to build a datalogger that has multiple receiver channels that run on serial communication protocol RS232 and then collect the information from the channels in a single storage that would be accessed by another controller whenever it gets full.

I'm using Spartan-6 for the job. I figured I could use Ken Chapman's ultra compact uart to use as receivers and then deploy glue logic to store the data in a FIFO of depth equal to \$noofchannels \cdot (\frac{1}{2}.receiverbufferdepth)+ 4\$
assuming the width to be 8 in all the buffers.
Now I have three fillstate signals available from this UART:

Data Present
Buffer full
Buffer half full

and I have to attach a channel ID every time I read data from the receiver-buffer so that the controller reading my FIFO would know which data was from which channel-this thing introduces overhead. I want my algorithm to have lowest overhead as possible as in I want it to attach an appropriate chunk of data (bytes) with each identifier. My baud rate is 115.200 kBd and my clock is 16 MHz. I'm thinking of having 4 receiver channels.

At first I decided to run an FSM that would start every time a half-full signal goes high and read from that particular buffer till its data-present signal goes zero. Also I calculated that if I keep the buffer depth 4 at each receiver channels and if reading every byte took 2 cycles then I would still have appropriate clock cycles left to read all of the buffers, write it to a single FIFO and ask the controller to read all of it.

Problem with this approach is that I might lose data in case a channel doesn't send more than 7 bytes ( because kcuart6 has a FIFO of depth 16 which I can't change to 4).

Guys I want suggestions for a fool proof architecture that would ensure that no bytes are lost while my glue logic is reading from receiver buffers and also while the controller is accessing my storage memory (because I can't write while the controller is reading my FIFO).

Best Answer

If I understand your design correctly, I think you have a design issue that needs to be addressed first.

You are grabbing data from one of several UART receive buffers and shovelling it directly into a UART transmit buffer.

This will have the impact of mixing up bytes from each of the incoming buffers into the output stream with no apparent way of unmixing them.

Generally when multiplexing streams like this you would receive a delimited packet of some kind, probably terminated with a line feed. You buffer the input until you get the terminator then transmit the buffer, probably with a header marking which stream the line is associated with.

This leads in to answering the problem you are tackling. There are two approaches to this, your current approach is known as hard-realtime. The maximum input rate is X per second, I process them in Y ns, the timing works everything is sweet.

Once you switch to buffers a hard realtime approach gets difficult. A soft realtime approach would use the average rate of incoming data, a buffer (or four in your case) that absorbs some variation in that rate and an average output rate. You design in some margin so the average input is no more than 80% of the output and put in a handler for the very unlikely event that your buffer starts overflowing (dropping packets is normal).

Btw. ring buffers are nice for this kind of constant data in-data out work flow.

Related Solutions

Electronic – How to interface 1 MSPS ADC with processing module in FPGA

Normally, FIFOs are self controlled to prevent overflows and underflows. This is done by implementing a forward and backward flow control. Forward flow control means that data words are marked valid in the FIFO so that the read side can distinguish valid from invalid words. Backward flow control is achieved by exporting fill state of a FIFO to the write side. If the FIFO is full it creates a 'full' signal signaling the writer that it can handle more data.

In your case the ADC is transmitting data at a constant rate, so you have to dimension the FIFO correct to prevent an overflow.

\$Write\,speed = 20\,MHz \cdot \frac{1\ ADC\,Words}{16\ Cycles} = 1.25\,M\frac{Words}{sec}\$

\$Read\,speed = 100\,MHz \cdot \frac{1\,Word}{1\,Cycle} = 100\,M\frac{Words}{sec}\$

Because read speed is faster then write speed and write burst length is one, you don't need to worry about FIFO depth or burst length and overflows. Note cross clock FIFOs have a minimum dephs, e.g. 3 words.

Lets have a look to a common FIFO interface:

entity fifo_ic_got is
    generic (
        D_BITS         : positive;          -- Data Width
        MIN_DEPTH      : positive           -- Minimum FIFO Depth
    );
    port (
        -- Write Interface
        clk_wr    : in  std_logic;
        rst_wr    : in  std_logic;
        put       : in  std_logic;
        din       : in  std_logic_vector(D_BITS-1 downto 0);
        full      : out std_logic;

        -- Read Interface
        clk_rd    : in  std_logic;
        rst_rd    : in  std_logic;
        got       : in  std_logic;
        valid     : out std_logic;
        dout      : out std_logic_vector(D_BITS-1 downto 0)
    );
end;

This FIFO has 2 clock inputs, one for each clock domain (read (rd) and write (wr)) as well as one resets for each side.

The data path din to dout is surrounded by 4 signals:

put - din is valid -> store word in the FIFO
full - the FIFO is full -> no more data can be stored, put has no effect
valid - the FIFO has at least one data word, which can be seen at dout
got - the current word on dout was read and the circuit is ready for the next word

Writing at every 16th clock cycle means to assign put every 16 cycles to 1. She signal full can be ignored, because the read side is always faster then the write side.

Here is a waveform for the FIFO: enter image description here

Wavedrome online waveform editor

Electronic – Store consecutive UART inputs to register

To do this properly, you need to implement some sort of framing protocol with a state machine. I recommend cooking up a basic packet format that at least has some sort of magic number identifier in the header that the state machine can look for. This is used to discard any extra bytes that might be received due to line noise, etc. The state machine looks for that (might ended just be one byte), discards it, and then stores the following bytes into the correct locations in the output register.

Best Answer

Related Solutions

Electronic – How to interface 1 MSPS ADC with processing module in FPGA

Electronic – Store consecutive UART inputs to register

Related Topic