Generic driver to rest of the system communication - advice needed?

Question

Hello all,

First - I am new to VHDL but:

I have built a state machine that communicates with FT245 USB chip using parallel protocol (it is very simple - 8-bit data bus, read and write strobes and 2 flags from the FT245 to indicate if its internal FIFO has space - to write or has data - to read). I have tested it and it sends data to PC fine and I can also read received byte in VHDL.

My next step is to make this code more generic so I can re-use it in my other projects and to really be able to send data to PC and receive the data into some controller code to make some action.

As such I was thinking for my FT245 driver to have an input byte STD_LOGIC_VECTOR(7 DOWNTO 0) that module user would send byte which has to be send to FT245 and consequently to the PC and the same 1 byte as output byte. Since I will be utilizing FIFO from the FT245 chip, I would pass state of its flags to the module user, so it can be checked if read or write is possible.

For writing, user would have to assert write_request flag to '1' and then my FT245 module would go into the writing part of the state machine (of course - flag that FIFO for writing from FT245 would have to be in proper state). Next write request can happen only if write_request flag is put back to '0' and then back to '1'.

For reading, user would have to assert read_request flag to '1' and then my data_ready flag would drop from '1' to '0'. On next clock cycle, data will be read (lasts several clock cycles @ 50Mhz FPGA clock) and then data_ready flag will be asserted back to '1'.

In case both write_request and read_request are asserted on same clock edge, write would take precedence.

I am posting this since I am not particularly happy with the flags approach.

What is write_request flag is forgoten to be set back to 0? Should I think it is again a new write_request and continue from idle state to writing part immediately thus sending data again and again? Same with read_request - is it really read or? Similarly notifying that new that is available is so-so....

I guess after one write cylce, I can make a new state where I wait for write_request to drop back to 0, if it is not already. And same for the read cycle. But then I can be stuck in those states....

Since such "communication" between modules aka. various hardware drivers is I guess common - what are the usual approaches taken?

After this is done, I need to do communication with ADC, then make 32-bit quadrature encoder decoder with counter and some configuration part where PC sends some configuration like encoder counts to mm coefficient and so on. That is why I am thinking of using modular approach.

I am using some chinese Cyclone IV E FPGA module.

altera_forum · Answer

Your description is very wordy - no timing diagrams, so I dont really know what you're getting at. Are there any standard interfaces to use rather than this that would allow you to plug it into more mudules (like an Avalon or AXI-4?) read_req/wr_request is pretty standard and straight forward, just like a FIFO. But it seems a bit odd (and inefficient) to have to detect a rising edge on wr_req, you're data rate will be half the clock rate. THis seems to be more suitable for a requesd/acknowledge type interface.

altera_forum · Answer

Thanks for your reply.

There is no code nor timing diagrams since I wanted to describe my idea first in an human time-efficient manner which is by using words.

Developing the solution to produce code and timing diagrams would take some time after which someone can provide better or more efficient protocol type, which is also simple to implement but I didn't even know it exists.

Are there any "design patterns" or "best practices" books or papers for always repeating codes and/or glue logic such as this? Because I am sure that in most more complex FPGA solutions you have bunch of "modules" communicating with each other (sending, reading, waiting for completion of some task, etc). It is very hard to find something online as opposed to software where this is common.

Request/acknowledge type interface would work as:

1. Byte data put on input vector of FT245 driver. FT245 driver "data_sent" bit is low.

2. Request to write put high.

3. FT245 driver goes to next state and performs sending sequence.

4. FT245 driver goes to state upon completion of sending sequence and puts data_sent bit high.

5. Requester waits for data_sent to become high. When this happens, puts request to write to low and puts ACK bit to FT245 as high.

6. FT245 driver puts "data_sent" bit back to low and goes to idle state.

As for data rate:

