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

Subversion Repositories darkriscv

[/] [darkriscv/] [trunk/] [rtl/] [config.vh] - Blame information for rev 4

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

Line No. Rev Author Line
1 2 marcelos
/*
2
 * Copyright (c) 2018, Marcelo Samsoniuk
3
 * All rights reserved.
4
 *
5
 * Redistribution and use in source and binary forms, with or without
6
 * modification, are permitted provided that the following conditions are met:
7
 *
8
 * * Redistributions of source code must retain the above copyright notice, this
9
 *   list of conditions and the following disclaimer.
10
 *
11
 * * Redistributions in binary form must reproduce the above copyright notice,
12
 *   this list of conditions and the following disclaimer in the documentation
13
 *   and/or other materials provided with the distribution.
14
 *
15
 * * Neither the name of the copyright holder nor the names of its
16
 *   contributors may be used to endorse or promote products derived from
17
 *   this software without specific prior written permission.
18
 *
19
 * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
20
 * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
21
 * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
22
 * DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
23
 * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
24
 * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
25
 * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
26
 * CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
27
 * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
28
 * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
29
 */
30
 
31
`timescale 1ns / 1ps
32
 
33
// memory architecture
34
//
35
// TODO: fix the different memory architecture concepts:
36
// status:
37
// ICACHE: works without interrupt
38
// DCACHE: does not work!
39
// WAITSTATE: works
40
// 
41
//`define __ICACHE__              // instruction cache
42
//`define __DCACHE__              // data cache (bug: simulation only)
43
//`define __WAITSTATES__          // wait-state tests, no cache
44
 
45
// peripheral configuration
46
//
47
// UART speed is set in bits per second, typically 115200 bps:
48
 
49
`define __UARTSPEED__ 115200
50
 
51
// darkriscv/darksocv configuration
52
// 
53
// pipeline stages:
54
// 
55
// 2-stage version: core and memory in different clock edges result in less
56
// clock performance, but less losses when the program counter changes
57
// (pipeline flush = 1 clock).  Works like a 4-stage pipeline and remember
58
// the 68040 clock scheme, with instruction per clock = 1.  alternatively,
59
// it is possible work w/ 1 wait-state and 1 clock edge, but with a penalty
60
// in performance (instruction per clock = 0.5).
61
// 
62
// 3-stage version: core and memory in the same clock edge require one extra
63
// stage in the pipeline, but keep a good performance most of time
64
// (instruction per clock = 1).  of course, read operations require 1
65
// wait-state, which means sometimes the read performance is reduced.
66
 
67
`define __3STAGE__
68
 
69 4 marcelos
// read-modify-write cycle:
70
//
71
// Generate RMW cycles when writing in the memory. This option basically 
72
// makes the read and write cycle symmetric and may work better in the cases
73
// when the 32-bit memory does not support separate write enables for 
74
// separate 16-bit and 8-bit words. Typically, the RMW cycle results in a
75
// decrease of 5% in the performance (not the clock, but the instruction
76
// pipeline eficiency) due to memory wait-states.
77
// Additional note: the RMW cycle is required for -O3 compilation!
78
 
79
//`define __RMW_CYCLE__
80
 
81 2 marcelos
// muti-threading support:
82
//
83 4 marcelos
// Decreases clock performance by 20% (80MHz), but enables two contexts
84
// (threads) in the core. The threads work in symmetrical way, which means
85
// that they will start with the same exactly core parameters (same initial
86
// PC, same initial SP, etc). The boot.s code is designed to handle this
87
// difference and set each thread to different applications.
88
// Notes: 
89
// a) threading is currently supported only in the 3-stage pipeline version.
90
// b) the old experimental "interrupt mode" was removed, which means that
91
//    the multi-thread mode does not make anything "visible" other than
92
//    increment the gpio register.
93
// c) the threading in the non interrupt mode just shares the core 50%/50%,
94
//    in a way that the single-thread performance is reduced.
95 2 marcelos
 
