FONT SIZE : AAA
The Universal Serial Bus (USB) protocol has become pervasive and ubiquitous in the computing and electronics industries in recent years. The protocol supports a variety of data rates from low speed (10 kbits/s to 100 kbits/s) up to high speed devices (up to 400 Mbits/s). While in principle it is possible to create FPGA interfaces directly to a USB bus, for anything other than the lower data rates it requires accurate voltage matching and impedance matching of the serial bus. For example, the low data rates require 2.8 V (1) and 0.3 V (0), differentially, whereas the high speed bus requires 400 mV signals, and in both cases termination resistors are required.
In practice, therefore, it is common when working with FPGAs to use a simple interface chip that handles all the analog interface issues and can then be connected directly to the FPGA with a simple UART style interface. An example device is the Silicon Labs CP2101, that takes the basic USB Connector pins (Differential Data and Power & Ground) and then sets up the basic serial data transmission pins. The block diagram of this device is given in Figure 15.6.
The pins on this device are relatively self explanatory and are summarized in the following table.
The basic operation of the serial port starts from the use of the TXD and RXD (data) lines. If the configuration is as a NULL modem with no handshaking, it is possible to simply use the transmit (TXD) and receive (RXD) lines alone.
If you wish to check that the line is clear for sending data, then the RTS signal can be set (Request to Send), in this case active low, and if the line is ready, then the CTS line will go low and the data can be sent. This basic scheme is defined in such a way that, once the receiver signal goes low, the transmitter can send at any rate, the assumption being that the receiver can handle whatever rate is provided. The protocol can be made more capable by using the DTR line, and this notifies the other end of the link that the device is ready for receiving data communications. The Data Carrier Detection (DCD) line is not used directly in the link, but indicates that there is a valid communications link between the devices. We can develop a
Figure 15.6
USB transceiver chip CP2101.
VHDL model for such a communications link with as much complexity as we need to communicate with the hardware in the system under consideration, starting with a simple template:
1 Entity serial_handler is
2 Port( 3 Clk : in std_logic;
4 Nrst : in std_logic;
5 Data_in : in std_logic;
6 Data_out : out std_logic;
7 TXD : out std_logic;
8 RXD : in std_logic
9 );
10 End entity serial_handler;
In this initial model, we have a simple clock and reset, with two data connections for the synchronous side, and the TXD and RXD asynchronous data communications lines. We can put together a simple architecture that simply samples the data lines and transfers them into an intermediate variable for use on the synchronous side of the model:1 architecture basic of serial_handler is
2 begin
3 p1 : process (clk )
4 begin
5 if rising_edge(clk) then
6 rxd_int <= rxd;
7 end if; 8 end process p1;
9 end architecture basic;
We can extend this model to handle the transmit side also, using a similar approach:
1 Architecture mod of serial_handler is
2 Begin
3 P1 : process (clk )
4 Begin
5 If rising_edge(clk) then
6 Data_out <= rxd;
7 Txd <= data_in;
8 End if; 9 End process p1;
10 End architecture mod;
This entity is the equivalent to a NULL modem architecture. If we wish to add the DTR notification that the device is ready for receiving data, we can add this to the entity list of ports and then gate the receive data if statement using the DTR signal:
1 entity serial_handler is
2 port( 3 clk : in std_logic;
4 nrst : in std_logic;
5 data_in : in std_logic;
6 data_out : out std_logic;
7 dtr : in std_logic;
8 txd : out std_logic;
9 rxd : in std_logic
10 );
11 end entity serial_handler;
12 architecture serial_dtr of serial_handler is
13 begin
14 p1 : process (clk )
15 begin
16 if rising_edge(clk) then
17 if dtr = 0 then
18 data_out <= rxd;
19 end if;
20 txd <= data_in;
21 end if;
22 end process p1;
23 end architecture basic;
Using this type of approach we can extend the serial handler to incorporate as much or as little of the modem communications link protocol as we require.
In a similar manner we can generate a similar Verilog serial handler module and then add in the same basic behavior of the handler as required.
1 module serial_handler (
2 clk, / clock
3 nrst, / reset
4 datain, / data in
5 dataout, / data out
6 txd, / Tx out
7 rxd /Received data in
8 );
As before, we have a simple clock and reset, with two data connections for the synchronous side, and the TXD and RXD asynchronous data communications lines. We can put together a simple module process that samples the data lines and transfers them into an intermediate variable for use on the synchronous side of the model:
1 always @ (posedge clk)
2 begin
3 rxd_int <= rxd;
4 end
Manufacturer:Xilinx
Product Categories: CPLD/FPGA
Lifecycle:Obsolete -
RoHS: -
Manufacturer:Xilinx
Product Categories:
Lifecycle:Any -
RoHS: -
Manufacturer:Xilinx
Product Categories: Condensateur
Lifecycle:Obsolete -
RoHS:
Manufacturer:Xilinx
Product Categories:
Lifecycle:Obsolete -
RoHS:
Manufacturer:Xilinx
Product Categories:
Lifecycle:Obsolete -
RoHS:
Support