@ 50Mhz clock every clock is at 20ns. Write pulse to FT245 chip is at minimum 50ns (= 3 clock cycles = 60ns). Read pulse is also 50ns (= 3 clock cycles = 60ns). I would loose about 3-4 clocks on this "communication protocol" making my write speed about 7 clock cycles (140ns) for 1 byte. This is 6.811MB/s which is well over the USB 2.0 data rate limit. so It is OK. however I would definetly like to learn more about more efficient implementations to know for the future!

altera_forum · Answer

Here's some information on interfacing to FTDI devices ...  http://www.ovro.caltech.edu/~dwh/correlator/pdf/ftdi.pdf  Cheers, Dave

altera_forum · Answer

I have looked at the Avalon bus specification for memory mapped slaves and devised a similar protocol:  Below is the user of the FT245 driver - it is a 2 process state machine:  
LIBRARY ieee;
USE ieee.std_logic_1164.all;
ENTITY Comm IS
        PORT 
        (
           clk : IN STD_LOGIC;
            rstn : IN STD_LOGIC;
            debug_wr_flag : STD_LOGIC;
            debug_in_data : IN STD_LOGIC_VECTOR(7 DOWNTO 0);
            debug_data_rd : OUT STD_LOGIC_VECTOR(7 DOWNTO 0);
            debug_data_wr : OUT STD_LOGIC_VECTOR(7 DOWNTO 0)
        );
END ENTITY;
ARCHITECTURE behavioral OF Comm is
   SIGNAL debug_wr_flag_reg : STD_LOGIC;
   SIGNAL debug_in_data_reg : STD_LOGIC_VECTOR(7 DOWNTO 0);
    
   SIGNAL rd_fifo_has_data : STD_LOGIC; -- FT245 fifo has data for reading
    SIGNAL wr_fifo_full : STD_LOGIC; -- FT245 fifo is full for writing
   SIGNAL waitreq : STD_LOGIC; -- FT245 is busy
    SIGNAL rd : STD_LOGIC; -- request rd
    SIGNAL wr : STD_LOGIC; -- request wr
    SIGNAL rddatavalid : STD_LOGIC; -- data is valid    
    SIGNAL rd_data : STD_LOGIC_VECTOR(7 DOWNTO 0); -- received (read) data by FT245
    SIGNAL wr_data : STD_LOGIC_VECTOR(7 DOWNTO 0); -- data to be written to FT245
    SIGNAL can_write : STD_LOGIC;
    SIGNAL can_read : STD_LOGIC;
    
    TYPE state IS (init, idle, wait_write, wait_read);    
    SIGNAL pr_state, nx_state : state;

COMPONENT FT245 IS
   PORT 
    ( 
       clk : IN STD_LOGIC;
        rstn : IN STD_LOGIC;
        rd_flag : IN STD_LOGIC;
        wr_flag : IN STD_LOGIC;
        rd_fifo_has_data : OUT STD_LOGIC;
        wr_fifo_full : OUT STD_LOGIC;
        waitreq : OUT STD_LOGIC;
        rddatavalid : OUT STD_LOGIC;
        data_write : IN STD_LOGIC_VECTOR(7 DOWNTO 0);
        data_read : OUT STD_LOGIC_VECTOR(7 DOWNTO 0)
    );
    
   END COMPONENT;
    
BEGIN
   driver : FT245 port map 
    (
        clk =&gt; clk, 
         rstn =&gt; rstn, 
         rd_flag =&gt; rd,
         wr_flag =&gt; wr,
         rd_fifo_has_data =&gt; rd_fifo_has_data, 
         wr_fifo_full =&gt; wr_fifo_full, 
         waitreq =&gt; waitreq, 
         rddatavalid =&gt; rddatavalid, 
         data_write =&gt; wr_data, 
         data_read =&gt; rd_data
    );
 
-- For debug purposes - show current values of rd and wr data. Not synced on purpose. 
debug_data_rd &lt;= rd_data;
debug_data_wr &lt;= wr_data;
-- For debug purposes - to inject some data to send...
PROCESS(clk)
BEGIN
   IF(rising_edge(clk)) THEN
     debug_wr_flag_reg &lt;= debug_wr_flag;
     debug_in_data_reg &lt;= debug_in_data;
    END IF;