96
//`define __THREADING__
97
 
98
// performance measurement:
99
//
100
// The performance measurement can be done in the simulation level by
101
// eabling the __PERFMETER__ define, in order to check how the clock cycles
102 4 marcelos
// are used in the core. The report is displayed when the FINISH_REQ signal
103
// is actived by the UART.
104 2 marcelos
 
105 4 marcelos
`define __PERFMETER__
106 2 marcelos
 
107
// mac instruction: 
108
// 
109
// The mac instruction is similar to other register to register
110
// instructions, but with a different opcode 7'h1111111.  the format is mac
111
// rd,r1,r2, but is not currently possible encode in asm, by this way it is
112
// available in licb as int mac(int rd, short r1, short r2).  Although it
113
// can be used to accelerate the mul/div operations, the mac operation is
114
// designed for DSP applications.  with some effort (low level machine
115
// code), it is possible peak 100MMAC/s @100MHz.
116
 
117
//`define __MAC16X16__
118
 
119
// RV32I vs RV32E:
120
//
121
// The difference between the RV32I and RV32E regarding the logic space is 
122
// minimal in typical applications with modern 5 or 6 input LUT based FPGAs, 
123
// but the RV32E is better with old 4 input LUT based FPGAs.
124
 
125
`define __RV32E__
126
 
127
// full harvard architecture:
128
// 
129
// When defined, enforses that the instruction and data buses are connected
130
// to fully separate memory banks.  Although the darkriscv always use
131
// harvard architecture in the core, with separate instruction and data
132
// buses, the logic levels outside the core can use different architectures
133
// and concepts, including von neumann, wich a single bus shared by
134
// instruction and data access, as well a mix between harvard and von
135
// neumann, which is possible in the case of dual-port blockrams, where is
136
// possible connect two separate buses in a single memory bank.  the main
137
// advantage of a single memory bank is that the .text and .data areas can
138
// be better allocated, but in this case is not possible protect the .text
139
// area as in the case of separate memory banks.
140
 
141 4 marcelos
//`define __HARVARD__
142 2 marcelos
 
143
// flexbuzz interface (experimental):
144
//
145
// A new data bus interface similar to a well known c*ldfire bus interface, in 
146
// a way that part of the bus routing is moved to the core, in a way that 
147
// is possible support different bus widths (8, 16 or 32 bit) and endians more 
148
// easily (the new interface is natively big-endian, but the endian can be adjusted
149
// in the bus interface dinamically). Similarly to the standard 32-bit interface, 
150
// the external logic must detect the RD/WR operation quick enough and assert HLT 
151
// in order to insert wait-states and perform the required multiplexing to fit 
152
// the DLEN operand size in the data bus width available.
153
 
154 4 marcelos
`define __FLEXBUZZ__
155
 
156
// initial PC and SP
157
//
158
// it is possible program the initial PC and SP.  Typically, the PC is set
159
// to address 0, representing the start of ROM memory and the SP is set to
160
// the final of RAM memory.  In the linker, the start of ROM memory matches
161
// with the .text area, which is defined in the boot.c code and the start of
162
// RAM memory matches with the .data and other volatile data, in a way that
163
// the stack can be positioned in the top of RAM and does not match with the
164
// .data.
165
 
166 2 marcelos
`define __RESETPC__ 32'd0
167
`define __RESETSP__ 32'd8192
168
 
169
// board definition:
170
// 
171
// The board is automatically defined in the xst/xise files via Makefile or
172
// ISE. Case it is not the case, please define you board name here:
173
 
174
//`define AVNET_MICROBOARD_LX9
175
//`define XILINX_AC701_A200
176
//`define QMTECH_SDRAM_LX16
177
 
178
// the following defines are automatically defined:
179
 
180
`ifdef __ICARUS__
181
    `define SIMULATION 1
182
`endif
183
 
184
`ifdef XILINX_ISIM
185
    `define SIMULATION 2
186
`endif
187
 
