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

Subversion Repositories cpu_lecture

[/] [cpu_lecture/] [trunk/] [html/] [02_Top_Level.html] - Blame information for rev 10

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

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/Top_Level</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="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>
11
<hr>
12
 
13
<H1><A NAME="section_1">2 TOP LEVEL</A></H1>
14
 
15
<P>This lesson defines what we want to create and the top level VHDL
16
file for it.
17
 
18
<H2><A NAME="section_1_1">2.1 Design Purpose</A></H2>
19
 
20
<P>We assume that the purpose of the design is to build an FPGA with
21
the following features:
22
 
23
<UL>
24
  <LI>a CPU similar to the Atmel ATmega8,
25
  <LI>a serial port with a fixed baud rate, and
26
  <LI>an output for a single digit 7-segment display.
27
</UL>
28
<P>It is assumed that a suitable hardware exists.
29
 
30
<H2><A NAME="section_1_2">2.2 Top Level Design</A></H2>
31
 
32
<P>A CPU with I/O is a somewhat complicated beast. In order to
33
tame it, we brake it down into smaller and smaller pieces until
34
the pieces become trivial.
35
 
36
<P>The trick is to perform the breakdown at points where the connection
37
between the pieces is weak (meaning that it consists of only a
38
few signals).
39
 
40
<P>The top level of our FPGA design, and a few components around the
41
FPGA, looks like this:
42
 
43
<P><br>
44
 
45
<P><img src="avr_fpga.png">
46
 
47
<P><br>
48
 
49
<P>This design consists of 2 big sub-components <STRONG>cpu</STRONG> and <STRONG>ino</STRONG>, a small
50
sub-component <STRONG>seg</STRONG>, and some local processes like <STRONG>clk_div</STRONG> and <STRONG>deb</STRONG> that
51
are not broken down in other VHDL files, but rather written directly
52
in VHDL.
53
 
54
<P><STRONG>cpu</STRONG> and <STRONG>ino</STRONG> are described in lessons 4 and 8.
55
 
56
<P><STRONG>seg</STRONG> is a debug component that has the current program counter (<STRONG>PC</STRONG>)
57
of the CPU as input and displays it as 4 hex digits that show up one
58
by one with a short break between every sequence of hex digits. Since
59
<STRONG>seg</STRONG> is rather board specific, we will not describe it in detail in
60
this lecture.
61
 
62
<P>The local processes are described further down in this lesson. Before
63
that we explain the structure that will be used for all VHDL source file.
64
 
65
<H2><A NAME="section_1_3">2.3 General Structure of our VHDL Files</A></H2>
66
 
67
<H3><A NAME="section_1_3_1">2.3.1 Header and Library Declarations</A></H3>
68
 
69
<P>Each VHDL source file starts with a comment containing a copyright notice
70
(all files are released under the GPL) and the purpose of the file.
71
Then follows a declaration of the libraries being used.
72
 
73
<H3><A NAME="section_1_3_2">2.3.2 Entity Declaration</A></H3>
74
 
75
<P>After the header and libraries, the entity that is defined in the VHDL
76
file is declared. We declare one entity per VHDL file.
77
The declaration consists of the name of the entity,
78
the inputs, and the outputs of the entity. In this declaration the order
79
of input and outputs does not matter, but we try to stick to the convention
80
to declare the inputs before the outputs.
81
 
82
<P>There is one exception: the file <STRONG>common.vhd</STRONG> does not define an entity,
83
but a VHDL package. This package contains the definitions of constants
84
that are used in more than one VHDL source file. This ensures that changes
85
to these constants happen in all files using them.
86
 
87
<H3><A NAME="section_1_3_3">2.3.3 Entity Architecture</A></H3>
88
 
89
<P>Finally, the architecture of the entity is specified. The
90
architecture consists of a header and a body.
91
 
92
<P>In the header we declare the components, functions, signals, and
93
constants that are used in the body.
94
 
