Electronic – VHDL: ADC to USB Buffering using Fifo

adcfifousbvhdl

I am trying to understand what is the correct way of doing such application, so please do not ask for complete code because each component is working fine on its own. I am struggling in the way of making them work together. I do not know the correct approach yet.

I have three vhdl modules adc, ft2232 usb and fifo modules.

ADC module is getting samples over spi. Its sample rate is 500KHz.
USB module is ft2232h usb implementation where it is achieving around 2 megabytes transfer to pc.
Fifo module works as well where i can read and write data on it. I used this code below also tried xilinx's ip core both works.
Fifo code

I want to buffer adc samples directly to pc. But what confuses me is that fifo cannot serve to both adc's write and usb's read operations simultaneously. Since they are two seperate processes they might try to use fifo at the same time. Should i define a busy flag to wait during read or write operations.

I appreciate any help.

Best Answer

But what confuses me is that fifo cannot serve to both adc's write and usb's read operations simultaneously.

Sure it can! That's why it has separate write and read ports. They operate completely independently of each other.

Related Solutions

FIFO(vhdl) : Delete Operation

I have done a type of fifo with had four extra inputs: rd_cancel and rd_commit, and wr_cancel and wr_commit. The idea is that you can do a bunch of writes and then either cancel the writes you did (erase the data you just wrote) or commit that data (make it available to the read port). The same thing for reading: rd_cancel would "unread" what you just read, rd_commit would commit your reads. The cancel/commit operation would cancel or commit only the data since the last cancel/commit.

This is done by having a temporary copy of the write and read pointers. These temp pointers are copied back and forth with the real pointers depending on the cancel/commit inputs. Also, when calculating if the FIFO is full or not, sometimes the temp pointers or the real pointers are used. It's a bit complicated, and beyond this kind of forum, but if this sounds like what you want then let me know and I'll see what I can come up with.

Just FYI: I have never seen this type of FIFO done before, but it seems like an obvious solution to several FIFO related problems. The last time I googled for a FIFO like this I came up empty, but I'd be surprised if nobody else have ever dreamed up something like this.

FIFO in VHDL : ERROR:HDLParsers:3324

Because you asked where the error comes from.

See IEEE Std 1076-2008, 6.5.6.3 Port clauses, para 9:

If a formal port is associated with an actual port, signal, or expression, then the formal port is said to be connected. If a formal port is instead associated with the reserved word open, then the formal is said to be unconnected. It is an error if a port of mode in is unconnected (see 6.5.6.3) or unassociated (see 6.5.7.3) unless its declaration includes a default expression (see 6.5.2). It is an error if a port of any mode other than in is unconnected or unassociated and its type is an unconstrained or partially constrained composite type. It is an error if some of the subelements of a composite formal port are connected and others are either unconnected or unassociated.

This is a problem with the association list (the port map) in the component instantiation for Led_out:

U102:Led_out
port map (
            M_CLK,
            BUTTON_T16,
            READ_EN,
            DATA_OUT
            );

In 6.5.7 Association lists, 6.5.7.1 para 2 we see that the formal_part of an association is optional:

association_list ::=
    association_element { , association_element }

association_element ::=
   [ formal_part => ] actual_part

Para 4:

An association element is said to be named if the formal designator appears explicitly; otherwise, it is said to be positional. For a positional association, an actual designator at a given position in an association list corresponds to the interface element at the same position in the interface list.

So you are using positional association and the actual designator is found by the association's position in the association list (the port map).

However your component declaration:

component Led_out is
PORT (
        M_CLK : IN STD_LOGIC;
        BUTTON_T16 : IN STD_LOGIC;
        rd_en : OUT STD_LOGIC;
        LEDS : out STD_LOGIC_VECTOR (7 downto 0);
        dout : IN STD_LOGIC_VECTOR(17 DOWNTO 0)
        );
end component;

doesn't have the same number of formals as the actuals you associate by position in the port map, the port map has one fewer which means the last one (dout) is unassociated according to paragraph 4 of 6.5.7.1 positional ordering.

That last port of the port clause is mode in and that violates the rule in paragraph 9 of 6.5.6.3, an error that can be detected at elaboration time.

Elaboration and execution of a model, 14.3 Elaboration of a block, package, or subprogram header, 14.3 Elaboration of a port clause, para 4 (in part):

If a given port is a port of mode in whose declaration includes a default expression, and if no association element associates a signal or expression with that port, then the default expression is evaluated and the effective and driving value of the port is set to the value of the default expression. ...

So if there were a default expression provided in the port declaration the unassociated formal of port in would not have an error.

See 6.5.2 Interface object declarations, para 6 (in part):

If an interface declaration contains a “:=” symbol followed by an expression, the expression is said to be the default expression of the interface object. ...

(And there are various rules for default expressions).

You're getting an error caused by not having LEDS which id declared as a mode out port in TOP_MODULE in the association list (the port map) where Led_out is instantiated.

And as Brian comments these things become readily apparent when using named association.

Best Answer

Related Solutions

FIFO(vhdl) : Delete Operation

FIFO in VHDL : ERROR:HDLParsers:3324

Related Topic