URL https://opencores.org/ocsvn/cpu_lecture/cpu_lecture/trunk

Subversion Repositories cpu_lecture

[/] [cpu_lecture/] [trunk/] [html/] [05_Opcode_Fetch.html] - Blame information for rev 8

Go to most recent revision | Details | Compare with Previous | View Log


<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<HTML>
<HEAD>
<TITLE>html/Opcode_Fetch</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="04_Cpu_Core.html">Previous Lesson</a></th><th class="ttop"><a href="toc.html">Table of Content</a></th><th class="tnxt"><a href="06_Data_Path.html">Next Lesson</a></th></table>
<hr>
 
<H1><A NAME="section_1">5 OPCODE FETCH</A></H1>
 
<P>In this lesson we will design the opcode fetch stage of the CPU core.
The opcode fetch stage is the simplest stage in the pipeline.
It is the stage that put life into the CPU core by generating a sequence
of opcodes that are then decoded and executed. The opcode fetch stage
is sometimes called the <STRONG>sequencer</STRONG> of the CPU.
 
<P>Since we use the Harvard architecture with separate program and data
memories, we can simply instantiate the program memory in the opcode fetch
stage. If you need more memory than your FPGA provides internally, then you
can design address and data buses towards an external memory instead
(or in addition). Most current FPGAs provide a lot of internal memory,
so we can keep things simple.
 
<P>The opcode fetch stage contains a sub-component <STRONG>pmem</STRONG>, which is
is the program memory. The main purpose of the opcode fetch stage is to
manipulate the program counter (<STRONG>PC</STRONG>) and to produce opcodes.
The <STRONG>PC</STRONG> is a local signal:
 
<P><br>
 
<pre class="vhdl">
 
 69     signal L_PC             : std_logic_vector(15 downto 0);
<pre class="filename">
src/opc_fetch.vhd
</pre></pre>
<P>
 
<P><br>
 
<P>The <STRONG>PC</STRONG> is updated on every clock with its next value. The <STRONG>T0</STRONG> output
is cleared when the <STRONG>WAIT</STRONG> signal is raised.
This causes the T0 output to be '1' on the first cycle of a 2 cycle
instruction and '0' on the second cycle:
 
<P><br>
 
<pre class="vhdl">
 
 86        lpc: process(I_CLK)
 87         begin
 88             if (rising_edge(I_CLK)) then
 89                 L_PC <= L_NEXT_PC;
 90                 L_T0 <= not L_WAIT;
 91             end if;
 92         end process;
<pre class="filename">
src/opc_fetch.vhd
</pre></pre>
<P>
 
<P><br>
 
<P>The next value of the <STRONG>PC</STRONG> depends on the <STRONG>CLR</STRONG>, <STRONG>WAIT</STRONG>, <STRONG>LOAD_PC</STRONG>, and
<STRONG>LONG_OP</STRONG> signals:
 
<P><br>
 
<pre class="vhdl">
 
 94         L_NEXT_PC <= X"0000"        when (I_CLR     = '1')
 95                 else L_PC           when (L_WAIT    = '1')
 96                 else I_NEW_PC       when (I_LOAD_PC = '1')
 97                 else L_PC + X"0002" when (L_LONG_OP = '1')
 98                 else L_PC + X"0001";
<pre class="filename">
src/opc_fetch.vhd
</pre></pre>
<P>
 
<P><br>
 
<P>The <STRONG>CLR</STRONG> signal, which overrides all others, resets the <STRONG>PC</STRONG> to 0. It
is generated at power on and when the reset input of the CPU is
asserted. The <STRONG>WAIT</STRONG> signal freezes the <STRONG>PC</STRONG> at its current value. It
is used when an instruction needs two <STRONG>CLK</STRONG> cycles to complete. The
<STRONG>LOAD_PC</STRONG> signal causes the <STRONG>PC</STRONG> to be loaded with the value on the
<STRONG>NEW_PC</STRONG> input. The <STRONG>LOAD_PC</STRONG> signal is driven by the execution stage
when a jump instruction is executed. If neither <STRONG>CLR</STRONG>, <STRONG>WAIT</STRONG>, or <STRONG>LOAD_PC</STRONG>
is present then the <STRONG>PC</STRONG> is advanced to the next instruction. If the current
instruction is one of <STRONG>JMP</STRONG>, <STRONG>CALL</STRONG>, <STRONG>LDS</STRONG> and <STRONG>STS</STRONG>, then it has a length
of two 16-bit words and <STRONG>LONG_OP</STRONG> is set. This causes the PC to be
incremented by 2 rather than by the normal instruction length of 1:
 
<P><br>
 
<pre class="vhdl">
 
100         -- Two word opcodes:
101         --
102         --        9       3210
103         -- 1001 000d dddd 0000 kkkk kkkk kkkk kkkk - LDS
104         -- 1001 001d dddd 0000 kkkk kkkk kkkk kkkk - SDS
105         -- 1001 010k kkkk 110k kkkk kkkk kkkk kkkk - JMP
106         -- 1001 010k kkkk 111k kkkk kkkk kkkk kkkk - CALL
107         --
108         L_LONG_OP <= '1' when (((P_OPC(15 downto  9) = "1001010") and
109                                 (P_OPC( 3 downto  2) = "11"))       -- JMP, CALL
110                            or  ((P_OPC(15 downto 10) = "100100") and
111                                 (P_OPC( 3 downto  0) = "0000")))    -- LDS, STS
112                 else '0';
<pre class="filename">
src/opc_fetch.vhd
</pre></pre>
<P>
 
<P><br>
 
<P>The <STRONG>CLR</STRONG>, <STRONG>SKIP</STRONG>, and <STRONG>I_INTVEC</STRONG> inputs are used to force a <STRONG>NOP</STRONG>
(no operation) opcode or an "interrupt opcode" onto the output of the
opcode fetch stage. An interrupt opcode is an opcode that does not
belong to the normal instruction set of the CPU (and is therefore not
generated by assemblers or compilers), but is used internally to trigger
interrupt processing (pushing of the PC, clearing the interrupt enable flag,
and jumping to specific locations) further down in the pipeline.
 
<P><br>
 
<pre class="vhdl">
 