95
<P>The body defines how the items declared in the header are
96
being used (i.e. instantiated, interconnected etc.). This body
97
contains, so to say, the "intelligence" of the design.
98
 
99
<H2><A NAME="section_1_4">2.4 avr_fpga.vhd</A></H2>
100
 
101
<P>The top level of our design is defined in <STRONG>avr_fpga.vhd</STRONG>. Since this
102
is our first VHDL file we explain it completely, line by line. Later
103
on, we will silently skip repetitions of parts that have been described
104
in other files or that are very similar.
105
 
106
<H3><A NAME="section_1_4_1">2.4.1 Header and Library Declarations</A></H3>
107
 
108
<P>avr_fpga.vhd starts with a copyright header.
109
 
110
<P><br>
111
 
112
<pre class="vhdl">
113
 
114
  1     -------------------------------------------------------------------------------
115
  2     --
116
  3     -- Copyright (C) 2009, 2010 Dr. Juergen Sauermann
117
  4     --
118
  5     --  This code is free software: you can redistribute it and/or modify
119
  6     --  it under the terms of the GNU General Public License as published by
120
  7     --  the Free Software Foundation, either version 3 of the License, or
121
  8     --  (at your option) any later version.
122
  9     --
123
 10     --  This code is distributed in the hope that it will be useful,
124
 11     --  but WITHOUT ANY WARRANTY; without even the implied warranty of
125
 12     --  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
126
 13     --  GNU General Public License for more details.
127
 14     --
128
 15     --  You should have received a copy of the GNU General Public License
129
 16     --  along with this code (see the file named COPYING).
130
 17     --  If not, see http://www.gnu.org/licenses/.
131
 18     --
132
 19     -------------------------------------------------------------------------------
133
 20     -------------------------------------------------------------------------------
134
 21     --
135
 22     -- Module Name:     avr_fpga - Behavioral
136
 23     -- Create Date:     13:51:24 11/07/2009
137
 24     -- Description:     top level of a CPU
138
 25     --
139
 26     -------------------------------------------------------------------------------
140
 27
141
<pre class="filename">
142
src/avr_fpga.vhd
143
</pre></pre>
144
<P>
145
 
146
<P><br>
147
 
148
<P>The libraries used are more or less the same in all VHDL files:
149
 
150
<P><br>
151
 
152
<pre class="vhdl">
153
 
154
 28     library IEEE;
155
 29     use IEEE.STD_LOGIC_1164.ALL;
156
 30     use IEEE.STD_LOGIC_ARITH.ALL;
157
 31     use IEEE.STD_LOGIC_UNSIGNED.ALL;
158
 32
159
<pre class="filename">
160
src/avr_fpga.vhd
161
</pre></pre>
162
<P>
163
 
164
<P><br>
165
 
166
<P>The only Xilinx specific components needed for this lecture are the block RAMs.
167
For functional simulation we provide compatible components written in
168
VHDL. For FPGAs from other vendors you can probably include their
169
FPGA libraries, but we have not tested this.
170
 
171
<H3><A NAME="section_1_4_2">2.4.2 Entity Declaration</A></H3>
172
 
173
<P>For a top level entity, the inputs and outputs of the entities are
174
the pins of the FPGA.
175
 
176
<P>For a lower level entity, the inputs and outputs of the entity are
177
associated ("connected") with the inputs and outputs of the instance
178
of the entity in a higher level entity. For this to work,
179
the inputs and outputs of the declaration should match the component
180
declaration in the architecture of another entity that instantiates
181
the entity being declared.
182
 
183
<P>Since we discuss the top-level, our inputs and outputs are pins of
184
the FPGA. The top level entity is declared like this:
185
 
186
<P><br>
187
 
188
<pre class="vhdl">
189
 
190
 33     entity avr_fpga is
