URL
https://opencores.org/ocsvn/cpu_lecture/cpu_lecture/trunk
Subversion Repositories cpu_lecture
[/] [cpu_lecture/] [trunk/] [html/] [02_Top_Level.html] - Rev 11
Go to most recent revision | Compare with Previous | Blame | View Log
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <HTML> <HEAD> <TITLE>html/Top_Level</TITLE> <META NAME="generator" CONTENT="HTML::TextToHTML v2.46"> <LINK REL="stylesheet" TYPE="text/css" HREF="lecture.css"> </HEAD> <BODY> <P><table class="ttop"><th class="tpre"><a href="01_Introduction_and_Overview.html">Previous Lesson</a></th><th class="ttop"><a href="toc.html">Table of Content</a></th><th class="tnxt"><a href="03_Pipelining.html">Next Lesson</a></th></table> <hr> <H1><A NAME="section_1">2 TOP LEVEL</A></H1> <P>This lesson defines what we want to create and the top level VHDL file for it. <H2><A NAME="section_1_1">2.1 Design Purpose</A></H2> <P>We assume that the purpose of the design is to build an FPGA with the following features: <UL> <LI>a CPU similar to the Atmel ATmega8, <LI>a serial port with a fixed baud rate, and <LI>an output for a single digit 7-segment display. </UL> <P>It is assumed that a suitable hardware exists. <H2><A NAME="section_1_2">2.2 Top Level Design</A></H2> <P>A CPU with I/O is a somewhat complicated beast. In order to tame it, we brake it down into smaller and smaller pieces until the pieces become trivial. <P>The trick is to perform the breakdown at points where the connection between the pieces is weak (meaning that it consists of only a few signals). <P>The top level of our FPGA design, and a few components around the FPGA, looks like this: <P><br> <P><img src="avr_fpga.png"> <P><br> <P>This design consists of 2 big sub-components <STRONG>cpu</STRONG> and <STRONG>ino</STRONG>, a small sub-component <STRONG>seg</STRONG>, and some local processes like <STRONG>clk_div</STRONG> and <STRONG>deb</STRONG> that are not broken down in other VHDL files, but rather written directly in VHDL. <P><STRONG>cpu</STRONG> and <STRONG>ino</STRONG> are described in lessons 4 and 8. <P><STRONG>seg</STRONG> is a debug component that has the current program counter (<STRONG>PC</STRONG>) of the CPU as input and displays it as 4 hex digits that show up one by one with a short break between every sequence of hex digits. Since <STRONG>seg</STRONG> is rather board specific, we will not describe it in detail in this lecture. <P>The local processes are described further down in this lesson. Before that we explain the structure that will be used for all VHDL source file. <H2><A NAME="section_1_3">2.3 General Structure of our VHDL Files</A></H2> <H3><A NAME="section_1_3_1">2.3.1 Header and Library Declarations</A></H3> <P>Each VHDL source file starts with a comment containing a copyright notice (all files are released under the GPL) and the purpose of the file. Then follows a declaration of the libraries being used. <H3><A NAME="section_1_3_2">2.3.2 Entity Declaration</A></H3> <P>After the header and libraries, the entity that is defined in the VHDL file is declared. We declare one entity per VHDL file. The declaration consists of the name of the entity, the inputs, and the outputs of the entity. In this declaration the order of input and outputs does not matter, but we try to stick to the convention to declare the inputs before the outputs. <P>There is one exception: the file <STRONG>common.vhd</STRONG> does not define an entity, but a VHDL package. This package contains the definitions of constants that are used in more than one VHDL source file. This ensures that changes to these constants happen in all files using them. <H3><A NAME="section_1_3_3">2.3.3 Entity Architecture</A></H3> <P>Finally, the architecture of the entity is specified. The architecture consists of a header and a body. <P>In the header we declare the components, functions, signals, and constants that are used in the body. <P>The body defines how the items declared in the header are being used (i.e. instantiated, interconnected etc.). This body contains, so to say, the "intelligence" of the design. <H2><A NAME="section_1_4">2.4 avr_fpga.vhd</A></H2> <P>The top level of our design is defined in <STRONG>avr_fpga.vhd</STRONG>. Since this is our first VHDL file we explain it completely, line by line. Later on, we will silently skip repetitions of parts that have been described in other files or that are very similar. <H3><A NAME="section_1_4_1">2.4.1 Header and Library Declarations</A></H3> <P>avr_fpga.vhd starts with a copyright header. <P><br> <pre class="vhdl"> 1 ------------------------------------------------------------------------------- 2 -- 3 -- Copyright (C) 2009, 2010 Dr. Juergen Sauermann 4 -- 5 -- This code is free software: you can redistribute it and/or modify 6 -- it under the terms of the GNU General Public License as published by 7 -- the Free Software Foundation, either version 3 of the License, or 8 -- (at your option) any later version. 9 -- 10 -- This code is distributed in the hope that it will be useful, 11 -- but WITHOUT ANY WARRANTY; without even the implied warranty of 12 -- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the 13 -- GNU General Public License for more details. 14 -- 15 -- You should have received a copy of the GNU General Public License 16 -- along with this code (see the file named COPYING). 17 -- If not, see http://www.gnu.org/licenses/. 18 -- 19 ------------------------------------------------------------------------------- 20 ------------------------------------------------------------------------------- 21 -- 22 -- Module Name: avr_fpga - Behavioral 23 -- Create Date: 13:51:24 11/07/2009 24 -- Description: top level of a CPU 25 -- 26 ------------------------------------------------------------------------------- 27 <pre class="filename"> src/avr_fpga.vhd </pre></pre> <P> <P><br> <P>The libraries used are more or less the same in all VHDL files: <P><br> <pre class="vhdl"> 28 library IEEE; 29 use IEEE.STD_LOGIC_1164.ALL; 30 use IEEE.STD_LOGIC_ARITH.ALL; 31 use IEEE.STD_LOGIC_UNSIGNED.ALL; 32 <pre class="filename"> src/avr_fpga.vhd </pre></pre> <P> <P><br> <P>The only Xilinx specific components needed for this lecture are the block RAMs. For functional simulation we provide compatible components written in VHDL. For FPGAs from other vendors you can probably include their FPGA libraries, but we have not tested this. <H3><A NAME="section_1_4_2">2.4.2 Entity Declaration</A></H3> <P>For a top level entity, the inputs and outputs of the entities are the pins of the FPGA. <P>For a lower level entity, the inputs and outputs of the entity are associated ("connected") with the inputs and outputs of the instance of the entity in a higher level entity. For this to work, the inputs and outputs of the declaration should match the component declaration in the architecture of another entity that instantiates the entity being declared. <P>Since we discuss the top-level, our inputs and outputs are pins of the FPGA. The top level entity is declared like this: <P><br> <pre class="vhdl"> 33 entity avr_fpga is 34 port ( I_CLK_100 : in std_logic; 35 I_SWITCH : in std_logic_vector(9 downto 0); 36 I_RX : in std_logic; 37 38 Q_7_SEGMENT : out std_logic_vector(6 downto 0); 39 Q_LEDS : out std_logic_vector(3 downto 0); 40 Q_TX : out std_logic); <pre class="filename"> src/avr_fpga.vhd </pre></pre> <P> <P><br> <P>We therefore have the following FPGA pins: <TABLE border="1"> <THEAD><TR><TH>Pin</TH><TH>Purpose</TH></TR></THEAD> <TBODY> <TR><TD>I_CLK_100</TD><TD>a 100 MHz Clock from the board.</TD></TR> <TR><TD>I_SWITCH</TD><TD>a 8 bit DIP switch and two single push-buttons.</TD></TR> <TR><TD>I_RX</TD><TD>the serial input of our UART.</TD></TR> <TR><TD>Q_7_SEGMENT</TD><TD>7 lines to the LEDs of a 7-segment display.</TD></TR> <TR><TD>Q_LEDS</TD><TD>4 lines to single LEDs</TD></TR> <TR><TD>Q_TX</TD><TD>the serial output of our UART.</TD></TR> </TBODY> </TABLE> <P>The lower 8 bits of <STRONG>SWITCH</STRONG> come from a DIP switch while the upper two bits come from two push-buttons. The two push-buttons are used as reset buttons, while the DIP switch goes to the I/O component from where the CPU can read the value set on the switch. <H3><A NAME="section_1_4_3">2.4.3 Architecture of the Top Level Entity</A></H3> <P>The architecture has a head and a body, The head starts with the <STRONG>architecture</STRONG> keyword. The body starts with <STRONG>begin</STRONG> and ends with <STRONG>end</STRONG>, like this: <P><br> <pre class="vhdl"> 43 architecture Behavioral of avr_fpga is <pre class="filename"> src/avr_fpga.vhd </pre></pre> <pre class="vhdl"> 107 begin <pre class="filename"> src/avr_fpga.vhd </pre></pre> <pre class="vhdl"> 184 end Behavioral; <pre class="filename"> src/avr_fpga.vhd </pre></pre> <P><BR> <BR> <H4><A NAME="section_1_4_3_1">2.4.3.1 Architecture Header</A></H4> <P>As we have seen in the first figure in this lesson, the top level uses 3 components: <STRONG>cpu</STRONG>, <STRONG>io</STRONG>, and <STRONG>seg</STRONG>. These components have to be declared in the header of the architecture. The architecture contains component declarations, signal declarations and others. We normally declare components and signals in the following order: <UL> <LI>declaration of functions <LI>declaration of constants <LI>declaration of the first component (type) <LI>declaration of signals driven by (an instance of) the first component <LI>declaration of the second component (type) <LI>declaration of signals driven by (an instance of) the second component <LI>... <LI>declaration of signals driven by local processes and the like. </UL> <P>The first component declaration <STRONG>cpu_core</STRONG> and the signals driven by its instances are: <P><br> <pre class="vhdl"> 45 component cpu_core 46 port ( I_CLK : in std_logic; 47 I_CLR : in std_logic; 48 I_INTVEC : in std_logic_vector( 5 downto 0); 49 I_DIN : in std_logic_vector( 7 downto 0); 50 51 Q_OPC : out std_logic_vector(15 downto 0); 52 Q_PC : out std_logic_vector(15 downto 0); 53 Q_DOUT : out std_logic_vector( 7 downto 0); 54 Q_ADR_IO : out std_logic_vector( 7 downto 0); 55 Q_RD_IO : out std_logic; 56 Q_WE_IO : out std_logic); 57 end component; 58 59 signal C_PC : std_logic_vector(15 downto 0); 60 signal C_OPC : std_logic_vector(15 downto 0); 61 signal C_ADR_IO : std_logic_vector( 7 downto 0); 62 signal C_DOUT : std_logic_vector( 7 downto 0); 63 signal C_RD_IO : std_logic; 64 signal C_WE_IO : std_logic; <pre class="filename"> src/avr_fpga.vhd </pre></pre> <P> <P><br> <P>The second component declaration <STRONG>io</STRONG> and its signals are: <P><br> <pre class="vhdl"> 66 component io 67 port ( I_CLK : in std_logic; 68 I_CLR : in std_logic; 69 I_ADR_IO : in std_logic_vector( 7 downto 0); 70 I_DIN : in std_logic_vector( 7 downto 0); 71 I_RD_IO : in std_logic; 72 I_WE_IO : in std_logic; 73 I_SWITCH : in std_logic_vector( 7 downto 0); 74 I_RX : in std_logic; 75 76 Q_7_SEGMENT : out std_logic_vector( 6 downto 0); 77 Q_DOUT : out std_logic_vector( 7 downto 0); 78 Q_INTVEC : out std_logic_vector(5 downto 0); 79 Q_LEDS : out std_logic_vector( 1 downto 0); 80 Q_TX : out std_logic); 81 end component; 82 83 signal N_INTVEC : std_logic_vector( 5 downto 0); 84 signal N_DOUT : std_logic_vector( 7 downto 0); 85 signal N_TX : std_logic; 86 signal N_7_SEGMENT : std_logic_vector( 6 downto 0); <pre class="filename"> src/avr_fpga.vhd </pre></pre> <P> <P><br> <P><STRONG>Note:</STRONG> Normally we would have used <STRONG>I_</STRONG> as a prefix for signals driven by instance <STRONG>ino</STRONG> of <STRONG>io</STRONG>. This conflicts, however, with the prefix reserved for inputs and we have used the next letter <STRONG>n</STRONG> of <STRONG>ino</STRONG> as prefix instead. <P>The last component is <STRONG>seg</STRONG>: <P><br> <pre class="vhdl"> 88 component segment7 89 port ( I_CLK : in std_logic; 90 91 I_CLR : in std_logic; 92 I_OPC : in std_logic_vector(15 downto 0); 93 I_PC : in std_logic_vector(15 downto 0); 94 95 Q_7_SEGMENT : out std_logic_vector( 6 downto 0)); 96 end component; 97 98 signal S_7_SEGMENT : std_logic_vector( 6 downto 0); <pre class="filename"> src/avr_fpga.vhd </pre></pre> <P> <P><br> <P>The local signals, which are not driven by any component, but by local processes and inputs of the entity, are: <P><br> <pre class="vhdl"> 100 signal L_CLK : std_logic := '0'; 101 signal L_CLK_CNT : std_logic_vector( 2 downto 0) := "000"; 102 signal L_CLR : std_logic; -- reset, active low 103 signal L_CLR_N : std_logic := '0'; -- reset, active low 104 signal L_C1_N : std_logic := '0'; -- switch debounce, active low 105 signal L_C2_N : std_logic := '0'; -- switch debounce, active low 106 107 begin <pre class="filename"> src/avr_fpga.vhd </pre></pre> <P> <P><br> <P>The <STRONG>begin</STRONG> keyword in the last line marks the end of the header of the architecture and the start of its body. <H4><A NAME="section_1_4_3_2">2.4.3.2 Architecture Body</A></H4> <P>We normally use the following order in the architecture body: <UL> <LI>components instantiated <LI>processes <LI>local signal assignments </UL> <P>Thus the architecture body is more or less using the same order as the architecture header. The component instantiations instantiate one or more instances of a component type and connect the "ports" of the instantiated component to the signals in the architecture. <P>The first component declared was <STRONG>cpu</STRONG> so we also instantiate it first: <P><br> <pre class="vhdl"> 109 cpu : cpu_core 110 port map( I_CLK => L_CLK, 111 I_CLR => L_CLR, 112 I_DIN => N_DOUT, 113 I_INTVEC => N_INTVEC, 114 115 Q_ADR_IO => C_ADR_IO, 116 Q_DOUT => C_DOUT, 117 Q_OPC => C_OPC, 118 Q_PC => C_PC, 119 Q_RD_IO => C_RD_IO, 120 Q_WE_IO => C_WE_IO); <pre class="filename"> src/avr_fpga.vhd </pre></pre> <P> <P><br> <P>The first line instantiates a component of type <STRONG>cpu_core</STRONG> and calls the instance <STRONG>cpu</STRONG>. The following lines map the names of the ports in the component declaration (in the architecture header) to either inputs of the entity, outputs of the entity, or signals declared in the architecture header. <P>We take <STRONG>cpu</STRONG> as an opportunity to explain our naming convention for signals. Our rule for entity inputs and outputs has the consequence that all left sides of the port map have either an <STRONG>I_</STRONG> prefix or an <STRONG>O_</STRONG> prefix. This follows from the fact that a component instantiated in one architecture corresponds to an entity declared in some other VHDL file and there the <STRONG>I_</STRONG> or <STRONG>O_</STRONG> convention applies, <P>The next observation is that all component outputs either drive an entity output or a local signal that starts with the letter chosen for the instantiated component. This is the C_ in the <STRONG>cpu</STRONG> case. The <STRONG>cpu</STRONG> does not drive an entity output directly (so all outputs map to <STRONG>C_</STRONG> signals), but in the <STRONG>io</STRONG> outputs there is one driving an entity output (see below). <P>Finally the component inputs can be driven from more or less anywhere, but from the prefix (<STRONG>L_</STRONG> or not) we can see if the signal is directly driven by another component (when the prefix is not <STRONG>L_</STRONG>) or by some logic defined further down in the architecture (signal assignments, processes). <P>Thus for the <STRONG>cpu</STRONG> component we can already tell that this component drives a number of local signals (that are not entity outputs but inputs to other components or local processes)> These signals are those on the right side of the port map starting with <STRONG>C_</STRONG>. We can also tell that there are some local processes generating a clock signal <STRONG>L_CLK</STRONG> and a reset signal <STRONG>L_CLR</STRONG>, and the <STRONG>ino</STRONG> component (which uses prefix <STRONG>N_</STRONG>) drives an interrupt vector <STRONG>N_INTVEC</STRONG> and a data bus <STRONG>N_DOUT</STRONG>. <P>The next two components being instantiated are <STRONG>ino</STRONG> of type <STRONG>io</STRONG> and <STRONG>seg</STRONG> of type <STRONG>segment7</STRONG>: <P><br> <pre class="vhdl"> 122 ino : io 123 port map( I_CLK => L_CLK, 124 I_CLR => L_CLR, 125 I_ADR_IO => C_ADR_IO, 126 I_DIN => C_DOUT, 127 I_RD_IO => C_RD_IO, 128 I_RX => I_RX, 129 I_SWITCH => I_SWITCH(7 downto 0), 130 I_WE_IO => C_WE_IO, 131 132 Q_7_SEGMENT => N_7_SEGMENT, 133 Q_DOUT => N_DOUT, 134 Q_INTVEC => N_INTVEC, 135 Q_LEDS => Q_LEDS(1 downto 0), 136 Q_TX => N_TX); 137 138 seg : segment7 139 port map( I_CLK => L_CLK, 140 I_CLR => L_CLR, 141 I_OPC => C_OPC, 142 I_PC => C_PC, 143 144 Q_7_SEGMENT => S_7_SEGMENT); <pre class="filename"> src/avr_fpga.vhd </pre></pre> <P> <P><br> <P>Then come the local processes. The first process divides the 100 MHz input clock from the board into a 25 MHz clock used by the CPU. The design can, with some tuning of the timing optimizations, run at 33 MHz, but for our purposes we are happy with 25 MHz. <P><br> <pre class="vhdl"> 148 clk_div : process(I_CLK_100) 149 begin 150 if (rising_edge(I_CLK_100)) then 151 L_CLK_CNT <= L_CLK_CNT + "001"; 152 if (L_CLK_CNT = "001") then 153 L_CLK_CNT <= "000"; 154 L_CLK <= not L_CLK; 155 end if; 156 end if; 157 end process; <pre class="filename"> src/avr_fpga.vhd </pre></pre> <P> <P><br> <P>The second process is <STRONG>deb</STRONG>. It debounces the push-buttons used to reset the <STRONG>cpu</STRONG> and <STRONG>ino</STRONG> components. When either button is pushed ('0' on <STRONG>SWITCH(8)</STRONG> or <STRONG>SWITCH(9)</STRONG>) then <STRONG>CLR_N</STRONG> goes low immediately and stays low for two more cycles after the button was released. <P><br> <pre class="vhdl"> 161 deb : process(L_CLK) 162 begin 163 if (rising_edge(L_CLK)) then 164 -- switch debounce 165 if ((I_SWITCH(8) = '0') or (I_SWITCH(9) = '0')) then -- pushed 166 L_CLR_N <= '0'; 167 L_C2_N <= '0'; 168 L_C1_N <= '0'; 169 else -- released 170 L_CLR_N <= L_C2_N; 171 L_C2_N <= L_C1_N; 172 L_C1_N <= '1'; 173 end if; 174 end if; 175 end process; <pre class="filename"> src/avr_fpga.vhd </pre></pre> <P> <P><br> <P>Finally we have the signals driven directly from other signals. This kind of signal assignments are the same as processes, but use a simpler syntax for frequently used logic. <P><br> <pre class="vhdl"> 177 L_CLR <= not L_CLR_N; 178 179 Q_LEDS(2) <= I_RX; 180 Q_LEDS(3) <= N_TX; 181 Q_7_SEGMENT <= N_7_SEGMENT when (I_SWITCH(7) = '1') else S_7_SEGMENT; 182 Q_TX <= N_TX; <pre class="filename"> src/avr_fpga.vhd </pre></pre> <P> <P><br> <P><STRONG>CLR</STRONG> is generated by inverting <STRONG>CLR_N</STRONG>. The serial input and the serial output are visualized by means of two LEDs. The 7 segment output can be driven from two sources: from a software controlled I/O register in the I/O unit, or from the seven segment component (that shows the current PC and opcode) being executed. The latter component is quite useful for debugging purposes. <P><STRONG>Note:</STRONG> We use a <STRONG>_N</STRONG> suffix to denote an active low signal. Active low signals normally come from some FPGA pin since inside the FPGA active low signals have no advantage over active high signals. In the good old TTL days active low signals were preferred for strobe signals since the HIGH to LOW transition in TTL was faster than the LOW to high transition. Some active low signals we see today are left-overs from those days.<BR> Another common case is switches and push-buttons that are held high with a pull-up resistor when open and short-cut to ground when the switch is closed. <H2><A NAME="section_1_5">2.5 Component Tree</A></H2> <P>The following figure shows the breakdown of almost all components in our design. Only the memory modules in <STRONG>sram</STRONG> and <STRONG>pmem</STRONG> and the individual registers in <STRONG>regs</STRONG> are hidden because they would blow up the structure without providing too much information. <P><br> <P><img src="Component_tree.png"> <P><br> <P>We have already discussed the top level <STRONG>fpga</STRONG> and its 3 components <STRONG>cpu</STRONG>, <STRONG>ino</STRONG>, and <STRONG>seg</STRONG>. <P>The <STRONG>cpu</STRONG> will be further broken down into a data path <STRONG>dpath</STRONG>, an opcode decode <STRONG>odec</STRONG>, and an opcode fetch <STRONG>opcf</STRONG>. The data path consist of a 16-bit ALU <STRONG>alui</STRONG>, a register file <STRONG>regs</STRONG>, and a data memory <STRONG>sram</STRONG>. The opcode fetch contains a program counter <STRONG>pcnt</STRONG> and a program memory <STRONG>pmem</STRONG>. <P>The <STRONG>ino</STRONG> contains a <STRONG>uart</STRONG> that is further broken down into a baud rate generator <STRONG>baud</STRONG>, a serial receiver <STRONG>rx</STRONG>, and a serial transmitter <STRONG>tx</STRONG>. <P><hr><BR> <table class="ttop"><th class="tpre"><a href="01_Introduction_and_Overview.html">Previous Lesson</a></th><th class="ttop"><a href="toc.html">Table of Content</a></th><th class="tnxt"><a href="03_Pipelining.html">Next Lesson</a></th></table> </BODY> </HTML>
Go to most recent revision | Compare with Previous | Blame | View Log