Designer''r toolbox

Part 3 Designer’s Toolbox The third section of this book is a designer’s toolbox of functions. These are relatively standard functions that occur in many designs and test circuits, and so it is incredibly useful to have at least an ini- tial design to evaluate rather than having to develop one from scratch. The first chapter in this part (chapter 7) looks at serial communi- cations, starting from the fundamentals of data transmission and discussing a practical approach of incorporating USB into the design. The next chapter (chapter 8) discusses digital filtering, with a simple example to show how to take a standard Laplace (S domain) description and implement it in a VHDL digital filter. Chapter 9 is an introduction to an increasingly important topic – secure systems – with a description of block ciphers, DES and AES. The second half of this section is concerned with standard inter- faces. Chapter 10 looks at modeling memory in VHDL, with a description of ROM, RAM, Flash and SRAM. Chapters 11 and 12 describe how to implement a simple PS/2 interface to a mouse and keyboard respectively. The data modes and protocols are reviewed and a simple implementation for each is described. Finally, Chapter 13 shows how to build a simple VGA interface, complete with Sync timing code in VHDL. This chapter is a useful starting point for those who need to develop complex applications, but often need to build a frame- work from scratch, but do not wish to develop all the routines from nothing. This part of the book gives a ‘helping hand’ up the learn- ing curve, although it must be stressed that the examples given are purely for education and as such have been written with simplicity and clarity in mind. Ch07-H6845.qxd 4/5/07 11:28 AM Page 81 This page intentionally left blank 7 Serial Communications Introduction There are a wide variety of serial communications protocols avail- able, but all rely on some form of coding scheme to efficiently and effectively transmit the serial data across the transmission medium. In this chapter, not only will the common methods of transmitting data be reviewed (RS-232 and Universal Serial Bus (USB)), but in addition some useful coding mechanisms will be described (Manchester, Code Mark Inversion, Non-Return-toZero – NRZ, Non-Return-toZero-Inverted – NRZI) as they often are used as part of a higher level transmission protocol. For example, the NRZI coding technique is used in the USB protocol. Manchester encoding and decoding Manchester encoding is a simple coding scheme that translates a basic bit stream into a series of transitions. It is extremely useful for ensuring that a specific bandwidth can be used for data trans- mission, as no matter what the sequence of the data bits, the frequency of the transmitted stream will be exactly twice the fre- quency of the original data. It also makes signal recovery trivial, because there is no need to attempt to extract a clock as the data can be recovered simply by looking for the edges in the data and extracting asynchronously. The basic approach to Manchester encoding is shown in Figure 16. Another advantage of the scheme is that the method is highly tolerant of errors in the data, if an error occurs, then the subse- quent data is not affected at all by an error in the transmitter, the medium or the receiver, and after the immediate glitch, the data can continue to be transmitted effectively without any need Ch07-H6845.qxd 4/5/07 11:28 AM Page 83 for error recovery. Of course, the original data can use some form of data coding to add in error correction (see the chapter on data checking on this book for methods such as parity checks, or CRC). If we wish to create a VHDL model for this type of coding scheme, it is actually relatively simple. The first step is to identify that we have a single data input (D) and a clock (CLK). Why syn- chronous? Using a synchronous clock we can define a sample on the rising edge of the clock for the data input and use BOTH edges of the clock to define the transitions on the output. The resulting behavioural VHDL code is shown below: Library ieee; Use ieee.std_logic_1664.all; Entity Manchester_encoder is Port ( Clk : in std_logic; D : in std_logic; Q : out std_logic ); End entity Manchester_encoder; Architecture basic of Manchester_encoder is Signal lastd : std_logic := '0'; Begin P1: Process ( clk ) Begin If rising_edge(clk) then if ( d = '0' ) then Q <= '1'; Lastd <= '0'; elsif ( d = '1' ) then Q <= '0'; Lastd <= '1'; Design Recipes for FPGAs 84 11 1 1 11000 Figure 16 Manchester Encoding Scheme Ch07-H6845.qxd 4/5/07 11:28 AM Page 84 Else Q <= 'X'; Lastd <= 'X'; End if; End if; If falling_edge(clk) then If ( lastd = '0' ) then Q <= '0'; elsif ( lastd = '1' ) then Q <= '1'; Else Q <= 'X'; End if End if; End process p1; End architecture basic; This VHDL is simple but there is an even simpler way to encode the data and that is to simply XOR the clock with the data. If we look at the same data sequence, we can see that if we add a clock, and observe the original data and the Manchester encoded output, that this is simple the data XORd with the clock shown in Figure 17. So, using this simple mechanism, we can create a much simpler Manchester encoder that simply XORs the clock and the data to obtain the resulting Manchester encoded data stream with the resulting VHDL: Library ieee; Use ieee.std_logic_1664.all; Entity Manchester_encoder is Port ( Clk : in std_logic; D : in std_logic; Q : out std_logic ); End entity Manchester_encoder; Architecture basic of Manchester_encoder is Begin Q <= D XOR CLK; End architecture basic; Decoding the Manchester data stream is also a choice between asynchronous and synchronous approaches. We can use a local clk and detect the values of the input to evaluate whether the values on the rising and falling edges are 0 or 1, respectively and ascertain the values of the data as a result, but clearly this is dependent on the Serial Communications 85 Ch07-H6845.qxd 4/5/07 11:28 AM Page 85 transmitter and receiver clocks being synchronized to a reasonable degree. Such a simple decoder could look like this: Entity Manchester_decoder is Port ( Clk : in std_logic; D : in std_logic; Q : out std_logic ); End entity Manchester_decoder; Architecture basic of Manchester_decoder is Signal lastd : std_logic := '0'; Begin P1 : process (clk) Begin If rising_edge(clk) then Lastd <= d; End if; If falling_edge(clk) then If (lastd = '0') and (d = '1') then Q <= '1'; Elsif (lastd = '1') and (d = '0') then Q <= '0'; Else Q <= 'X'; End if; End if; End process p1; End architecture basic; In this VHDL model, the clock is at the same rate as the trans- mitter clock, and the data should be sent in packets (see the data checking chapter of this book) to ensure that the data is not sent in too large blocks such that the clock can get out of sync, and also Design Recipes for FPGAs 86 CLK D Q 00011 1111 Figure 17 Manchester Encoding Using XOR Function Ch07-H6845.qxd 4/5/07 11:28 AM Page 86 that the data can be checked for integrity to correct for mistakes or the clock on the receiver being out of phase. NRZ coding and decoding The NRZ encoding scheme is actually not a coding scheme at all. It simply states that a ‘0’ is transmitted as a ‘0’ and a ‘1’ is transmit- ted as a ‘1’. It is only worth mentioning because a designer may see the term NRZ and assume that a specific encoder or decoder was required, whereas in fact this is not the case. It is also worth noting that there are some significant disadvantages in using this simple approach. The first disadvantage, especially when compared to the Manchester coding scheme is that long sequences of ‘0’s or ‘1’s give effectively DC values when transmitted, that are susceptible to problems of noise and also make clock recovery very difficult. The other issue is that of bandwidth. Again if we compare the coding scheme to that of the Manchester example, it is obvious that the Manchester scheme requires quite a narrow bandwidth (relatively) to transmit the data, whereas the NRZ scheme may require any- thing from DC up to half the data rate (Nyquist frequency) and any- thing in between. This makes line design and filter design very much more problematic. NRZI coding and decoding In the NRZI scheme, the potential problems of the NRZ scheme, particularly the long periods of DC levels are partially alleviated. In the NRZI, if the data is a ‘0’, then the data does not change, whereas if a ‘1’ occurs on the data line, then the output changes. Therefore the issue of long sequences of ‘1’s is addressed, but the potential for long sequences of ‘0’s remains. It is a simple matter to create a basic model for a NRZI encoder using the following VHDL model: Entity nrzi_encoder is Port ( CLK : in std_logic; D : in std_logic; Q : out std_logic ); End entity nrzi_encoder; Architecture basic of nrzi_encoder is Signal qint : std_logic := '0'; Serial Communications 87 Ch07-H6845.qxd 4/5/07 11:28 AM Page 87 Begin p1 : process (clk) Begin If (d = '1') then If ( qint = '0' ) then Qint <= '1'; else Qint <= '0'; End if; End if; End process p1; Q <= qint; End architecture basic; Notice that this model is synchronous, but if we wished to make it asynchronous, the only changes would be to remove the clk port and change the process sensitivity list from clk to d. We can apply the same logic to the output, to obtain the decoded data stream, using the VHDL below. Again we are using a synchronous approach: Entity nrzi_decoder is Port ( CLK : in std_logic; D : in std_logic; Q : out std_logic ); End entity nrzi_decoder; Architecture basic of nrzi_decoder is Signal lastd : std_logic := '0'; Begin p1 : process (clk) Begin If rising_edge(clk) then If (d = lastd) then Q <= '0'; Else Q <= '1'; End if; Lastd <= d; End if; End process p1; End architecture basic; The NRZI decoder is extremely simple, in that the only thing we need to check is whether the data stream has changed since the last clock edge. If the data has changed since the last clock, then we know that the data is a ‘1’, but if the data is unchanged, then we know that it is a ‘0’. Clearly we could use an asynchronous approach, but this would rely on the data checking algorithm downstream being synchronized correctly. Design Recipes for FPGAs 88 Ch07-H6845.qxd 4/5/07 11:28 AM Page 88 RS-232 Introduction The basic approach of RS-232 serial transmission is that of a UART. UART stands for Universal Asynchronous Receiver/Transmitter. It is the standard method of translating a serial communication stream into the parallel form used by computers. RS-232 is a UART that has a specific standard defined for start, stop, break, data, parity and pin names. RS-232 baud rate generator The RS-232 is an asynchronous transmission scheme and so the cor- rect clock rate must be defined prior to transmission to ensure that the data is transmitted and received correctly. The RS-232 baud rate can range from 1200 baud up to 115200 baud. This is based on a standard clock frequency of 14.7456 MHz, and this is then divided down by 8,16,28,48,96,192,384 and 768 to get the correct baud rates. We therefore need to define a clock divider circuit that can output the correct baud rate configured by a control word. We have obviously got 8 different ratios, and so we can use a 3 bit control word (baud[2:0]) plus a clock and reset to create the correct frequencies, assuming that the basic clock frequency is 14.7456 MHz (Figure 18). The VHDL for this controller is given below and uses a single process to select the correct baud rate and another to divide down the input clock accordingly: LIBRARY ieee; USE ieee.Std_logic_1164.ALL; USE ieee.Std_logic_unsigned.ALL; Serial Communications 89 Baud Rate Generator CLK RST 2:0 BAUD CLKOUT Figure 18 Baud Clock Generator Ch07-H6845.qxd 4/5/07 11:28 AM Page 89 ENTITY baudcontroller IS PORT( clk : IN std_logic; rst : IN std_logic; baud : IN std_logic_vector(0 to 2); clkout : OUT std_logic); END baudcontroller; ARCHITECTURE simple OF baudcontroller IS SIGNAL clkdiv : integer := 0; SIGNAL count : integer := 0; BEGIN Div: process (rst, clk) begin if rst = '0' then clkdiv <= 0; count <= 0; elsif rising_edge(CLK) then case Baud is when "000" => clkdiv <= 7; -- 115200 when "001" => clkdiv <= 15; -- 57600 when "010" => clkdiv <= 23; -- 38400 when "011" => clkdiv <= 47; -- 19200 when "100" => clkdiv <= 95; -- 9600 when "101" => clkdiv <= 191; -- 4800 when "110" => clkdiv <= 383; -- 2400 when "111" => clkdiv <= 767; -- 1200 when others => clkdiv <= 7; end case; end if; end process; clockdivision: process (clk, rst) begin if rst='0' then clkdiv <= 0; count <= 0; elsif rising_edge(CLK) then count <= count + 1; if (count > clkdiv) then clkout <= not clkout; count <= 0; end if; end if; end process; END simple; RS-232 receiver The RS-232 receiver wait for data to arrive on the RX line and has a specification defined as follows Ͻnumber of bitsϾϽparityϾ Design Recipes for FPGAs 90 Ch07-H6845.qxd 4/5/07 11:28 AM Page 90 . Part 3 Designer’s Toolbox The third section of this book is a designer’s toolbox of functions. These are relatively standard