191
 34         port (  I_CLK_100   : in  std_logic;
192
 35                 I_SWITCH    : in  std_logic_vector(9 downto 0);
193
 36                 I_RX        : in  std_logic;
194
 37
195
 38                 Q_7_SEGMENT : out std_logic_vector(6 downto 0);
196
 39                 Q_LEDS      : out std_logic_vector(3 downto 0);
197
 40                 Q_TX        : out std_logic);
198
<pre class="filename">
199
src/avr_fpga.vhd
200
</pre></pre>
201
<P>
202
 
203
<P><br>
204
 
205
<P>We therefore have the following FPGA pins:
206
 
207
<TABLE border="1">
208
<THEAD><TR><TH>Pin</TH><TH>Purpose</TH></TR></THEAD>
209
<TBODY>
210
<TR><TD>I_CLK_100</TD><TD>a 100 MHz Clock from the board.</TD></TR>
211
<TR><TD>I_SWITCH</TD><TD>a 8 bit DIP switch and two single push-buttons.</TD></TR>
212
<TR><TD>I_RX</TD><TD>the serial input of our UART.</TD></TR>
213
<TR><TD>Q_7_SEGMENT</TD><TD>7 lines to the LEDs of a 7-segment display.</TD></TR>
214
<TR><TD>Q_LEDS</TD><TD>4 lines to single LEDs</TD></TR>
215
<TR><TD>Q_TX</TD><TD>the serial output of our UART.</TD></TR>
216
</TBODY>
217
</TABLE>
218
 
219
<P>The lower 8 bits of <STRONG>SWITCH</STRONG> come from a DIP switch while the upper
220
two bits come from two push-buttons. The two push-buttons are used
221
as reset buttons, while the DIP switch goes to the I/O component from
222
where the CPU can read the value set on the switch.
223
 
224
<H3><A NAME="section_1_4_3">2.4.3 Architecture of the Top Level Entity</A></H3>
225
 
226
<P>The architecture has a head and a body, The head starts with the <STRONG>architecture</STRONG>
227
keyword. The body starts with <STRONG>begin</STRONG> and ends with <STRONG>end</STRONG>, like this:
228
 
229
<P><br>
230
 
231
<pre class="vhdl">
232
 
233
 43     architecture Behavioral of avr_fpga is
234
<pre class="filename">
235
src/avr_fpga.vhd
236
</pre></pre>
237
<pre class="vhdl">
238
 
239
107     begin
240
<pre class="filename">
241
src/avr_fpga.vhd
242
</pre></pre>
243
<pre class="vhdl">
244
 
245
184     end Behavioral;
246
<pre class="filename">
247
src/avr_fpga.vhd
248
</pre></pre>
249
<P><BR>
250
<BR>
251
 
252
 
253
<H4><A NAME="section_1_4_3_1">2.4.3.1 Architecture Header</A></H4>
254
 
255
<P>As we have seen in the first figure in this lesson, the top level
256
uses 3 components: <STRONG>cpu</STRONG>, <STRONG>io</STRONG>, and <STRONG>seg</STRONG>. These components have to
257
be declared in the header of the architecture.
258
The architecture contains component declarations,
259
signal declarations and others. We normally declare components and
260
signals in the following order:
261
 
262
<UL>
263
  <LI>declaration of functions
264
  <LI>declaration of constants
265
  <LI>declaration of the first component (type)
266
  <LI>declaration of signals driven by (an instance of) the first component
267
  <LI>declaration of the second component (type)
268
  <LI>declaration of signals driven by (an instance of) the second component
269
  <LI>...
270
  <LI>declaration of signals driven by local processes and the like.
271
</UL>
272
<P>The first component declaration <STRONG>cpu_core</STRONG> and the signals driven by its
273
instances are:
274
 
275
<P><br>
276
 
277
<pre class="vhdl">
278
 
279
 45     component cpu_core
