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

Subversion Repositories zipcpu

[/] [zipcpu/] [trunk/] [rtl/] [cpudefs.v] - Blame information for rev 193

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

Line No. Rev Author Line
1 56 dgisselq
///////////////////////////////////////////////////////////////////////////////
2
//
3
// Filename:    cpudefs.v
4
//
5
// Project:     Zip CPU -- a small, lightweight, RISC CPU soft core
6
//
7
// Purpose:     Some architectures have some needs, others have other needs.
8
//              Some of my projects need a Zip CPU with pipelining, others
9
//      can't handle the timing required to get the answer from the ALU
10
//      back into the input for the ALU.  As each different projects has
11
//      different needs, I can either 1) reconfigure my entire baseline prior
12
//      to building each project, or 2) host a configuration file which contains
13
//      the information regarding each baseline.  This file is that
14
//      configuration file.  It controls how the CPU (not the system,
15
//      peripherals, or other) is defined and implemented.  Several options
16
//      are available within here, making the Zip CPU pipelined or not,
17
//      able to handle a faster clock with more stalls or a slower clock with
18
//      no stalls, etc.
19
//
20
//      This file encapsulates those control options.
21
//
22
//      The number of LUTs the Zip CPU uses varies dramatically with the
23
//      options defined in this file.
24
//
25
//
26
// Creator:     Dan Gisselquist, Ph.D.
27 69 dgisselq
//              Gisselquist Technology, LLC
28 56 dgisselq
//
29
///////////////////////////////////////////////////////////////////////////////
30
//
31 193 dgisselq
// Copyright (C) 2015-2016, Gisselquist Technology, LLC
32 56 dgisselq
//
33
// This program is free software (firmware): you can redistribute it and/or
34
// modify it under the terms of  the GNU General Public License as published
35
// by the Free Software Foundation, either version 3 of the License, or (at
36
// your option) any later version.
37
//
38
// This program is distributed in the hope that it will be useful, but WITHOUT
39
// ANY WARRANTY; without even the implied warranty of MERCHANTIBILITY or
40
// FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
41
// for more details.
42
//
43
// License:     GPL, v3, as defined and found on www.gnu.org,
44
//              http://www.gnu.org/licenses/gpl.html
45
//
46
//
47
///////////////////////////////////////////////////////////////////////////////
48
`ifndef CPUDEFS_H
49
`define CPUDEFS_H
50
//
51
//
52
// The first couple options control the Zip CPU instruction set, and how
53
// it handles various instructions within the set:
54
//
55
//
56
// OPT_ILLEGAL_INSTRUCTION is part of a new section of code that is supposed
57
// to recognize illegal instructions and interrupt the CPU whenever one such
58
// instruction is encountered.  The goal is to create a soft floating point
59
// unit via this approach, that can then be replaced with a true floating point
60
// unit.  As I'm not there yet, it just catches illegal instructions and
61
// interrupts the CPU on any such instruction--when defined.  Otherwise,
62
// illegal instructions are quietly ignored and their behaviour is ...
63
// undefined. (Many get treated like NOOPs ...)
64
//
65 184 dgisselq
// I recommend setting this flag so highly, that I'm likely going to remove
66
// the option to turn this off in future versions of this CPU.
67 56 dgisselq
//
68
`define OPT_ILLEGAL_INSTRUCTION
69
//
70
//
71
//
72
// OPT_MULTIPLY controls whether or not the multiply is built and included
73
// in the ALU by default.  Set this option and a parameter will be set that
74
// includes the multiply.  (This parameter may still be overridden, as with
75
// any parameter ...)  If the multiply is not included and
76
// OPT_ILLEGAL_INSTRUCTION is set, then the multiply will create an illegal
77
// instruction that will then trip the illegal instruction trap.
78
//
79 193 dgisselq
// Either not defining this value, or defining it to zero will disable the
80
// hardware multiply.  A value of '1' will cause the multiply to occurr in one
81
// clock cycle only--often at the expense of the rest of the CPUs speed.
82
// A value of 2 will cause the multiply to have a single delay cycle, 3 will
83
// have two delay cycles, and 4 (or more) will have 3 delay cycles.
84 56 dgisselq
//
85
//
86 193 dgisselq
`define OPT_MULTIPLY    3
87 56 dgisselq
//
88
//
89 193 dgisselq
//
90 69 dgisselq
// OPT_DIVIDE controls whether or not the divide instruction is built and
91
// included into the ZipCPU by default.  Set this option and a parameter will
92
// be set that causes the divide unit to be included.  (This parameter may
93
// still be overridden, as with any parameter ...)  If the divide is not
94
// included and OPT_ILLEGAL_INSTRUCTION is set, then the multiply will create
95
// an illegal instruction exception that will send the CPU into supervisor
96
// mode.
97
//
98
//
99
`define OPT_DIVIDE
100
//
101
//
102
//
103
// OPT_IMPLEMENT_FPU will (one day) control whether or not the floating point
104
// unit (once I have one) is built and included into the ZipCPU by default. 
105
// At that time, if this option is set then a parameter will be set that
106
// causes the floating point unit to be included.  (This parameter may
107
// still be overridden, as with any parameter ...)  If the floating point unit
108
// is not included and OPT_ILLEGAL_INSTRUCTION is set, then as with the
109
// multiply and divide any floating point instruction will result in an illegal
110
// instruction exception that will send the CPU into supervisor mode.
111
//
112
//
113
// `define      OPT_IMPLEMENT_FPU
114
//
115
//
116
//
117
// OPT_NEW_INSTRUCTION_SET controls whether or not the new instruction set
118
// is in use.  The new instruction set contains space for floating point
119
// operations, signed and unsigned divide instructions, as well as bit reversal
120
// and ... at least two other operations yet to be defined.  The decoder alone
121
// uses about 70 fewer LUTs, although in practice this works out to 12 fewer
122
// when all works out in the wash.  Further, floating point and divide
123
// instructions will cause an illegal instruction exception if they are not
124
// implemented--so software capability can be built to use these instructions
125
// immediately, even if the hardware is not yet ready.
126
//
127
// This option is likely to go away in the future, obsoleting the previous
128
// instruction set, so I recommend setting this option and switching to the
129
// new instruction set as soon as possible.
130
//
131
`define OPT_NEW_INSTRUCTION_SET
132
//
133
//
134
//
135
//
136
//
137
//
138 56 dgisselq
// OPT_SINGLE_FETCH controls whether or not the prefetch has a cache, and 
139
// whether or not it can issue one instruction per clock.  When set, the
140
// prefetch has no cache, and only one instruction is fetched at a time.
141
// This effectively sets the CPU so that only one instruction is ever 
142
// in the pipeline at once, and hence you may think of this as a "kill 
143
// pipeline" option.  However, since the pipelined fetch component uses so
144
// much area on the FPGA, this is an important option to use in trimming down
145
// used area if necessary.  Hence, it needs to be maintained for that purpose.
146
// Be aware, though, it will drop your performance by a factor between 2x and
147
// 3x.
148
//
149 64 dgisselq
// We can either pipeline our fetches, or issue one fetch at a time.  Pipelined
150
// fetches are more complicated and therefore use more FPGA resources, while
151
// single fetches will cause the CPU to stall for about 5 stalls each 
152
// instruction cycle, effectively reducing the instruction count per clock to
153
// about 0.2.  However, the area cost may be worth it.  Consider:
154
//
155
//      Slice LUTs              ZipSystem       ZipCPU
156
//      Single Fetching         2521            1734
157
//      Pipelined fetching      2796            2046
158
//      (These numbers may be dated, but should still be representative ...)
159
//
160 56 dgisselq
// I recommend only defining this if you "need" to, if area is tight and
161
// speed isn't as important.  Otherwise, just leave this undefined.
162
//
163
// `define      OPT_SINGLE_FETCH
164
//
165
//
166
//
167
// The next several options are pipeline optimization options.  They make no
168
// sense in a single instruction fetch mode, hence we #ifndef them so they
169
// are only defined if we are in a full pipelined mode (i.e. OPT_SINGLE_FETCH
170
// is not defined).
171
//
172
`ifndef OPT_SINGLE_FETCH
173
//
174
//
175
//
176 69 dgisselq
// OPT_PIPELINED is the natural result and opposite of using the single 
177
// instruction fetch unit.  If you are not using that unit, the ZipCPU will
178
// be pipelined.  The option is defined here more for readability than 
179
// anything else, since OPT_PIPELINED makes more sense than OPT_SINGLE_FETCH,
180
// well ... that and it does a better job of explaining what is going on.
181 56 dgisselq
//
182 69 dgisselq
// In other words, leave this define alone--lest you break the ZipCPU.
183 56 dgisselq
//
184 69 dgisselq
`define OPT_PIPELINED
185 56 dgisselq
//
186
//
187
//
188 69 dgisselq
// OPT_TRADITIONAL_PFCACHE allows you to switch between one of two prefetch
189
// caches.  If enabled, a more traditional cache is implemented.  This more
190
// traditional cache (currently) uses many more LUTs, but it also reduces
191
// the stall count tremendously over the alternative hacked pipeline cache.
192
// (The traditional pfcache is also pipelined, whereas the pipeline cache
193
// implements a windowed approach to caching.)
194
//
195
// If you have the fabric to support this option, I recommend including it.
196
//
197
`define OPT_TRADITIONAL_PFCACHE
198
//
199
//
200
//
201 56 dgisselq
// OPT_EARLY_BRANCHING is an attempt to execute a BRA statement as early
202
// as possible, to avoid as many pipeline stalls on a branch as possible.
203 69 dgisselq
// It's not tremendously successful yet--BRA's still suffer stalls,
204 56 dgisselq
// but I intend to keep working on this approach until the number of stalls
205 69 dgisselq
// gets down to one or (ideally) zero.  (With the OPT_TRADITIONAL_PFCACHE, this
206
// gets down to a single stall cycle ...)  That way a "BRA" can be used as the
207
// compiler's branch prediction optimizer: BRA's barely stall, while branches
208
// on conditions will always suffer about 4 stall cycles or so.
209 56 dgisselq
//
210
// I recommend setting this flag, so as to turn early branching on.
211
//
212
`define OPT_EARLY_BRANCHING
213
//
214
//
215
//
216
// OPT_PIPELINED_BUS_ACCESS controls whether or not LOD/STO instructions
217
// can take advantaged of pipelined bus instructions.  To be eligible, the
218
// operations must be identical (cannot pipeline loads and stores, just loads
219
// only or stores only), and the addresses must either be identical or one up
220
// from the previous address.  Further, the load/store string must all have
221
// the same conditional.  This approach gains the must use, in my humble
222
// opinion, when saving registers to or restoring registers from the stack
223
// at the beginning/end of a procedure, or when doing a context swap.
224
//
225
// I recommend setting this flag, for performance reasons, especially if your
226
// wishbone bus can handle pipelined bus accesses.
227
//
228
`define OPT_PIPELINED_BUS_ACCESS
229
//
230
//
231
//
232 69 dgisselq
`ifdef  OPT_NEW_INSTRUCTION_SET
233 56 dgisselq
//
234
//
235
//
236 69 dgisselq
// The new instruction set also defines a set of very long instruction words.
237
// Well, calling them "very long" instruction words is probably a misnomer,
238
// although we're going to do it.  They're really 2x16-bit instructions---
239
// instruction words that pack two instructions into one word.  (2x14 bit
240
// really--'cause you need a bit to note the instruction is a 2x instruction,
241
// and then 3-bits for the condition codes ...)  Set OPT_VLIW to include these
242
// double instructions as part of the new instruction set.  These allow a single
243
// instruction to contain two instructions within.   These instructions are
244
// designed to get more code density from the instruction set, and to hopefully
245
// take some pain off of the performance of the pre-fetch and instruction cache.
246 56 dgisselq
//
247 69 dgisselq
// These new instructions, however, also necessitate a change in the Zip
248
// CPU--the Zip CPU can no longer execute instructions atomically.  It must
249
// now execute non-VLIW instructions, or VLIW instruction pairs, atomically. 
250
// This logic has been added into the ZipCPU, but it has not (yet) been
251
// tested thoroughly.
252
//
253
// Oh, and the assembler, the debugger, and the object file dumper, and the
254
// simulator all need to be updated as well ....
255
//
256
`define OPT_VLIW
257
//
258
//
259 84 dgisselq
`endif // OPT_NEW_INSTRUCTION_SET
260 69 dgisselq
//
261
//
262 56 dgisselq
`endif  // OPT_SINGLE_FETCH
263
//
264
//
265 69 dgisselq
//
266
// Now let's talk about peripherals for a moment.  These next two defines
267
// control whether the DMA controller is included in the Zip System, and
268
// whether or not the 8 accounting timers are also included.  Set these to
269
// include the respective peripherals, comment them out not to.
270
//
271
`define INCLUDE_DMA_CONTROLLER
272
`define INCLUDE_ACCOUNTING_COUNTERS
273
//
274
//
275
// `define      DEBUG_SCOPE
276
//
277 56 dgisselq
`endif  // CPUDEFS_H

powered by: WebSVN 2.1.0

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