188
`ifdef MODEL_TECH
189
    `define SIMULATION 3
190
`endif
191
 
192
`ifdef XILINX_SIMULATOR
193
    `define SIMULATION 4
194
`endif
195
 
196
`ifdef AVNET_MICROBOARD_LX9
197
    `define BOARD_ID 1
198
    //`define BOARD_CK 100000000
199
    //`define BOARD_CK 66666666
200
    //`define BOARD_CK 40000000
201
    // example of DCM logic:
202
    `define BOARD_CK_REF 100000000
203
    `define BOARD_CK_MUL 2
204
    `ifdef __3STAGE__
205
        `define BOARD_CK_DIV 2 // 100MHz 
206
    `else
207
        `define BOARD_CK_DIV 4 // 50MHz
208
    `endif
209
`endif
210
 
211
`ifdef XILINX_AC701_A200
212
    `define BOARD_ID 2
213
    //`define BOARD_CK 90000000
214
    `define BOARD_CK_REF 90000000
215
    `define BOARD_CK_MUL 4
216
    `define BOARD_CK_DIV 2
217
`endif
218
 
219
`ifdef QMTECH_SDRAM_LX16
220
    `define BOARD_ID 3
221
    `define BOARD_CK_REF 50000000
222
    `define BOARD_CK_MUL 4
223
    `define BOARD_CK_DIV 2
224
    `define INVRES 1
225
`endif
226
 
227
`ifdef QMTECH_SPARTAN7_S15
228
    `define BOARD_ID 4
229
    `define BOARD_CK_REF 50000000
230
    `define BOARD_CK_MUL 20
231
    `define BOARD_CK_DIV 10
232
    `define XILINX7CLK 1
233
    `define VIVADO 1
234
    `define INVRES 1
235
`endif
236
 
237
`ifdef LATTICE_BREVIA2_XP2
238
    `define BOARD_ID 5
239
    `define BOARD_CK 50000000
240
    `define INVRES 1
241
`endif
242
 
243
`ifdef PISWORDS_RS485_LX9
244
    `define BOARD_ID 6
245
    `define BOARD_CK_REF 50000000
246
    `define BOARD_CK_MUL 4
247
    `define BOARD_CK_DIV 2
248
    `define INVRES 1
249
`endif
250
 
251
`ifdef DIGILENT_SPARTAN3_S200
252
    `define BOARD_ID 7
253
    `define BOARD_CK 50000000
254
`endif
255
 
256
`ifdef ALIEXPRESS_HPC40GBE_K420
257
    `define BOARD_ID 8
258
    //`define BOARD_CK 200000000
259
    `define BOARD_CK_REF 100000000
260
    `define BOARD_CK_MUL 11
261
    `define BOARD_CK_DIV 5
262
    `define XILINX7CLK 1
263
    `define INVRES 1
264
`endif
265
 
266
`ifdef QMTECH_ARTIX7_A35
267
    `define BOARD_ID 9
268
    `define BOARD_CK_REF 50000000
269
    `define BOARD_CK_MUL 20
270
    `define BOARD_CK_DIV 10
271
    `define XILINX7CLK 1
272
    `define VIVADO 1
273
    `define INVRES 1
274
`endif
275
 
276
`ifndef BOARD_ID
277
    `define BOARD_ID 0
278
    `define BOARD_CK 100000000
279
`endif
280
 
281
`ifdef BOARD_CK_REF
282
    `define BOARD_CK (`BOARD_CK_REF * `BOARD_CK_MUL / `BOARD_CK_DIV)
283
`endif
284
 
285
// darkuart baudrate automtically calculated according to board clock:
286
 
287
`ifndef __UARTSPEED__
288
  `define __UARTSPEED__ 115200
289
`endif
290
 
291
`define  __BAUD__ ((`BOARD_CK/`__UARTSPEED__))

powered by: WebSVN 2.1.0

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