280
 46         port (  I_CLK       : in  std_logic;
281
 47                 I_CLR       : in  std_logic;
282
 48                 I_INTVEC    : in  std_logic_vector( 5 downto 0);
283
 49                 I_DIN       : in  std_logic_vector( 7 downto 0);
284
 50
285
 51                 Q_OPC       : out std_logic_vector(15 downto 0);
286
 52                 Q_PC        : out std_logic_vector(15 downto 0);
287
 53                 Q_DOUT      : out std_logic_vector( 7 downto 0);
288
 54                 Q_ADR_IO    : out std_logic_vector( 7 downto 0);
289
 55                 Q_RD_IO     : out std_logic;
290
 56                 Q_WE_IO     : out std_logic);
291
 57     end component;
292
 58
293
 59     signal  C_PC            : std_logic_vector(15 downto 0);
294
 60     signal  C_OPC           : std_logic_vector(15 downto 0);
295
 61     signal  C_ADR_IO        : std_logic_vector( 7 downto 0);
296
 62     signal  C_DOUT          : std_logic_vector( 7 downto 0);
297
 63     signal  C_RD_IO         : std_logic;
298
 64     signal  C_WE_IO         : std_logic;
299
<pre class="filename">
300
src/avr_fpga.vhd
301
</pre></pre>
302
<P>
303
 
304
<P><br>
305
 
306
<P>The second component declaration <STRONG>io</STRONG> and its signals are:
307
 
308
<P><br>
309
 
310
<pre class="vhdl">
311
 
312
 66     component io
313
 67         port (  I_CLK       : in  std_logic;
314
 68                 I_CLR       : in  std_logic;
315
 69                 I_ADR_IO    : in  std_logic_vector( 7 downto 0);
316
 70                 I_DIN       : in  std_logic_vector( 7 downto 0);
317
 71                 I_RD_IO     : in  std_logic;
318
 72                 I_WE_IO     : in  std_logic;
319
 73                 I_SWITCH    : in  std_logic_vector( 7 downto 0);
320
 74                 I_RX        : in  std_logic;
321
 75
322
 76                 Q_7_SEGMENT : out std_logic_vector( 6 downto 0);
323
 77                 Q_DOUT      : out std_logic_vector( 7 downto 0);
324
 78                 Q_INTVEC    : out std_logic_vector(5 downto 0);
325
 79                 Q_LEDS      : out std_logic_vector( 1 downto 0);
326
 80                 Q_TX        : out std_logic);
327
 81     end component;
328
 82
329
 83     signal N_INTVEC         : std_logic_vector( 5 downto 0);
330
 84     signal N_DOUT           : std_logic_vector( 7 downto 0);
331
 85     signal N_TX             : std_logic;
332
 86     signal N_7_SEGMENT      : std_logic_vector( 6 downto 0);
333
<pre class="filename">
334
src/avr_fpga.vhd
335
</pre></pre>
336
<P>
337
 
338
<P><br>
339
 
340
<P><STRONG>Note:</STRONG> Normally we would have used <STRONG>I_</STRONG> as a prefix for signals driven by
341
instance <STRONG>ino</STRONG> of <STRONG>io</STRONG>. This conflicts, however, with the prefix reserved
342
for inputs and we have used the next letter <STRONG>n</STRONG> of <STRONG>ino</STRONG> as prefix instead.
343
 
344
<P>The last component is <STRONG>seg</STRONG>:
345
 
346
<P><br>
347
 
348
<pre class="vhdl">
349
 
350
 88     component segment7
351
 89         port ( I_CLK        : in  std_logic;
352
 90
353
 91                I_CLR        : in  std_logic;
354
 92                I_OPC        : in  std_logic_vector(15 downto 0);
355
 93                I_PC         : in  std_logic_vector(15 downto 0);
356
 94
357
 95                Q_7_SEGMENT  : out std_logic_vector( 6 downto 0));
358
 96     end component;
359
 97
360
 98     signal S_7_SEGMENT      : std_logic_vector( 6 downto 0);
361
<pre class="filename">
362
src/avr_fpga.vhd
363
</pre></pre>
364
<P>
365
 
366
<P><br>
367
 
368
<P>The local signals, which are not driven by any component, but by local
369
processes and inputs of the entity, are:
370
 