END PROCESS;
-- Sequential part
PROCESS(clk, rstn)
BEGIN
   IF(rstn = '0') THEN
        pr_state &lt;= init;
    ELSIF(rising_edge(clk)) THEN
        pr_state &lt;= nx_state;
    END IF;
END PROCESS;
-- Combinatorial part
-- can write only if debug wr flag is 1 and fifo is not full and no transaction is in progress
can_write &lt;=  '1' WHEN debug_wr_flag_reg = '1' and wr_fifo_full = '0' and wr = '0' and rd = '0'  and waitreq = '0'
                  ELSE '0';
-- can read only if FT245 fifo has data and no transacation is in progress
can_read &lt;= '1' WHEN rd_fifo_has_data = '1' and wr = '0' and rd = '0'  and waitreq = '0' 
                ELSE '0';
PROCESS(pr_state, wr_fifo_full, waitreq, rddatavalid, rd_data, can_write, can_read, debug_in_data_reg)
BEGIN
  CASE pr_state IS
    WHEN init =&gt;
          wr_data &lt;= (others =&gt; '0');
            rd &lt;= '0';
            wr &lt;= '0';            
          nx_state &lt;= idle;
     WHEN idle =&gt;
     
          wr_data &lt;= (others =&gt; '0');
            rd &lt;= '0';
            wr &lt;= '0';
            nx_state &lt;= idle;
            
          IF(can_write = '1') THEN
               wr_data &lt;= debug_in_data_reg;
                wr &lt;= '1';
                nx_state &lt;= wait_write;
            ELSIF(can_read = '1') THEN
               rd &lt;= '1';
                nx_state &lt;= wait_read;            
            END IF;        
            
     WHEN wait_write =&gt;
     
            wr_data &lt;= debug_in_data_reg;
            wr &lt;= '1';
            rd &lt;= '0';
            nx_state &lt;= wait_write;
            
          IF(waitreq = '0') THEN
               wr &lt;='0';
                nx_state &lt;= idle;            
            END IF;          
            
     WHEN wait_read =&gt;
     
            rd &lt;= '1';
            wr &lt;= '0';
            wr_data &lt;= (others =&gt; '0');
           nx_state &lt;= wait_read;
          IF(waitreq = '0' and rddatavalid = '1') THEN
               rd &lt;= '0';                
               nx_state &lt;= idle;                
            END IF;     
            
     WHEN others =&gt;
     
        wr_data &lt;= (others =&gt; '0');
          wr &lt;= '0';
         rd &lt;= '0';  
         nx_state &lt;= init;
          
  END CASE;
END PROCESS;
END behavioral;
  And this is the skeleton of FT245 driver as a single process timed state machine. When it enters do_write and do_read, it will have sub-states to actually strobe the FT245 chip with data, etc. This code only shows the communication side towards. I had some trouble with inferring latches for the output so I did a single process FSM.   
library ieee;
USE ieee.std_logic_1164.all;
USE ieee.numeric_std.all;
ENTITY FT245 IS
   PORT 
    ( 
       clk : IN STD_LOGIC;
        rstn : IN STD_LOGIC;
        rd_flag : IN STD_LOGIC;
        wr_flag : IN STD_LOGIC;
        rd_fifo_has_data : OUT STD_LOGIC;
        wr_fifo_full : OUT STD_LOGIC;
        waitreq : OUT STD_LOGIC;
        rddatavalid : OUT STD_LOGIC;
        data_write : IN STD_LOGIC_VECTOR(7 DOWNTO 0);
        data_read : OUT STD_LOGIC_VECTOR(7 DOWNTO 0)
    );