133         L_INVALIDATE <= I_CLR or I_SKIP;
134
135         Q_OPC <= X"00000000" when (L_INVALIDATE = '1')
136             else P_OPC       when (I_INTVEC(5) = '0')
137             else (X"000000" & "00" & I_INTVEC);     -- "interrupt opcode"
<pre class="filename">
src/opc_fetch.vhd
</pre></pre>
<P>
 
<P><br>
 
<P><STRONG>CLR</STRONG> is derived from the reset input and also resets the program counter.
<STRONG>SKIP</STRONG> comes from the execution stage and is used to invalidate parts
of the pipeline, for example when a decision was made to take a conditional
branch. This will be explained in more detail in the lesson about branching.
 
<H2><A NAME="section_1_1">5.1 Program Memory</A></H2>
 
<P>The program memory is declared as follows:
 
<P><br>
 
<pre class="vhdl">
 
 36     entity prog_mem is
 37         port (  I_CLK       : in  std_logic;
 38
 39                 I_WAIT      : in  std_logic;
 40                 I_PC        : in  std_logic_vector(15 downto 0); -- word address
 41                 I_PM_ADR    : in  std_logic_vector(11 downto 0); -- byte address
 42
 43                 Q_OPC       : out std_logic_vector(31 downto 0);
 44                 Q_PC        : out std_logic_vector(15 downto 0);
 45                 Q_PM_DOUT   : out std_logic_vector( 7 downto 0));
 46     end prog_mem;
<pre class="filename">
src/prog_mem.vhd
</pre></pre>
<P>
 
<P><br>
 
<H3><A NAME="section_1_1_1">5.2.1 Dual Port Memory</A></H3>
 
<P>The program memory is a dual port memory. This means that two different
memory locations can be read or written at the same time. We don't
write to the program memory, be we would like to read two addresses
at the same time. The reason are the <STRONG>LPM</STRONG> (load program memory)
instructions. These instructions read from the program memory while
the program memory is fetching the next instructions. In a way these
instructions violate the Harvard architecture, but on the other hand
they are extremely useful for string constants in C. Rather than
initializing the (typically smaller) data memory with these constants,
one can leave them in program memory and access them using <STRONG>LPM</STRONG>
instructions,
 
<P>Without a dual port memory, we would have needed to stop the pipeline
during the execution of <STRONG>LPM</STRONG> instructions. Use of dual port memory
avoids this additional complexity.
 