371
<P><br>
372
 
373
<pre class="vhdl">
374
 
375
100     signal L_CLK            : std_logic := '0';
376
101     signal L_CLK_CNT        : std_logic_vector( 2 downto 0) := "000";
377
102     signal L_CLR            : std_logic;            -- reset,  active low
378
103     signal L_CLR_N          : std_logic := '0';     -- reset,  active low
379
104     signal L_C1_N           : std_logic := '0';     -- switch debounce, active low
380
105     signal L_C2_N           : std_logic := '0';     -- switch debounce, active low
381
106
382
107     begin
383
<pre class="filename">
384
src/avr_fpga.vhd
385
</pre></pre>
386
<P>
387
 
388
<P><br>
389
 
390
<P>The <STRONG>begin</STRONG> keyword in the last line marks the end of the header
391
of the architecture and the start of its body.
392
 
393
<H4><A NAME="section_1_4_3_2">2.4.3.2 Architecture Body</A></H4>
394
 
395
<P>We normally use the following order in the architecture body:
396
 
397
<UL>
398
  <LI>components instantiated
399
  <LI>processes
400
  <LI>local signal assignments
401
</UL>
402
<P>Thus the architecture body is more or less using the same order as
403
the architecture header. The component instantiations instantiate one
404
or more instances of a component type and connect the "ports" of the
405
instantiated component to the signals in the architecture.
406
 
407
<P>The first component declared was <STRONG>cpu</STRONG> so we also instantiate it first:
408
 
409
<P><br>
410
 
411
<pre class="vhdl">
412
 
413
109         cpu : cpu_core
414
110         port map(   I_CLK       => L_CLK,
415
111                     I_CLR       => L_CLR,
416
112                     I_DIN       => N_DOUT,
417
113                     I_INTVEC    => N_INTVEC,
418
114
419
115                     Q_ADR_IO    => C_ADR_IO,
420
116                     Q_DOUT      => C_DOUT,
421
117                     Q_OPC       => C_OPC,
422
118                     Q_PC        => C_PC,
423
119                     Q_RD_IO     => C_RD_IO,
424
120                     Q_WE_IO     => C_WE_IO);
425
<pre class="filename">
426
src/avr_fpga.vhd
427
</pre></pre>
428
<P>
429
 
430
<P><br>
431
 
432
<P>The first line instantiates a component of type <STRONG>cpu_core</STRONG> and calls
433
the instance <STRONG>cpu</STRONG>. The following lines map the names of the ports
434
in the component declaration (in the architecture header) to either
435
inputs of the entity, outputs of the entity, or signals declared in
436
the architecture header.
437
 
438
<P>We take <STRONG>cpu</STRONG> as an opportunity to explain our naming convention for signals.
439
Our rule for entity inputs and outputs has the consequence that all
440
left sides of the port map have either an <STRONG>I_</STRONG> prefix or an <STRONG>O_</STRONG> prefix.
441
This follows from the fact that a component instantiated in one architecture
442
corresponds to an entity declared in some other VHDL file and there the
443
<STRONG>I_</STRONG> or <STRONG>O_</STRONG> convention applies,
444
 
445
<P>The next observation is that all component outputs either drive an entity
446
output or a local signal that starts with the letter chosen for the
447
instantiated component. This is the C_ in the <STRONG>cpu</STRONG> case. The <STRONG>cpu</STRONG> does
448
not drive an entity output directly (so all outputs map to <STRONG>C_</STRONG> signals),
449
but in the <STRONG>io</STRONG> outputs there is one driving an entity output (see below).
450
 
451
<P>Finally the component inputs can be driven from more or less anywhere, but
452
from the prefix (<STRONG>L_</STRONG> or not) we can see if the signal is directly driven
453
by another component (when the prefix is not <STRONG>L_</STRONG>) or by some logic defined
454
further down in the architecture (signal assignments, processes).
455
 