END ENTITY;
ARCHITECTURE behavioral OF FT245 IS
BEGIN
-- Debug values 
rd_fifo_has_data &lt;= '0'; -- will not go into reading 
wr_fifo_full &lt;= '0'; -- will always mark as write is OK....
PROCESS(clk, rstn) 
    TYPE state IS (init, idle, do_write, write_end, do_read, read_end);    
    VARIABLE pr_state, nx_state : state;
    
   VARIABLE dummy : INTEGER RANGE 0 to 100; -- dummy counter for read data
    VARIABLE count : INTEGER RANGE 0 to 5;
    VARIABLE timer : INTEGER RANGE 0 to 5;
BEGIN
    IF(rstn = '0') THEN
       count := 0;
        pr_state := init;
        nx_state := init;
        
    ELSIF(rising_edge(clk)) THEN
    
       count := count +1;
        
        CASE pr_state IS
               
       WHEN init =&gt;
          
          dummy := 0;                    
          rddatavalid &lt;= '0';
          waitreq &lt;= '0';          
          timer := 0;
          nx_state  := idle;
          data_read &lt;= (others =&gt; '0');
          
        WHEN idle =&gt; 
                    
            rddatavalid &lt;= '0';
            waitreq &lt;= '0';
            nx_state := idle;
            timer := 0;
            
           IF(wr_flag = '1') THEN 
              waitreq &lt;= '1';
              nx_state := do_write;
            ELSIF(rd_flag = '1') THEN
              waitreq &lt;= '1';
              nx_state := do_read;
            END IF;              
       WHEN do_write =&gt;
                
            rddatavalid &lt;= '0';
            waitreq &lt;= '1';            
            nx_state := write_end;
            timer := 5; -- 100ns delay - as needed for FT245 to do its work....substates should be
                        -- here to do actual protocol to FT245
              
       WHEN write_end =&gt; 
                
            rddatavalid &lt;= '0';
            waitreq &lt;= '0';
            nx_state := idle;
            timer := 0;            
            
        WHEN do_read =&gt;
      
          dummy := dummy +1;            
            rddatavalid &lt;= '0';
            waitreq &lt;= '1';
            
            nx_state := read_end;
            timer := 5; -- 100 ns delay; actually there should be sub-states here 
                        -- to talk to FT245 chip as required
            
        WHEN read_end =&gt;
      
         data_read &lt;= std_logic_vector(to_unsigned(dummy,8));         
         rddatavalid &lt;= '1';
         waitreq &lt;= '0';
         
         nx_state := idle;
         timer := 0;            
            
         WHEN others =&gt;
          
          data_read &lt;= (others =&gt; '0');          
          rddatavalid &lt;= '0';
          waitreq &lt;= '0';
          
          timer := 0;
          nx_state  := init;
        
      END CASE;
        
      -- Update present state with next state 
      IF(count &gt;= timer) THEN
        pr_state := nx_state;
        count := 0;
      END IF;  
    END IF; -- rising clock
END PROCESS; -- fsm
END behavioral;
   Didn't have time to do simulation yet - holidays &amp; such.   What do you all think?

altera_forum · Answer

--- Quote Start ---

Here's some information on interfacing to FTDI devices ...

http://www.ovro.caltech.edu/~dwh/correlator/pdf/ftdi.pdf

Cheers,

Dave

--- Quote End ---

Thanx.

Protocol itself is very simple - I did a functional proof of concept and tested in on real hardware in 1 hour.

However, there is some interesting stuff in there to check it out in terms of integrating FSM for FTDI chips into rest of the code. I will check it out.

Forum Discussion

Generic driver to rest of the system communication - advice needed?

7 Replies

Recent Discussions

Fitter stalls on "Advanced Physical Optimization" on Windows 10

EDA_MAINTAIN_DESIGN_HIERARCHY obsolete?

Problem with wire level expressions in platform designer quartus pro 25.1

NIOS V Sysnthesis Fails with Quartus 25.1 Lite

Known issues in Quartus Standard 18.0