<P>The second port used for <STRONG>LPM</STRONG> instructions consists of the address
input <STRONG>PM_ADR</STRONG> and the data output <STRONG>PM_DOUT</STRONG>. <STRONG>PM_ADR</STRONG> is a 12-bit
byte address (and consequently <STRONG>PM_DOUT</STRONG> is an 8-bit output. In
contrast, the other port uses an 11-bit word address.
 
<P>The other signals of the program memory belong to the first port
which is used for opcode fetches.
 
<H3><A NAME="section_1_1_2">5.2.2 Look-ahead for two word instructions</A></H3>
 
<P>The vast majority of AVR instructions are single-word (16-bit) instructions.
There are 4 exceptions, which are <STRONG>CALL</STRONG>, <STRONG>JMP</STRONG>, <STRONG>LDS</STRONG>, and <STRONG>STS</STRONG>. These
instructions have addresses (the target address for <STRONG>CALL</STRONG> and <STRONG>JMP</STRONG> and
data memory address for $LDS# and <STRONG>STS</STRONG>) in the word following the opcode.
 
<P>There are two ways to handle such opcodes. One way is to look back in the
pipeline when the second word is needed. When one of these instructions
reaches the execution stage, then the next word is clocked into the decoding
stage (so we could fetch it from there). It might lead to complications,
however, when it comes to invalidating the pipeline, insertion of interrupts
and the like.
 
<P>The other way, and the one we choose, is to divide the program memory into
an even memory and an odd memory. The internal memory modules in an FPGA are
anyhow small and therefore using two memories is almost as simple as using
one (both would consist of a number of smaller modules).
 
<P>There are two cases to consider: (1) an even <STRONG>PC</STRONG> (shown on the left of the
following figure) and (2) an odd <STRONG>PC</STRONG> shown on the right. In both cases do
we want the (combined) memory at address <STRONG>PC</STRONG> to be stored in the lower word
of the <STRONG>OPC</STRONG> output and the next word (at <STRONG>PC</STRONG>+1) in the upper word of <STRONG>OPC</STRONG>.
 
<P><br>
 
<P><img src="opcode_fetch_2.png">
 
<P><br>
 
<P>We observe the following:
 
<UL>
  <LI>the odd memory address is <STRONG>PC[10:1]</STRONG> in both cases.
  <LI>the even memory address is  <STRONG>PC[10:1]</STRONG> + <STRONG>PC[0]</STRONG> in both cases.
  <LI>the data outputs of the two memories are either straight or crossed,
  depending (only) on <STRONG>PC[0]</STRONG>.
</UL>
<P>In VHDL, we express this like:
 
<P><br>
 
<pre class="vhdl">
 
252         L_PC_O <= I_PC(10 downto 1);
253         L_PC_E <= I_PC(10 downto 1) + ("000000000" & I_PC(0));
254         Q_OPC(15 downto  0) <= M_OPC_E when L_PC_0 = '0' else M_OPC_O;
255         Q_OPC(31 downto 16) <= M_OPC_E when L_PC_0 = '1' else M_OPC_O;
<pre class="filename">
src/prog_mem.vhd
</pre></pre>
<P>
 
<P><br>
 
<P>The output multiplexer uses the <STRONG>PC</STRONG> and <STRONG>PM_ADR</STRONG> of the previous cycle,
so we need to remember the lower bit(s) in signals <STRONG>PC_0</STRONG> and <STRONG>PM_ADR_1_0</STRONG>:
 
<P><br>
 
<pre class="vhdl">
 
224         pc0: process(I_CLK)
225         begin
226             if (rising_edge(I_CLK)) then
227                 Q_PC <= I_PC;
228                 L_PM_ADR_1_0 <= I_PM_ADR(1 downto 0);
229                 if ((I_WAIT = '0')) then
230                     L_PC_0 <= I_PC(0);
231                 end if;
232             end if;
233         end process;
<pre class="filename">
src/prog_mem.vhd
</pre></pre>
<P>
 
<P><br>
 
<P>The split into two memories makes the entire program memory 32-bit
wide. Note that the PC is a word address, while PM_ADR is a byte address.
 
<H3><A NAME="section_1_1_3">5.2.3 Memory block instantiation and initialization.</A></H3>
 
<P>The entire program memory consists of 8 memory modules, four
for the even half (components <STRONG>pe_0</STRONG>, <STRONG>pe_1</STRONG>, <STRONG>pe_2</STRONG>, and <STRONG>pe_3</STRONG>) and
four for the odd part (<STRONG>po_0</STRONG>, <STRONG>po_1</STRONG>, <STRONG>po_2</STRONG>, and <STRONG>po_3</STRONG>).
 
<P>We explain the first module in detail:
 
<P><br>
 
<pre class="vhdl">
 
102         pe_0 : RAMB4_S4_S4 ---------------------------------------------------------
103         generic map(INIT_00 => pe_0_00, INIT_01 => pe_0_01, INIT_02 => pe_0_02,
104                     INIT_03 => pe_0_03, INIT_04 => pe_0_04, INIT_05 => pe_0_05,
105                     INIT_06 => pe_0_06, INIT_07 => pe_0_07, INIT_08 => pe_0_08,
106                     INIT_09 => pe_0_09, INIT_0A => pe_0_0A, INIT_0B => pe_0_0B,
107                     INIT_0C => pe_0_0C, INIT_0D => pe_0_0D, INIT_0E => pe_0_0E,
108                     INIT_0F => pe_0_0F)
109         port map(ADDRA => L_PC_E,                   ADDRB => I_PM_ADR(11 downto 2),
110                  CLKA  => I_CLK,                    CLKB  => I_CLK,
111                  DIA   => "0000",                   DIB   => "0000",
112                  ENA   => L_WAIT_N,                 ENB   => '1',
113                  RSTA  => '0',                      RSTB  => '0',
114                  WEA   => '0',                      WEB   => '0',
115                  DOA   => M_OPC_E(3 downto 0),      DOB   => M_PMD_E(3 downto 0));
<pre class="filename">
src/prog_mem.vhd
</pre></pre>
<P>
 
<P><br>
 
<P>The first line instantiates a module of type <STRONG>RAMB4_S4_S4</STRONG>, which
is a dual-port memory module with two 4-bit ports. For a Xilinx
FPGA you can used these modules directly by uncommenting the
use of the UNISIM library. For functional simulation we have provided
a <STRONG>RAMB4_S4_S4.vhd</STRONG> component in the test directory. This component
emulates the real <STRONG>RAMB4_S4_S4</STRONG> as good as needed.
 
<P>The next lines define the content of each memory module by means of
a generic map. The elements of the generic map (like <STRONG>pe_0_00</STRONG>, <STRONG>pe_0_01</STRONG>, and
so forth) define the initial memory content of the instantiated module.
<STRONG>pe_0_00</STRONG>, <STRONG>pe_0_01</STRONG>, .. are themselves defined in <STRONG>prog_mem_content.vhd</STRONG>
which is included in the library section:
 
<P><br>
 
<pre class="vhdl">
 
 34     use work.prog_mem_content.all;
<pre class="filename">
src/prog_mem.vhd
</pre></pre>
<P>
 
<P><br>
 
<P>The process from a C (or C++) source file <STRONG>hello.c</STRONG> to the final
FPGA is then:
 
<UL>
  <LI>write, compile, and link <STRONG>hello.c</STRONG> (produces <STRONG>hello.hex</STRONG>).
  <LI>generate <STRONG>prog_mem_content.vhd</STRONG> from <STRONG>hello.hex</STRONG> (by means of tool
  <STRONG>make_mem</STRONG>, which is provided with this lecture).
  <LI>simulate, synthesize and implement the design.
  <LI>create a bitmap file.
  <LI>flash the FPGA (or serial PROM).
</UL>
<P>There are other ways of initializing the memory modules, such as
updating sections of the bitmap file, but we found the above sequence
easier to use.
 
<P>After the generic map, follows the port map of the memory module.
The two addresses <STRONG>ADDRA</STRONG> and <STRONG>ADDRB</STRONG> of the two ports come from
the <STRONG>PC</STRONG> and <STRONG>PM_ADR</STRONG> inputs as already described.
 
<P>Both ports are clocked from <STRONG>CLK</STRONG>. Since the program memory is read-only,
the <STRONG>DIA</STRONG> and <STRONG>DIB</STRONG> inputs are not used (set to 0000) and <STRONG>WEA</STRONG> and <STRONG>WEB</STRONG>
are 0. <STRONG>RSTA</STRONG> and <STRONG>RSTB</STRONG> are not used either and are set to 0.
<STRONG>ENA</STRONG> is used for keeping the <STRONG>OPC</STRONG> when the pipeline is stopped, while
<STRONG>ENB</STRONG> is not used. The memory outputs <STRONG>DOA</STRONG> and <STRONG>DOB</STRONG> go to the output
multiplexers of the two ports.
 
<H3><A NAME="section_1_1_4">5.2.3 Delayed PC</A></H3>
 
<P><STRONG>Q_PC</STRONG> is <STRONG>I_PC</STRONG> delayed by one clock. The program memory is a synchronous
memory, which has the consequence that the program memory output <STRONG>OPC</STRONG>
for a given <STRONG>I_PC</STRONG> is always one clock cycle behind as shown in the figure
below on the left.
 
<P><br>
 
<P><img src="opcode_fetch_1.png">
 
<P><br>
 
<P>By clocking <STRONG>I_PC</STRONG> once, we re-align <STRONG>Q_PC</STRONG> and <STRONG>OPC</STRONG> as shown on the right:
 
<P><br>
 
<pre class="vhdl">
 
227                 Q_PC <= I_PC;
<pre class="filename">
src/prog_mem.vhd
</pre></pre>
<P>
 
<P><br>
 
<H2><A NAME="section_1_2">5.3 Two Cycle Opcodes</A></H2>
 
<P>The vast majority of instructions executes in one cycle. Some need
two cycles because they involve reading of a synchronous memory. For
these signals <STRONG>WAIT</STRONG> signal is generated on the first cycle:
 
<P><br>
 
<pre class="vhdl">
 
114         -- Two cycle opcodes:
115         --
116         -- 1001 000d dddd .... - LDS etc.
117         -- 1001 0101 0000 1000 - RET
118         -- 1001 0101 0001 1000 - RETI
119         -- 1001 1001 AAAA Abbb - SBIC
120         -- 1001 1011 AAAA Abbb - SBIS
121         -- 1111 110r rrrr 0bbb - SBRC
122         -- 1111 111r rrrr 0bbb - SBRS
123         --
124         L_WAIT <= '0'  when (L_INVALIDATE = '1')
125              else '0'  when (I_INTVEC(5)  = '1')
126              else L_T0 when ((P_OPC(15 downto   9) = "1001000" )    -- LDS etc.
127                          or  (P_OPC(15 downto   8) = "10010101")    -- RET etc.
128                          or  ((P_OPC(15 downto 10) = "100110")      -- SBIC, SBIS
129                            and P_OPC(8) = '1')
130                          or  (P_OPC(15 downto  10) = "111111"))     -- SBRC, SBRS
131             else  '0';
<pre class="filename">
src/opc_fetch.vhd
</pre></pre>
<P>
 
<P><br>
 
<H2><A NAME="section_1_3">5.4 Interrupts</A></H2>
 
<P>The opcode fetch stage is also responsible for part of the interrupt
handling. Interrupts are generated in the I/O block by setting
<STRONG>INTVEC</STRONG> to a value with the highest bit set:
 
<P><br>
 
<pre class="vhdl">
 
169                     if (L_RX_INT_ENABLED and U_RX_READY) = '1' then
170                         if (L_INTVEC(5) = '0') then     -- no interrupt pending
171                             L_INTVEC <= "101011";       -- _VECTOR(11)
172                         end if;
173                     elsif (L_TX_INT_ENABLED and not U_TX_BUSY) = '1' then
174                         if (L_INTVEC(5) = '0') then     -- no interrupt pending
175                             L_INTVEC <= "101100";       -- _VECTOR(12)
176                         end if;
<pre class="filename">
src/io.vhd
</pre></pre>
<P>
 
<P><br>
 
<P>The highest bit of <STRONG>INTVEC</STRONG> indicates that the lower bits contain a
valid interrupt number. <STRONG>INTVEC</STRONG> proceeds to the cpu core where
the upper bit is <STRONG>and</STRONG>'ed with the global interrupt enable bit (in the
status register):
 
<P><br>
 
<pre class="vhdl">
 
241         L_INTVEC_5 <= I_INTVEC(5) and R_INT_ENA;
<pre class="filename">
src/cpu_core.vhd
</pre></pre>
<P>
 
<P><br>
 
<P>The (possibly modified) <STRONG>INTVEC</STRONG> then proceeds to the opcode fetch stage.
If the the global interrupt enable bit was set, then the next valid
opcode is replaced by an "interrupt opcode":
 
<P><br>
 
<pre class="vhdl">
 
135         Q_OPC <= X"00000000" when (L_INVALIDATE = '1')
136             else P_OPC       when (I_INTVEC(5) = '0')
137             else (X"000000" & "00" & I_INTVEC);     -- "interrupt opcode"
<pre class="filename">
src/opc_fetch.vhd
</pre></pre>
<P>
 
<P><br>
 
<P>The interrupt opcode uses a gap after the <STRONG>NOP</STRONG> instruction in the opcode
set of the AVR CPU. When the interrupt opcode reaches the execution
stage then is causes a branch to the location determined by the lower
bits of <STRONG>INTVEC</STRONG>, pushes the program counter, and clears the interrupt
enable bit. This happens a few clock cycles later. In the meantime
the opcode fetch stage keeps inserting interrupt instructions into
the pipeline. These additional interrupt instructions are being
invalidated by the execution stage when the first interrupt instruction
reaches the execution stage.
 
<P><hr><BR>
<table class="ttop"><th class="tpre"><a href="04_Cpu_Core.html">Previous Lesson</a></th><th class="ttop"><a href="toc.html">Table of Content</a></th><th class="tnxt"><a href="06_Data_Path.html">Next Lesson</a></th></table>
</BODY>
</HTML>

Browse

Tools

Subversion Repositories cpu_lecture

[/] [cpu_lecture/] [trunk/] [html/] [05_Opcode_Fetch.html] - Blame information for rev 8

Line No.	Rev	Author	Line
1	2	jsauermann	`<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"`
2			`"http://www.w3.org/TR/html4/strict.dtd">`
3			`<HTML>`
4			`<HEAD>`
5			`<TITLE>html/Opcode_Fetch</TITLE>`
6			`<META NAME="generator" CONTENT="HTML::TextToHTML v2.46">`
7			`<LINK REL="stylesheet" TYPE="text/css" HREF="lecture.css">`
8			`</HEAD>`
9			`<BODY>`
10			`<P><table class="ttop"><th class="tpre"><a href="04_Cpu_Core.html">Previous Lesson</a></th><th class="ttop"><a href="toc.html">Table of Content</a></th><th class="tnxt"><a href="06_Data_Path.html">Next Lesson</a></th></table>`
11			`<hr>`
12
13			`<H1><A NAME="section_1">5 OPCODE FETCH</A></H1>`
14
15			`<P>In this lesson we will design the opcode fetch stage of the CPU core.`
16			`The opcode fetch stage is the simplest stage in the pipeline.`
17			`It is the stage that put life into the CPU core by generating a sequence`
18			`of opcodes that are then decoded and executed. The opcode fetch stage`
19			`is sometimes called the <STRONG>sequencer</STRONG> of the CPU.`
20
21			`<P>Since we use the Harvard architecture with separate program and data`
22			`memories, we can simply instantiate the program memory in the opcode fetch`
23			`stage. If you need more memory than your FPGA provides internally, then you`
24			`can design address and data buses towards an external memory instead`
25			`(or in addition). Most current FPGAs provide a lot of internal memory,`
26			`so we can keep things simple.`
27
28			`<P>The opcode fetch stage contains a sub-component <STRONG>pmem</STRONG>, which is`
29			`is the program memory. The main purpose of the opcode fetch stage is to`
30			`manipulate the program counter (<STRONG>PC</STRONG>) and to produce opcodes.`
31			`The <STRONG>PC</STRONG> is a local signal:`
32
33			`<P><br>`
34
35			`<pre class="vhdl">`
36
37			`69 signal L_PC : std_logic_vector(15 downto 0);`
38			`<pre class="filename">`
39			`src/opc_fetch.vhd`
40			`</pre></pre>`
41			`<P>`
42
43			`<P><br>`
44
45			`<P>The <STRONG>PC</STRONG> is updated on every clock with its next value. The <STRONG>T0</STRONG> output`
46			`is cleared when the <STRONG>WAIT</STRONG> signal is raised.`
47			`This causes the T0 output to be '1' on the first cycle of a 2 cycle`
48			`instruction and '0' on the second cycle:`
49
50			`<P><br>`
51
52			`<pre class="vhdl">`
53
54			`86 lpc: process(I_CLK)`
55			`87 begin`
56			`88 if (rising_edge(I_CLK)) then`
57			`89 L_PC <= L_NEXT_PC;`
58			`90 L_T0 <= not L_WAIT;`
59			`91 end if;`
60			`92 end process;`
61			`<pre class="filename">`
62			`src/opc_fetch.vhd`
63			`</pre></pre>`
64			`<P>`
65
66			`<P><br>`
67
68			`<P>The next value of the <STRONG>PC</STRONG> depends on the <STRONG>CLR</STRONG>, <STRONG>WAIT</STRONG>, <STRONG>LOAD_PC</STRONG>, and`
69			`<STRONG>LONG_OP</STRONG> signals:`
70
71			`<P><br>`
72
73			`<pre class="vhdl">`
74
75			`94 L_NEXT_PC <= X"0000" when (I_CLR = '1')`
76			`95 else L_PC when (L_WAIT = '1')`
77			`96 else I_NEW_PC when (I_LOAD_PC = '1')`
78			`97 else L_PC + X"0002" when (L_LONG_OP = '1')`
79			`98 else L_PC + X"0001";`
80			`<pre class="filename">`
81			`src/opc_fetch.vhd`
82			`</pre></pre>`
83			`<P>`
84
85			`<P><br>`
86
87			`<P>The <STRONG>CLR</STRONG> signal, which overrides all others, resets the <STRONG>PC</STRONG> to 0. It`
88			`is generated at power on and when the reset input of the CPU is`
89			`asserted. The <STRONG>WAIT</STRONG> signal freezes the <STRONG>PC</STRONG> at its current value. It`
90			`is used when an instruction needs two <STRONG>CLK</STRONG> cycles to complete. The`
91			`<STRONG>LOAD_PC</STRONG> signal causes the <STRONG>PC</STRONG> to be loaded with the value on the`
92			`<STRONG>NEW_PC</STRONG> input. The <STRONG>LOAD_PC</STRONG> signal is driven by the execution stage`
93			`when a jump instruction is executed. If neither <STRONG>CLR</STRONG>, <STRONG>WAIT</STRONG>, or <STRONG>LOAD_PC</STRONG>`
94			`is present then the <STRONG>PC</STRONG> is advanced to the next instruction. If the current`
95			`instruction is one of <STRONG>JMP</STRONG>, <STRONG>CALL</STRONG>, <STRONG>LDS</STRONG> and <STRONG>STS</STRONG>, then it has a length`
96			`of two 16-bit words and <STRONG>LONG_OP</STRONG> is set. This causes the PC to be`
97			`incremented by 2 rather than by the normal instruction length of 1:`
98
99			`<P><br>`
100
101			`<pre class="vhdl">`
102
103			`100 -- Two word opcodes:`
104			`101 --`
105			`102 -- 9 3210`
106			`103 -- 1001 000d dddd 0000 kkkk kkkk kkkk kkkk - LDS`
107			`104 -- 1001 001d dddd 0000 kkkk kkkk kkkk kkkk - SDS`
108			`105 -- 1001 010k kkkk 110k kkkk kkkk kkkk kkkk - JMP`
109			`106 -- 1001 010k kkkk 111k kkkk kkkk kkkk kkkk - CALL`
110			`107 --`
111			`108 L_LONG_OP <= '1' when (((P_OPC(15 downto 9) = "1001010") and`
112			`109 (P_OPC( 3 downto 2) = "11")) -- JMP, CALL`
113			`110 or ((P_OPC(15 downto 10) = "100100") and`
114			`111 (P_OPC( 3 downto 0) = "0000"))) -- LDS, STS`
115			`112 else '0';`
116			`<pre class="filename">`
117			`src/opc_fetch.vhd`
118			`</pre></pre>`
119			`<P>`
120
121			`<P><br>`
122
123			`<P>The <STRONG>CLR</STRONG>, <STRONG>SKIP</STRONG>, and <STRONG>I_INTVEC</STRONG> inputs are used to force a <STRONG>NOP</STRONG>`
124			`(no operation) opcode or an "interrupt opcode" onto the output of the`
125			`opcode fetch stage. An interrupt opcode is an opcode that does not`
126			`belong to the normal instruction set of the CPU (and is therefore not`
127			`generated by assemblers or compilers), but is used internally to trigger`
128			`interrupt processing (pushing of the PC, clearing the interrupt enable flag,`
129			`and jumping to specific locations) further down in the pipeline.`
130
131			`<P><br>`
132
133			`<pre class="vhdl">`
134
135			`133 L_INVALIDATE <= I_CLR or I_SKIP;`
136			`134`
137			`135 Q_OPC <= X"00000000" when (L_INVALIDATE = '1')`
138			`136 else P_OPC when (I_INTVEC(5) = '0')`
139			`137 else (X"000000" & "00" & I_INTVEC); -- "interrupt opcode"`
140			`<pre class="filename">`
141			`src/opc_fetch.vhd`
142			`</pre></pre>`
143			`<P>`
144
145			`<P><br>`
146
147			`<P><STRONG>CLR</STRONG> is derived from the reset input and also resets the program counter.`
148			`<STRONG>SKIP</STRONG> comes from the execution stage and is used to invalidate parts`
149			`of the pipeline, for example when a decision was made to take a conditional`
150			`branch. This will be explained in more detail in the lesson about branching.`
151
152			`<H2><A NAME="section_1_1">5.1 Program Memory</A></H2>`
153
154			`<P>The program memory is declared as follows:`
155
156			`<P><br>`
157
158			`<pre class="vhdl">`
159
160			`36 entity prog_mem is`
161			`37 port ( I_CLK : in std_logic;`
162			`38`
163			`39 I_WAIT : in std_logic;`
164			`40 I_PC : in std_logic_vector(15 downto 0); -- word address`
165			`41 I_PM_ADR : in std_logic_vector(11 downto 0); -- byte address`
166			`42`
167			`43 Q_OPC : out std_logic_vector(31 downto 0);`
168			`44 Q_PC : out std_logic_vector(15 downto 0);`
169			`45 Q_PM_DOUT : out std_logic_vector( 7 downto 0));`
170			`46 end prog_mem;`
171			`<pre class="filename">`
172			`src/prog_mem.vhd`
173			`</pre></pre>`
174			`<P>`
175
176			`<P><br>`
177
178			`<H3><A NAME="section_1_1_1">5.2.1 Dual Port Memory</A></H3>`
179
180			`<P>The program memory is a dual port memory. This means that two different`
181			`memory locations can be read or written at the same time. We don't`
182			`write to the program memory, be we would like to read two addresses`
183			`at the same time. The reason are the <STRONG>LPM</STRONG> (load program memory)`
184			`instructions. These instructions read from the program memory while`
185			`the program memory is fetching the next instructions. In a way these`
186			`instructions violate the Harvard architecture, but on the other hand`
187			`they are extremely useful for string constants in C. Rather than`
188			`initializing the (typically smaller) data memory with these constants,`
189			`one can leave them in program memory and access them using <STRONG>LPM</STRONG>`
190			`instructions,`
191
192			`<P>Without a dual port memory, we would have needed to stop the pipeline`
193			`during the execution of <STRONG>LPM</STRONG> instructions. Use of dual port memory`
194			`avoids this additional complexity.`
195
196			`<P>The second port used for <STRONG>LPM</STRONG> instructions consists of the address`
197			`input <STRONG>PM_ADR</STRONG> and the data output <STRONG>PM_DOUT</STRONG>. <STRONG>PM_ADR</STRONG> is a 12-bit`
198			`byte address (and consequently <STRONG>PM_DOUT</STRONG> is an 8-bit output. In`
199			`contrast, the other port uses an 11-bit word address.`
200
201			`<P>The other signals of the program memory belong to the first port`
202			`which is used for opcode fetches.`
203
204			`<H3><A NAME="section_1_1_2">5.2.2 Look-ahead for two word instructions</A></H3>`
205
206			`<P>The vast majority of AVR instructions are single-word (16-bit) instructions.`
207			`There are 4 exceptions, which are <STRONG>CALL</STRONG>, <STRONG>JMP</STRONG>, <STRONG>LDS</STRONG>, and <STRONG>STS</STRONG>. These`
208			`instructions have addresses (the target address for <STRONG>CALL</STRONG> and <STRONG>JMP</STRONG> and`
209			`data memory address for $LDS# and <STRONG>STS</STRONG>) in the word following the opcode.`
210
211			`<P>There are two ways to handle such opcodes. One way is to look back in the`
212			`pipeline when the second word is needed. When one of these instructions`
213			`reaches the execution stage, then the next word is clocked into the decoding`
214			`stage (so we could fetch it from there). It might lead to complications,`
215			`however, when it comes to invalidating the pipeline, insertion of interrupts`
216			`and the like.`
217
218			`<P>The other way, and the one we choose, is to divide the program memory into`
219			`an even memory and an odd memory. The internal memory modules in an FPGA are`
220			`anyhow small and therefore using two memories is almost as simple as using`
221			`one (both would consist of a number of smaller modules).`
222
223			`<P>There are two cases to consider: (1) an even <STRONG>PC</STRONG> (shown on the left of the`
224			`following figure) and (2) an odd <STRONG>PC</STRONG> shown on the right. In both cases do`
225			`we want the (combined) memory at address <STRONG>PC</STRONG> to be stored in the lower word`
226			`of the <STRONG>OPC</STRONG> output and the next word (at <STRONG>PC</STRONG>+1) in the upper word of <STRONG>OPC</STRONG>.`
227
228			`<P><br>`
229
230			`<P><img src="opcode_fetch_2.png">`
231
232			`<P><br>`
233
234			`<P>We observe the following:`
235
236			`<UL>`
237			`<LI>the odd memory address is <STRONG>PC[10:1]</STRONG> in both cases.`
238			`<LI>the even memory address is <STRONG>PC[10:1]</STRONG> + <STRONG>PC[0]</STRONG> in both cases.`
239			`<LI>the data outputs of the two memories are either straight or crossed,`
240			`depending (only) on <STRONG>PC[0]</STRONG>.`
241			`</UL>`
242			`<P>In VHDL, we express this like:`
243
244			`<P><br>`
245
246			`<pre class="vhdl">`
247
248			`252 L_PC_O <= I_PC(10 downto 1);`
249			`253 L_PC_E <= I_PC(10 downto 1) + ("000000000" & I_PC(0));`
250			`254 Q_OPC(15 downto 0) <= M_OPC_E when L_PC_0 = '0' else M_OPC_O;`
251			`255 Q_OPC(31 downto 16) <= M_OPC_E when L_PC_0 = '1' else M_OPC_O;`
252			`<pre class="filename">`
253			`src/prog_mem.vhd`
254			`</pre></pre>`
255			`<P>`
256
257			`<P><br>`
258
259			`<P>The output multiplexer uses the <STRONG>PC</STRONG> and <STRONG>PM_ADR</STRONG> of the previous cycle,`
260			`so we need to remember the lower bit(s) in signals <STRONG>PC_0</STRONG> and <STRONG>PM_ADR_1_0</STRONG>:`
261
262			`<P><br>`
263
264			`<pre class="vhdl">`
265
266			`224 pc0: process(I_CLK)`
267			`225 begin`
268			`226 if (rising_edge(I_CLK)) then`
269			`227 Q_PC <= I_PC;`
270			`228 L_PM_ADR_1_0 <= I_PM_ADR(1 downto 0);`
271			`229 if ((I_WAIT = '0')) then`
272			`230 L_PC_0 <= I_PC(0);`
273			`231 end if;`
274			`232 end if;`
275			`233 end process;`
276			`<pre class="filename">`
277			`src/prog_mem.vhd`
278			`</pre></pre>`
279			`<P>`
280
281			`<P><br>`
282
283			`<P>The split into two memories makes the entire program memory 32-bit`
284			`wide. Note that the PC is a word address, while PM_ADR is a byte address.`
285
286			`<H3><A NAME="section_1_1_3">5.2.3 Memory block instantiation and initialization.</A></H3>`
287
288			`<P>The entire program memory consists of 8 memory modules, four`
289			`for the even half (components <STRONG>pe_0</STRONG>, <STRONG>pe_1</STRONG>, <STRONG>pe_2</STRONG>, and <STRONG>pe_3</STRONG>) and`
290			`four for the odd part (<STRONG>po_0</STRONG>, <STRONG>po_1</STRONG>, <STRONG>po_2</STRONG>, and <STRONG>po_3</STRONG>).`
291
292			`<P>We explain the first module in detail:`
293
294			`<P><br>`
295
296			`<pre class="vhdl">`
297
298			`102 pe_0 : RAMB4_S4_S4 ---------------------------------------------------------`
299			`103 generic map(INIT_00 => pe_0_00, INIT_01 => pe_0_01, INIT_02 => pe_0_02,`
300			`104 INIT_03 => pe_0_03, INIT_04 => pe_0_04, INIT_05 => pe_0_05,`
301			`105 INIT_06 => pe_0_06, INIT_07 => pe_0_07, INIT_08 => pe_0_08,`
302			`106 INIT_09 => pe_0_09, INIT_0A => pe_0_0A, INIT_0B => pe_0_0B,`
303			`107 INIT_0C => pe_0_0C, INIT_0D => pe_0_0D, INIT_0E => pe_0_0E,`
304			`108 INIT_0F => pe_0_0F)`
305			`109 port map(ADDRA => L_PC_E, ADDRB => I_PM_ADR(11 downto 2),`
306			`110 CLKA => I_CLK, CLKB => I_CLK,`
307			`111 DIA => "0000", DIB => "0000",`
308			`112 ENA => L_WAIT_N, ENB => '1',`
309			`113 RSTA => '0', RSTB => '0',`
310			`114 WEA => '0', WEB => '0',`
311			`115 DOA => M_OPC_E(3 downto 0), DOB => M_PMD_E(3 downto 0));`
312			`<pre class="filename">`
313			`src/prog_mem.vhd`
314			`</pre></pre>`
315			`<P>`
316
317			`<P><br>`
318
319			`<P>The first line instantiates a module of type <STRONG>RAMB4_S4_S4</STRONG>, which`
320			`is a dual-port memory module with two 4-bit ports. For a Xilinx`
321			`FPGA you can used these modules directly by uncommenting the`
322			`use of the UNISIM library. For functional simulation we have provided`
323			`a <STRONG>RAMB4_S4_S4.vhd</STRONG> component in the test directory. This component`
324			`emulates the real <STRONG>RAMB4_S4_S4</STRONG> as good as needed.`
325
326			`<P>The next lines define the content of each memory module by means of`
327			`a generic map. The elements of the generic map (like <STRONG>pe_0_00</STRONG>, <STRONG>pe_0_01</STRONG>, and`
328			`so forth) define the initial memory content of the instantiated module.`
329			`<STRONG>pe_0_00</STRONG>, <STRONG>pe_0_01</STRONG>, .. are themselves defined in <STRONG>prog_mem_content.vhd</STRONG>`
330			`which is included in the library section:`
331
332			`<P><br>`
333
334			`<pre class="vhdl">`
335
336			`34 use work.prog_mem_content.all;`
337			`<pre class="filename">`
338			`src/prog_mem.vhd`
339			`</pre></pre>`
340			`<P>`
341
342			`<P><br>`
343
344			`<P>The process from a C (or C++) source file <STRONG>hello.c</STRONG> to the final`
345			`FPGA is then:`
346
347			`<UL>`
348			`<LI>write, compile, and link <STRONG>hello.c</STRONG> (produces <STRONG>hello.hex</STRONG>).`
349			`<LI>generate <STRONG>prog_mem_content.vhd</STRONG> from <STRONG>hello.hex</STRONG> (by means of tool`
350			`<STRONG>make_mem</STRONG>, which is provided with this lecture).`
351			`<LI>simulate, synthesize and implement the design.`
352			`<LI>create a bitmap file.`
353			`<LI>flash the FPGA (or serial PROM).`
354			`</UL>`
355			`<P>There are other ways of initializing the memory modules, such as`
356			`updating sections of the bitmap file, but we found the above sequence`
357			`easier to use.`
358
359			`<P>After the generic map, follows the port map of the memory module.`
360			`The two addresses <STRONG>ADDRA</STRONG> and <STRONG>ADDRB</STRONG> of the two ports come from`
361			`the <STRONG>PC</STRONG> and <STRONG>PM_ADR</STRONG> inputs as already described.`
362
363			`<P>Both ports are clocked from <STRONG>CLK</STRONG>. Since the program memory is read-only,`
364			`the <STRONG>DIA</STRONG> and <STRONG>DIB</STRONG> inputs are not used (set to 0000) and <STRONG>WEA</STRONG> and <STRONG>WEB</STRONG>`
365			`are 0. <STRONG>RSTA</STRONG> and <STRONG>RSTB</STRONG> are not used either and are set to 0.`
366			`<STRONG>ENA</STRONG> is used for keeping the <STRONG>OPC</STRONG> when the pipeline is stopped, while`
367			`<STRONG>ENB</STRONG> is not used. The memory outputs <STRONG>DOA</STRONG> and <STRONG>DOB</STRONG> go to the output`
368			`multiplexers of the two ports.`
369
370			`<H3><A NAME="section_1_1_4">5.2.3 Delayed PC</A></H3>`
371
372			`<P><STRONG>Q_PC</STRONG> is <STRONG>I_PC</STRONG> delayed by one clock. The program memory is a synchronous`
373			`memory, which has the consequence that the program memory output <STRONG>OPC</STRONG>`
374			`for a given <STRONG>I_PC</STRONG> is always one clock cycle behind as shown in the figure`
375			`below on the left.`
376
377			`<P><br>`
378
379			`<P><img src="opcode_fetch_1.png">`
380
381			`<P><br>`
382
383			`<P>By clocking <STRONG>I_PC</STRONG> once, we re-align <STRONG>Q_PC</STRONG> and <STRONG>OPC</STRONG> as shown on the right:`
384
385			`<P><br>`
386
387			`<pre class="vhdl">`
388
389			`227 Q_PC <= I_PC;`
390			`<pre class="filename">`
391			`src/prog_mem.vhd`
392			`</pre></pre>`
393			`<P>`
394
395			`<P><br>`
396
397			`<H2><A NAME="section_1_2">5.3 Two Cycle Opcodes</A></H2>`
398
399			`<P>The vast majority of instructions executes in one cycle. Some need`
400			`two cycles because they involve reading of a synchronous memory. For`
401			`these signals <STRONG>WAIT</STRONG> signal is generated on the first cycle:`
402
403			`<P><br>`
404
405			`<pre class="vhdl">`
406
407			`114 -- Two cycle opcodes:`
408			`115 --`
409			`116 -- 1001 000d dddd .... - LDS etc.`
410			`117 -- 1001 0101 0000 1000 - RET`
411			`118 -- 1001 0101 0001 1000 - RETI`
412			`119 -- 1001 1001 AAAA Abbb - SBIC`
413			`120 -- 1001 1011 AAAA Abbb - SBIS`
414			`121 -- 1111 110r rrrr 0bbb - SBRC`
415			`122 -- 1111 111r rrrr 0bbb - SBRS`
416			`123 --`
417			`124 L_WAIT <= '0' when (L_INVALIDATE = '1')`
418			`125 else '0' when (I_INTVEC(5) = '1')`
419			`126 else L_T0 when ((P_OPC(15 downto 9) = "1001000" ) -- LDS etc.`
420			`127 or (P_OPC(15 downto 8) = "10010101") -- RET etc.`
421			`128 or ((P_OPC(15 downto 10) = "100110") -- SBIC, SBIS`
422			`129 and P_OPC(8) = '1')`
423			`130 or (P_OPC(15 downto 10) = "111111")) -- SBRC, SBRS`
424			`131 else '0';`
425			`<pre class="filename">`
426			`src/opc_fetch.vhd`
427			`</pre></pre>`
428			`<P>`
429
430			`<P><br>`
431
432			`<H2><A NAME="section_1_3">5.4 Interrupts</A></H2>`
433
434			`<P>The opcode fetch stage is also responsible for part of the interrupt`
435			`handling. Interrupts are generated in the I/O block by setting`
436			`<STRONG>INTVEC</STRONG> to a value with the highest bit set:`
437
438			`<P><br>`
439
440			`<pre class="vhdl">`
441
442			`169 if (L_RX_INT_ENABLED and U_RX_READY) = '1' then`
443			`170 if (L_INTVEC(5) = '0') then -- no interrupt pending`
444			`171 L_INTVEC <= "101011"; -- _VECTOR(11)`
445			`172 end if;`
446			`173 elsif (L_TX_INT_ENABLED and not U_TX_BUSY) = '1' then`
447			`174 if (L_INTVEC(5) = '0') then -- no interrupt pending`
448			`175 L_INTVEC <= "101100"; -- _VECTOR(12)`
449			`176 end if;`
450			`<pre class="filename">`
451			`src/io.vhd`
452			`</pre></pre>`
453			`<P>`
454
455			`<P><br>`
456
457			`<P>The highest bit of <STRONG>INTVEC</STRONG> indicates that the lower bits contain a`
458			`valid interrupt number. <STRONG>INTVEC</STRONG> proceeds to the cpu core where`
459			`the upper bit is <STRONG>and</STRONG>'ed with the global interrupt enable bit (in the`
460			`status register):`
461
462			`<P><br>`
463
464			`<pre class="vhdl">`
465
466			`241 L_INTVEC_5 <= I_INTVEC(5) and R_INT_ENA;`
467			`<pre class="filename">`
468			`src/cpu_core.vhd`
469			`</pre></pre>`
470			`<P>`
471
472			`<P><br>`
473
474			`<P>The (possibly modified) <STRONG>INTVEC</STRONG> then proceeds to the opcode fetch stage.`
475			`If the the global interrupt enable bit was set, then the next valid`
476			`opcode is replaced by an "interrupt opcode":`
477
478			`<P><br>`
479
480			`<pre class="vhdl">`
481
482			`135 Q_OPC <= X"00000000" when (L_INVALIDATE = '1')`
483			`136 else P_OPC when (I_INTVEC(5) = '0')`
484			`137 else (X"000000" & "00" & I_INTVEC); -- "interrupt opcode"`
485			`<pre class="filename">`
486			`src/opc_fetch.vhd`
487			`</pre></pre>`
488			`<P>`
489
490			`<P><br>`
491
492			`<P>The interrupt opcode uses a gap after the <STRONG>NOP</STRONG> instruction in the opcode`
493			`set of the AVR CPU. When the interrupt opcode reaches the execution`
494			`stage then is causes a branch to the location determined by the lower`
495			`bits of <STRONG>INTVEC</STRONG>, pushes the program counter, and clears the interrupt`
496			`enable bit. This happens a few clock cycles later. In the meantime`
497			`the opcode fetch stage keeps inserting interrupt instructions into`
498			`the pipeline. These additional interrupt instructions are being`
499			`invalidated by the execution stage when the first interrupt instruction`
500			`reaches the execution stage.`
501
502			`<P><hr><BR>`
503			`<table class="ttop"><th class="tpre"><a href="04_Cpu_Core.html">Previous Lesson</a></th><th class="ttop"><a href="toc.html">Table of Content</a></th><th class="tnxt"><a href="06_Data_Path.html">Next Lesson</a></th></table>`
504			`</BODY>`
505			`</HTML>`