456
<P>Thus for the <STRONG>cpu</STRONG> component we can already tell that this component
457
drives a number of local signals (that are not entity outputs but inputs
458
to other components or local processes)&gt; These signals are those on
459
the right side of the port map starting with <STRONG>C_</STRONG>. We can also tell
460
that there are some local processes generating a clock signal <STRONG>L_CLK</STRONG>
461
and a reset signal <STRONG>L_CLR</STRONG>, and the <STRONG>ino</STRONG> component (which uses prefix <STRONG>N_</STRONG>)
462
drives an interrupt vector <STRONG>N_INTVEC</STRONG> and a data bus <STRONG>N_DOUT</STRONG>.
463
 
464
<P>The next two components being instantiated are <STRONG>ino</STRONG> of type <STRONG>io</STRONG> and
465
<STRONG>seg</STRONG> of type <STRONG>segment7</STRONG>:
466
 
467
<P><br>
468
 
469
<pre class="vhdl">
470
 
471
122         ino : io
472
123         port map(   I_CLK       => L_CLK,
473
124                     I_CLR       => L_CLR,
474
125                     I_ADR_IO    => C_ADR_IO,
475
126                     I_DIN       => C_DOUT,
476
127                     I_RD_IO     => C_RD_IO,
477
128                     I_RX        => I_RX,
478
129                     I_SWITCH    => I_SWITCH(7 downto 0),
479
130                     I_WE_IO     => C_WE_IO,
480
131
481
132                     Q_7_SEGMENT => N_7_SEGMENT,
482
133                     Q_DOUT      => N_DOUT,
483
134                     Q_INTVEC    => N_INTVEC,
484
135                     Q_LEDS      => Q_LEDS(1 downto 0),
485
136                     Q_TX        => N_TX);
486
137
487
138         seg : segment7
488
139         port map(   I_CLK       => L_CLK,
489
140                     I_CLR       => L_CLR,
490
141                     I_OPC       => C_OPC,
491
142                     I_PC        => C_PC,
492
143
493
144                     Q_7_SEGMENT => S_7_SEGMENT);
494
<pre class="filename">
495
src/avr_fpga.vhd
496
</pre></pre>
497
<P>
498
 
499
<P><br>
500
 
501
<P>Then come the local processes.  The first process divides the 100 MHz
502
input clock from the board into a 25 MHz clock used by the CPU.
503
The design can, with some tuning of the timing optimizations,
504
run at 33 MHz, but for our purposes we are happy with 25 MHz.
505
 
506
<P><br>
507
 
508
<pre class="vhdl">
509
 
510
148         clk_div : process(I_CLK_100)
511
149         begin
512
150             if (rising_edge(I_CLK_100)) then
513
151                 L_CLK_CNT <= L_CLK_CNT + "001";
514
152                 if (L_CLK_CNT = "001") then
515
153                     L_CLK_CNT <= "000";
516
154                     L_CLK <= not L_CLK;
517
155                 end if;
518
156             end if;
519
157         end process;
520
<pre class="filename">
521
src/avr_fpga.vhd
522
</pre></pre>
523
<P>
524
 
525
<P><br>
526
 
527
<P>The second process is <STRONG>deb</STRONG>. It debounces the push-buttons used to
528
reset the <STRONG>cpu</STRONG> and <STRONG>ino</STRONG> components. When either button is pushed
529
('0' on <STRONG>SWITCH(8)</STRONG> or <STRONG>SWITCH(9)</STRONG>) then <STRONG>CLR_N</STRONG> goes low immediately
530
and stays low for two more cycles after the button was released.
531
 
532
<P><br>
533
 
534
<pre class="vhdl">
535
 
536
161         deb : process(L_CLK)
537
162         begin
538
163             if (rising_edge(L_CLK)) then
539
164                 -- switch debounce
540
165                 if ((I_SWITCH(8) = '0') or (I_SWITCH(9) = '0')) then    -- pushed
541
166                     L_CLR_N <= '0';
542
167                     L_C2_N  <= '0';
543
168                     L_C1_N  <= '0';
544
169                 else                                                    -- released
545
170                     L_CLR_N <= L_C2_N;
546
171                     L_C2_N  <= L_C1_N;
547
172                     L_C1_N  <= '1';
548
173                 end if;
549
174             end if;
550
175         end process;
551
<pre class="filename">
552
src/avr_fpga.vhd
553
</pre></pre>
554
<P>
555
 
556
<P><br>
557
 
558
<P>Finally we have the signals driven directly from other signals. This
559
kind of signal assignments are the same as processes, but use a simpler
560
syntax for frequently used logic.
561
 
562
<P><br>
563
 
564
<pre class="vhdl">
565
 
566
177         L_CLR <= not L_CLR_N;
567
178
568
179         Q_LEDS(2) <= I_RX;
569
180         Q_LEDS(3) <= N_TX;
570
181         Q_7_SEGMENT  <= N_7_SEGMENT when (I_SWITCH(7) = '1') else S_7_SEGMENT;
571
182         Q_TX <= N_TX;
572
<pre class="filename">
573
src/avr_fpga.vhd
574
</pre></pre>
575
<P>
576
 
577
<P><br>
578
 
579
<P><STRONG>CLR</STRONG> is generated by inverting <STRONG>CLR_N</STRONG>. The serial input and the
580
serial output are visualized by means of two LEDs. The 7 segment output
581
can be driven from two sources: from a software controlled I/O register
582
in the I/O unit, or from the seven segment component (that shows the
583
current PC and opcode) being executed. The latter component is quite useful
584
for debugging purposes.
585
 
586
<P><STRONG>Note:</STRONG> We use a <STRONG>_N</STRONG> suffix to denote an active low signal.
587
Active low signals normally come from some FPGA pin since inside
588
the FPGA active low signals have no advantage over active high signals.
589
In the good old TTL days active low signals were preferred for strobe
590
signals since the HIGH to LOW transition in TTL was faster than the LOW
591
to high transition. Some active low signals we see today are left-overs
592
from those days.<BR>
593
Another common case is switches and push-buttons that are held high
594
with a pull-up resistor when open and short-cut to ground when the
595
switch is closed.
596
 
597
<H2><A NAME="section_1_5">2.5 Component Tree</A></H2>
598
 
599
<P>The following figure shows the breakdown of almost all components
600
in our design. Only the memory modules in <STRONG>sram</STRONG> and <STRONG>pmem</STRONG> and the
601
individual registers in <STRONG>regs</STRONG> are hidden because they would blow up the
602
structure without providing too much information.
603
 
604
<P><br>
605
 
606
<P><img src="Component_tree.png">
607
 
608
<P><br>
609
 
610
<P>We have already discussed the top level <STRONG>fpga</STRONG> and its 3 components
611
<STRONG>cpu</STRONG>, <STRONG>ino</STRONG>, and <STRONG>seg</STRONG>.
612
 
613
<P>The <STRONG>cpu</STRONG> will be further broken down into a data path <STRONG>dpath</STRONG>, an opcode
614
decode <STRONG>odec</STRONG>, and an opcode fetch <STRONG>opcf</STRONG>. The data path consist of a
615
16-bit ALU <STRONG>alui</STRONG>, a register file <STRONG>regs</STRONG>, and a data memory <STRONG>sram</STRONG>.
616
The opcode fetch contains a program counter <STRONG>pcnt</STRONG> and a program memory <STRONG>pmem</STRONG>.
617
 
618
<P>The <STRONG>ino</STRONG> contains a <STRONG>uart</STRONG> that is further broken down into a baud rate
619
generator <STRONG>baud</STRONG>, a serial receiver <STRONG>rx</STRONG>, and a serial transmitter <STRONG>tx</STRONG>.
620
 
621
<P><hr><BR>
622
<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>
623
</BODY>
624
</HTML>

powered by: WebSVN 2.1.0

© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.