mirror of
https://github.com/lcbcFoo/ReonV.git
synced 2025-04-18 18:44:43 -04:00
702 lines
27 KiB
Text
702 lines
27 KiB
Text
|
|
Name of configuration
|
|
CONFIG_CFG_NAME
|
|
The VHDL name of the created configuration record. Must be a valid
|
|
VHDL identifier.
|
|
|
|
Prompt for target technology
|
|
CONFIG_SYN_GENERIC
|
|
Selects the target technology. The following are available:
|
|
|
|
- Generic: Generic FPGA or ASIC targets if your synthesis tool
|
|
is capable of infering RAMs and pads automatically.
|
|
|
|
- ATC35: Atmel-Nantes 0.35 um rad-hard CMOS
|
|
|
|
- ATC25: Atmel-Nantes 0.25 um rad-hard CMOS
|
|
|
|
- ATC18: Atmel-Nantes 0.18 um rad-hard CMOS with Virage ram cells
|
|
|
|
- FS90: UMC with Faraday FS90 libraries
|
|
|
|
- UMC-0.18 : UMC 0.18 um CMOS with Virtual Silicon libraries
|
|
|
|
- TSMC-0.25: TSMC 0.25 um CMOS
|
|
|
|
- Xilinx-Virtex: Xilinx Virtex libraries
|
|
|
|
- Xilinx-Virtex2: Xilinx Virtex2 libraries
|
|
|
|
- Actel ProAsic and Axellerator FPGAs
|
|
|
|
Infer ram
|
|
CONFIG_SYN_INFER_RAM
|
|
Say Y here if you want the synthesis tool to infer your
|
|
RAMs for cache memories and trace buffer. Say N to directly
|
|
instantiate technology-specific RAM cells from the selected
|
|
target technology package (tech_xxx.vhd).
|
|
|
|
Infer register file
|
|
CONFIG_SYN_INFER_REGF
|
|
Say Y here if you want the synthesis tool to infer the RAMS in
|
|
the register file. Say N to directly instantiate technology-
|
|
specific RAM cells from the selected target technology package
|
|
(tech_xxx.vhd).
|
|
|
|
Infer rom
|
|
CONFIG_SYN_INFER_ROM
|
|
Say Y here if you want the synthesis tool to infer the
|
|
(optional) internal boot ROM. Say N to directly instantiate
|
|
technology-specific ROM cells from the selected target
|
|
technology package (tech_xxx.vhd). Most users should say Y
|
|
here since only the Virtex package provides support for hard
|
|
ROM cells, and then only through Coregen.
|
|
|
|
Infer pads
|
|
CONFIG_SYN_INFER_PADS
|
|
Say Y here if you want the synthesis tool to infer pads.
|
|
Say N to directly instantiate technology-specific pads from
|
|
the selected target technology package (tech_xxx.vhd).
|
|
|
|
Infer multiplier
|
|
CONFIG_SYN_INFER_MULT
|
|
Say Y here if you want the synthesis tool to infer a multiplier
|
|
for the UMUL/SMUL instructions. Say N to use a structural
|
|
multiplier provided in multlib.vhd. FPGA targets should say Y
|
|
here, ASIC targets should say N unless your synthesis tool can
|
|
infer some really fast multiplier core.
|
|
|
|
Use dual-port RAMS for DSU trace buffer
|
|
CONFIG_SYN_TRACE_DPRAM
|
|
Say Y here if you want to use dual-port RAMs instead of single-port
|
|
RAMs for the DSU trace buffer. This will reduce the total number of
|
|
RAM blocks. Note that the target tech package must have support for
|
|
DPRAM's, which is currently only implemented for Virtex, ATC25, and
|
|
TSMC025.
|
|
|
|
Improve register file write timing
|
|
CONFIG_SYN_RFTYPE
|
|
If you say Y here, the register file write timing will be improved
|
|
by clocking the write port on the rising edge, providing a whole
|
|
cycle for write strobe generation. If you say N, both read and write
|
|
ports will be clocked on the falling edge of the clock, simplifying
|
|
timing analysis.
|
|
|
|
This option is not implemented on all targets. Say Y when possible.
|
|
|
|
Use Virtex CLKDLL for clock synchronisation
|
|
CONFIG_CLK_VIRTEX
|
|
Valid for all Spartan and Virtex targets. If enabled, the input
|
|
clock will be re-synchronized using a Virtex CLKDLL macro. This
|
|
will improve clock-to-output delays and allow scaling the clock
|
|
with a factor 0.5, 1.0, or 2.0. This option also re-synchronizes
|
|
the SDRAM clock, allowing the use of the SDRAM controller without
|
|
the inverted-clock option. For this to work, connect SDCLK to PLLREF.
|
|
|
|
WARNING: This option cannot be simulated unless you also compile
|
|
the VHDL component libraries for the Virtex macro blocks (comes
|
|
with the Xilinx ISE tool). Also, the input clock must be at
|
|
least 24 MHz for the CKLDLL to work.
|
|
|
|
System clock multiplier
|
|
CONFIG_CLKDLL_1_2
|
|
Scale the input clock with a factor of 0.5, 1.0, or 2.0. Useful
|
|
when the target board has an oscillator with a too high (or low)
|
|
frequency for your design. The divided clock will be used as the
|
|
main clock for the whole processor (except PCI and ethernet clocks).
|
|
|
|
Use Virtex-II DCM for clock synchronisation
|
|
CONFIG_CLK_VIRTEX2
|
|
Valid for Spartan2/Spartan3/Virtex2 targets. If enabled, the input
|
|
clock will be re-synchronized using a Virtex DCM macro. This
|
|
will improve clock-to-output delays and allow scaling the clock
|
|
frequency. This option also re-synchronizes the SDRAM clock,
|
|
allowing the use of the SDRAM controller without the inverted-clock
|
|
option. For this to work, connect SDCLK to PLLREF.
|
|
|
|
WARNING: This option cannot be simulated unless you also compile
|
|
the VHDL component libraries for the Virtex macro blocks (comes
|
|
with the Xilinx ISE tool).
|
|
|
|
System clock multiplier
|
|
CONFIG_DCM_2_3
|
|
Scale the input clock with a factor of 2/3, 3/4, 1, 4/3, 3/2,
|
|
2, 3, and 4. Useful when the target board has an oscillator with a
|
|
too high (or low) frequency for your design. The divided clock will
|
|
be used as the main clock for the whole processor (except PCI and
|
|
ethernet clocks). NOTE: the resulting frequency must be at least
|
|
24 MHz or the DCM might not work (see Virtex-II datasheet).
|
|
|
|
Enable CLKDLL for PCI clock
|
|
CONFIG_PCI_DLL
|
|
Say Y here to re-synchronize the PCI clock using a
|
|
Virtex BUFGDLL macro. Will improve PCI clock-to-output
|
|
delays on the expense of input-setup requirements.
|
|
|
|
Use PCI clock system clock
|
|
CONFIG_PCI_SYSCLK
|
|
Say Y here to the PCI clock to generate the system clock.
|
|
The PCI clock can be scaled using the DCM or CLKDLL to
|
|
generate a suitable processor clock.
|
|
|
|
Number of SPARC register windows
|
|
CONFIG_IU_NWINDOWS
|
|
The SPARC architecture (and LEON) allows 2 - 32 register windows.
|
|
However, any number except 8 will require that you modify and
|
|
recompile your run-time system or kernel. Unless you know what
|
|
you are doing, use 8.
|
|
|
|
SPARC V8 multiply and divide instruction
|
|
CONFIG_IU_V8MULDIV
|
|
If you say Y here, the SPARC V8 multiply and divide instructions
|
|
will be implemented. The instructions are: UMUL, UMULCC, SMUL,
|
|
SMULCC, UDIV, UDIVCC, SDIV, SDIVCC. In code containing frequent
|
|
integer multiplications and divisions, significant performance
|
|
increase can be achieved. Emulated floating-point operations will
|
|
also benefit from this option.
|
|
|
|
By default, the sparc-rtems-gcc compiler does not emit these
|
|
instructions and your code must be compiled with -mv8 to see any
|
|
performance increase. On the other hand, code compiled with -mv8
|
|
will generate an illegal instruction trap when executed on processors
|
|
with this option disabled.
|
|
|
|
The divider consumes approximately 2 kgates, the size of the
|
|
multiplier depends on the latency.
|
|
|
|
Multiplier latency
|
|
CONFIG_IU_MUL_LATENCY_1
|
|
The multiplier used for UMUL/SMUL instructions can be implemented
|
|
with 1, 2, 4, 5 or 35 cycles latency. Lower latency gives higher
|
|
multiplication performance, but increases area and might reduce
|
|
the maximum clock frequency. The best area/timing/performance
|
|
compromise is usually 4 or 5. A latency of 5 cycles will use the
|
|
same multiplier (16x16) as for 4 cycles, but with a pipeline register
|
|
to improve timing.
|
|
|
|
Multiplier latency
|
|
CONFIG_IU_MUL_MAC
|
|
If you say Y here, the SPARC V8e UMAC/SMAC (multiply-accumulate)
|
|
instructions will be enabled. The instructions implement a
|
|
single-cycle 16x16->32 bits multiply with a 40-bits accumulator.
|
|
The details of these instructions can be found in the LEON manual,
|
|
section 2.4. Note that the multiplier must be configured with 4
|
|
cycles latency for this option to be enabled.
|
|
|
|
Load latency
|
|
CONFIG_IU_LDELAY
|
|
Defines the pipeline load delay (= pipeline cycles before the data
|
|
from a load instruction is available for the next instruction).
|
|
One cycle gives best performance, but might create a critical path
|
|
on targets with slow (data) cache memories. A 2-cycle delay can
|
|
improve timing but will reduce performance with about 5 - 8%.
|
|
All FPGA targets and most ASIC targets do fine with 1.
|
|
|
|
Icc interlock
|
|
CONFIG_IU_ICCHOLD
|
|
If you say Y here, a pipeline stall cycle will be introduced when
|
|
an instruction that modifies the condition codes is directly followed
|
|
by a branch instruction that uses these codes (BICC, TICC). The option
|
|
reduces the performance with about 5% but significantly improves timing
|
|
on FPGA targets. Recommendation: say Y on FPGA targets, N on ASIC targets.
|
|
|
|
Fast jump address generation
|
|
CONFIG_IU_FASTJUMP
|
|
If you say Y here, jump address generation will accelerated by
|
|
using a separate address adder. Will improve timing on most targets
|
|
to the cost of approximately 300 gates.
|
|
|
|
Fast instruction decoding
|
|
CONFIG_IU_FASTDECODE
|
|
If you say Y here, instruction decode timing will be improved by adding
|
|
some extra parallel logic. Useful when you have a critical path
|
|
ending at the register file read address ports.
|
|
|
|
Register file power saving
|
|
CONFIG_IU_RFPOW
|
|
If you say Y here, the read ports of the register file will be disabled
|
|
when not used in an attempt to save power. Only implemented on TSMC-0.25,
|
|
UMC-0.18 and UMC-FS90 targets. Might lead to a critical path to the
|
|
register file read enable signal. If so, say N and the read ports will
|
|
be permanently enabled. Also say N if saving a few gates feels better
|
|
than saving a few milli-Watts.
|
|
|
|
Hardware watchpoints
|
|
CONFIG_IU_WATCHPOINTS
|
|
The processor can have up to 4 hardware watchpoints, allowing to
|
|
create both data and instruction breakpoints at any memory location,
|
|
also in PROM. Each watchpoint will use approximately 500 gates.
|
|
Use 0 to disable the watchpoint function.
|
|
|
|
Processor implementation ID
|
|
CONFIG_IU_IMPL
|
|
Each SPARC processor has a 4-bit implementation ID hardcoded in the
|
|
processor status register (%psr). You should not use numbers 0 - 9
|
|
which are used by existing implementations. The value 10 will be
|
|
assigned to Gaisler Research use this value unless you have a
|
|
compelling reason not to. In any case, do NOT use 1 since this
|
|
number is used by ERC32 and will cause applications compiled with
|
|
LECCS to fail.
|
|
|
|
Processor version ID
|
|
CONFIG_IU_VER
|
|
Each SPARC processor has a 4-bit version ID hardcoded in the
|
|
processor status register (%psr). Use 2 for LEON2.
|
|
|
|
Floating-point enable
|
|
CONFIG_FPU_ENABLE
|
|
Say Y here to enable the floating-point unit. Note that only the
|
|
(incomplete) LTH FPU is provided with the LEON VHDL model. The
|
|
Gaisler GRFPU and the Meiko FPU are commercial cores and must be
|
|
obtained separately.
|
|
|
|
FPU selection
|
|
CONFIG_FPU_GRFPU
|
|
Select between Gaisler Research's GRFPU, the Sun Meiko FPU core or
|
|
the open-source LTH core from Lund's University. The Meiko and GRFPU
|
|
are fully IEEE-754 compatible and supports all SPARC FPU instructions.
|
|
The LTH FPU also supports IEEE-754, but does not implement the FMUL,
|
|
FDIV and FSQRT instructions and cannot (yet) be used for general
|
|
floating-point code.
|
|
|
|
FPU version ID
|
|
CONFIG_FPU_VER
|
|
Each SPARC FPU has a 3-bit version ID hardcoded in the FPU status
|
|
register (%fsr). Has no impact on operation or any (known) software.
|
|
Use as you like, staying with 0 is safe.
|
|
|
|
Co-processor enable
|
|
CONFIG_CP_ENABLE
|
|
Say Y here to enable the interface to a (custom) co-processor unit.
|
|
Unless you actually want to add your own co-processor, say N.
|
|
|
|
Co-processor configuration
|
|
CONFIG_CP_CFG
|
|
The VHDL name of the co-processor configuration to be used. Should
|
|
exist in target.vhd.
|
|
|
|
Instruction cache associativity
|
|
CONFIG_ICACHE_ASSO1
|
|
The instruction cache can be implemented as a multi-set cache with
|
|
1 - 4 sets. Higher associativity usually increases the cache hit
|
|
rate and thereby the performance. The downside is higher power
|
|
consumption and increased gate-count for tag comparators.
|
|
|
|
Note that a 1-set cache is effectively a direct-mapped cache.
|
|
|
|
Instruction cache set size
|
|
CONFIG_ICACHE_SZ1
|
|
The size of each set in the instuction cache (kbytes). Valid values
|
|
are 1 - 64 in binary steps. Note that the full range is only supported
|
|
by the generic and virtex2 targets. Most target packages are limited
|
|
to 2 - 16 kbyte. Large set size gives higher performance but might
|
|
affect the maximum frequency (on ASIC targets). The total instruction
|
|
cache size is the number of set multiplied with the set size.
|
|
|
|
Instruction cache line size
|
|
CONFIG_ICACHE_LZ16
|
|
The instruction cache line size. Can be set to either 16 or 32
|
|
bytes per line. Instruction caches typically benefit from larger
|
|
line sizes, but on small caches, it migh be better with 16 bytes/line
|
|
to limit eviction miss rate.
|
|
|
|
Instruction cache replacement algorithm
|
|
CONFIG_ICACHE_ALGORND
|
|
Cache replacement algorithm for caches with 2 - 4 sets. The 'random'
|
|
algorithm selects the set to evict randomly. The least-recently-used
|
|
(LRR) algorithm evicts the set least recently replaced. The least-
|
|
recently-used (LRU) algorithm evicts the set least recently accessed.
|
|
The random algorithm uses a simple 1- or 2-bit counter to select
|
|
the eviction set and has low area overhead. The LRR scheme uses one
|
|
extra bit in the tag ram and has therefore also low area overhead.
|
|
However, the LRR scheme can only be used with 2-set caches. The LRU
|
|
scheme has typically the best performance but also highest area overhead.
|
|
A 2-set LRU uses 1 flip-flop per line, a 3-set LRU uses 3 flip-flops
|
|
per line, and a 4-set LRU uses 5 flip-flops per line to store the access
|
|
history.
|
|
|
|
Instruction cache locking
|
|
CONFIG_ICACHE_LOCK
|
|
Say Y here to enable cache locking in the instruction cache.
|
|
Locking can be done on cache-line level, but will increase the
|
|
width of the tag ram with one bit. If you don't know what
|
|
locking is good for, it is safe to say N.
|
|
|
|
Data cache associativity
|
|
CONFIG_DCACHE_ASSO1
|
|
The data cache can be implemented as a multi-set cache with
|
|
1 - 4 sets. Higher associativity usually increases the cache hit
|
|
rate and thereby the performance. The downside is higher power
|
|
consumption and increased gate-count for tag comparators.
|
|
|
|
Note that a 1-set cache is effectively a direct-mapped cache.
|
|
|
|
Data cache set size
|
|
CONFIG_DCACHE_SZ1
|
|
The size of each set in the data cache (kbytes). Valid values are
|
|
1 - 64 in binary steps. Note that the full range is only supported
|
|
by the generic and virtex2 targets. Most target packages are limited
|
|
to 2 - 16 kbyte. A large cache gives higher performance but the
|
|
data cache is timing critical an a too large setting might affect
|
|
the maximum frequency (on ASIC targets). The total data cache size
|
|
is the number of set multiplied with the set size.
|
|
|
|
Data cache line size
|
|
CONFIG_DCACHE_LZ16
|
|
The data cache line size. Can be set to either 16 or 32 bytes per
|
|
line. A smaller line size gives better associativity and higher
|
|
cache hit rate, but requires a larger tag memory.
|
|
|
|
Data cache replacement algorithm
|
|
CONFIG_DCACHE_ALGORND
|
|
See the explanation for instruction cache replacement algorithm.
|
|
|
|
Data cache locking
|
|
CONFIG_DCACHE_LOCK
|
|
Say Y here to enable cache locking in the data cache.
|
|
Locking can be done on cache-line level, but will increase the
|
|
width of the tag ram with one bit. If you don't know what
|
|
locking is good for, it is safe to say N.
|
|
|
|
Data cache snooping
|
|
CONFIG_DCACHE_SNOOP
|
|
Say Y here to enable data cache snooping on the AHB bus. Is only
|
|
useful if you have additional AHB masters such as the DSU or a
|
|
target PCI interface. Note that the target technology must support
|
|
dual-port RAMs for this option to be enabled. Dual-port RAMS are
|
|
currently supported on Virtex/2, ATC25, ATC18 and TSMC025 targets.
|
|
|
|
Data cache snooping implementation
|
|
CONFIG_DCACHE_SNOOP_SLOW
|
|
Selects the snooping implementation. Use 'slow' if you don't have
|
|
AHB slaves in cacheable areas which are capable of supporting
|
|
zero-waitstates non-sequential write accesses. Otherwise use 'fast'
|
|
and suffer a few kgates extra area.
|
|
|
|
Fast read-data generation
|
|
CONFIG_DCACHE_RFAST
|
|
Say Y here to improve the data read timing in multi-set caches.
|
|
FPGA implementations usually do fine with N, while ASIC
|
|
implementations tuned for maximum frequency should say Y. Increases
|
|
the area with about 200 gates per set.
|
|
|
|
Fast write-data generation
|
|
CONFIG_DCACHE_WFAST
|
|
Say Y here to improve the timing of the data inputs to the data
|
|
cache data memory in multi-set caches. FPGA implementations
|
|
usually do fine with N, while ASIC implementations tuned for
|
|
maximum frequency should say Y. Increases the area with about
|
|
200 gates per set.
|
|
|
|
Local data ram
|
|
CONFIG_DCACHE_LRAM
|
|
Say Y here to add a local ram to the data cache controller.
|
|
Accesses to the ram (load/store) will be performed at 0 waitstates
|
|
and store data will never be written back to the AHB bus.
|
|
|
|
Size of local data ram
|
|
CONFIG_DCACHE_LRAM_SZ1
|
|
Defines the size of the local data ram in Kbytes. Note that most
|
|
technology libraries do not support larger rams than 16 Kbyte.
|
|
|
|
Start address of local data ram
|
|
CONFIG_DCACHE_LRSTART
|
|
Defines the 8 MSB bits of start address of the local data ram.
|
|
By default set to 8f (start address = 0x8f000000), but any value
|
|
(except 0) is possible. Note that the local data ram 'shadows'
|
|
a 16 Mbyte block of the address space.
|
|
|
|
MMU enable
|
|
CONFIG_MMU_ENABLE
|
|
Say Y here to enable the Memory Management Unit.
|
|
|
|
MMU split icache/dcache table lookaside buffer
|
|
CONFIG_MMU_COMBINED
|
|
Select "combined" for a combined icache/dcache table lookaside buffer,
|
|
"split" for a split icache/dcache table lookaside buffer
|
|
|
|
MMU tlb replacement scheme
|
|
CONFIG_MMU_REPARRAY
|
|
Select "LRU" to use the "least recently used" algorithm for TLB
|
|
replacement, or "Increment" for a simple incremental replacement
|
|
scheme.
|
|
|
|
Combined i/dcache tlb
|
|
CONFIG_MMU_I2
|
|
Select the number of entries for the instruction TLB, or the
|
|
combined icache/dcache TLB if such is used.
|
|
|
|
Split tlb, dcache
|
|
CONFIG_MMU_D2
|
|
Select the number of entries for the dcache TLB.
|
|
|
|
8-bit memory support
|
|
CONFIG_MCTRL_8BIT
|
|
If you say Y here, the PROM/SRAM memory controller will support
|
|
8-bit mode, i.e. operate from 8-bit devices as if they were 32-bit.
|
|
Say N to save a few hundred gates.
|
|
|
|
16-bit memory support
|
|
CONFIG_MCTRL_16BIT
|
|
If you say Y here, the PROM/SRAM memory controller will support
|
|
16-bit mode, i.e. operate from 16-bit devices as if they were 32-bit.
|
|
Say N to save a few hundred gates.
|
|
|
|
Write strobe feedback
|
|
CONFIG_MCTRL_WFB
|
|
If you say Y here, the PROM/SRAM write strobes (WRITEN, WEN) will
|
|
be used to enable the data bus drivers during write cycles. This
|
|
will guarantee that the data is still valid on the rising edge of
|
|
the write strobe. If you say N, the write strobes and the data bus
|
|
drivers will be clocked on the rising edge, potentially creating
|
|
a hold time problem in external memory or I/O. However, in all
|
|
practical cases, there is enough capacitance in the data bus lines
|
|
to keep the value stable for a few (many?) nano-seconds after the
|
|
buffers have been disabled, making it safe to say N and remove a
|
|
combinational path in the netlist that might be difficult to
|
|
analyze.
|
|
|
|
Write strobe feedback
|
|
CONFIG_MCTRL_5CS
|
|
If you say Y here, the 5th (RAMSN[4]) SRAM chip select signal will
|
|
be enabled. If you don't intend to use it, say N and save some gates.
|
|
|
|
SDRAM controller enable
|
|
CONFIG_MCTRL_SDRAM
|
|
Say Y here to enabled the PC100/PC133 SDRAM controller. If you don't
|
|
intend to use SDRAM, say N and save about 1 kgates.
|
|
|
|
SDRAM controller inverted clock
|
|
CONFIG_MCTRL_SDRAM_INVCLK
|
|
If you say Y here, the SDRAM clock will be inverted in respect to the
|
|
system clock and the SDRAM signals. This will limit the SDRAM frequency
|
|
to 50/66 MHz, but has the benefit that you will not need a PLL to
|
|
generate the SDRAM clock. On FPGA targets, say Y. On ASIC targets,
|
|
say N and tell your foundry to balance the SDRAM clock output.
|
|
|
|
SDRAM separate address buses
|
|
CONFIG_MCTRL_SDRAM_SEPBUS
|
|
Say Y here if your SDRAM is connected through separate address
|
|
and data buses (SA & SD). This is the case on the GR-CPCI-XC2V6000
|
|
board, but not on the GR-PCI-XC2V3000 or Avnet XCV1500E boards.
|
|
|
|
Default AHB master
|
|
CONFIG_AHB_DEFMST
|
|
Sets the default AHB master (see AMBA 2.0 specification for definition).
|
|
Should not be set to a value larger than the number of AHB masters - 1.
|
|
For highest processor performance, leave it at 0.
|
|
|
|
Support AHB split-transactions
|
|
CONFIG_AHB_SPLIT
|
|
Say Y here to enable AHB split-transaction support in the AHB arbiter.
|
|
Unless you actually have an AHB slave that can generate AHB split
|
|
responses, say N and save some gates. None of the AHB slaves provided
|
|
with LEON generates split, so N is a safe choice.
|
|
|
|
AHB status register enable
|
|
CONFIG_PERI_AHBSTAT
|
|
If you want the AHB status register functionality say Y here.
|
|
The register will catch the address and parameters of AHB transfers
|
|
that are terminated with an error response. Saying N will save
|
|
about 500 gates.
|
|
|
|
RAM write-protectionenable
|
|
CONFIG_PERI_WPROT
|
|
If you want to enable RAM write protection (LEON manual 7.13) say Y here.
|
|
Otherwise say N and save 1 kgates.
|
|
|
|
LEON configuration register
|
|
CONFIG_PERI_LCONF
|
|
Enables the LEON configuration register that shows how the model was
|
|
configured. The register is necessary for the test benches to run, and
|
|
also needed by applications compiled with LECCS. Always say Y.
|
|
|
|
Secondary interrupt controller enable
|
|
CONFIG_PERI_IRQ2
|
|
Say Y here to enable the secondary interrupt controller (LEON
|
|
manual 6.3). Routing of the interrupt sources is done in mcore.vhd.
|
|
It is safe to say N.
|
|
|
|
Secondary interrupt controller configuration
|
|
CONFIG_PERI_IRQ2_CFG
|
|
The VHDL name of the secondary interrupt controller configuration
|
|
to be used. Should exist in target.vhd.
|
|
|
|
Watchdog enable
|
|
CONFIG_PERI_WDOG
|
|
Say Y here to enable the watchdog functionallity in the timer module.
|
|
Unless you need a watchdog, say N and save 200 gates.
|
|
|
|
On-chip ram
|
|
CONFIG_AHBRAM_ENABLE
|
|
Say Y here to add a block on on-chip ram to the AHB bus. The ram
|
|
will be attached at address 0x60000000.
|
|
|
|
On-chip ram size
|
|
CONFIG_AHBRAM_SZ1
|
|
Set the size of the on-chip AHB ram. The ram is infered/instantiated
|
|
as four byte-wide ram slices to allow byte and half-word write
|
|
accesses. It is therefore essential that the target package can
|
|
infer byte-wide rams. This is currently supported on the generic,
|
|
virtex, virtex2, proasic and axellerator targets.
|
|
|
|
DSU enable
|
|
CONFIG_DSU_ENABLE
|
|
The debug support unit (DSU) allows non-intrusive debugging and tracing
|
|
of both executed instructions and AHB transfers. If you want to enable
|
|
the DSU, say Y here and select the configuration below.
|
|
|
|
Trace buffer enable
|
|
CONFIG_DSU_TRACEBUF
|
|
Say Y to enable the trace buffer. The buffer is not necessary for
|
|
debugging, only for tracing instructions and data transfers.
|
|
|
|
Enable mixed tracing
|
|
CONFIG_DSU_MIXED_TRACE
|
|
If you say Y here, simultaneous instruction and AHB tracing will be
|
|
possible. A N will still allow tracing of both, but not simultaneously.
|
|
|
|
Size of trace buffer
|
|
CONFIG_DSU_TRACESZ64
|
|
Select the number of entries on the trace buffer. For each entry,
|
|
16 bytes (128 bits) will be needed. A 128-entry buffer will need
|
|
2 kbyte.
|
|
|
|
PCI interface enable
|
|
CONFIG_PCI_ENABLE
|
|
To enable a PCI interface, say Y here.
|
|
|
|
PCI interface type
|
|
CONFIG_PCI_TARGET
|
|
Three PCI cores are provided with this version of Leon: a simple
|
|
target-only interface without fifos, a fast target interface with
|
|
configurable fifos, and a full master-target core with fifos.
|
|
The simple target-only interface is small and robust, and is suitable
|
|
to be used for DSU communications via PCI. The other two cores core
|
|
are suitable when high transfer rates or a master interface are needed.
|
|
|
|
PCI trace buffer
|
|
CONFIG_PCI_TRACE
|
|
The PCI trace buffer implements a simple on-chip logic analyzer
|
|
to trace the PCI signals. The PCI AD bus and most control signals
|
|
are stored in a circular buffer, and can be read out by the DSU
|
|
or any other AHB master. See the manual for detailed operation.
|
|
Only available for target technologies with dual-port rams.
|
|
|
|
PCI trace buffer depth
|
|
CONFIG_PCI_TRACE256
|
|
Select the number of entries in the PCI trace buffer. Each entry
|
|
will use 6 bytes of on-chip (block) ram.
|
|
|
|
PCI FIFO depth
|
|
CONFIG_PCI_FIFO8
|
|
The number words in the PCI FIFO buffers in the master-target
|
|
core. The master interface uses four 33-bit wide FIFOs, while the
|
|
target interface uses two.
|
|
|
|
Ethernet MAC enable
|
|
CONFIG_ETH_ENABLE
|
|
Say Y here to enable a Ethernet MAC from OpenCores. The control
|
|
registers of the MAC will be mapped to 0xb0000000.
|
|
|
|
Ethernet MAC transmitt FIFO depth
|
|
CONFIG_ETH_TXFIFO
|
|
The number of 32-bit words in the transmitt FIFO. 8 words is a
|
|
good compromise.
|
|
|
|
Ethernet MAC receive FIFO depth
|
|
CONFIG_ETH_RXFIFO
|
|
The number of 32-bit words in the receiver FIFO. 8 words is a
|
|
good compromise.
|
|
|
|
Ethernet MAC burts length
|
|
CONFIG_ETH_BURST
|
|
The length of the burst on the AHB when moving data to and from
|
|
the FIFOs. A good compromise is half of the FIFO depth.
|
|
|
|
Fault-tolerance enable
|
|
CONFIG_FT_ENABLE
|
|
Say Y here to enable the fault-tolerance features in LEON-FT. If you
|
|
only have access to the the public LGPL model, say N or the model
|
|
will not compile. If you do have the LEON-FT model, say Y here
|
|
even if you say N to all other options.
|
|
|
|
Boot selection
|
|
CONFIG_BOOT_EXTPROM
|
|
The processor can be configured to boot from external memory, internal
|
|
ROM, or both. The internal ROM contains by default the PMON monitor
|
|
(LEON manual 11.8). If the 'both' option is selected, boot source will
|
|
be controlled through PIO[4].
|
|
|
|
Default RAM read waitstates
|
|
CONFIG_BOOT_RWS
|
|
If booting from internal ROM is selected, the memory controller will
|
|
automatically initialise the SRAM read waitstates setting with this
|
|
value (valid range is 0 - 3).
|
|
|
|
Default RAM write waitstates
|
|
CONFIG_BOOT_WWS
|
|
If booting from internal ROM is selected, the memory controller will
|
|
automatically initialise the SRAM write waitstates setting with this
|
|
value (valid range is 0 - 3).
|
|
|
|
System clock
|
|
CONFIG_BOOT_SYSCLK
|
|
If booting from internal ROM is selected, this value should reflect
|
|
the system clock frequency. This will allow proper default
|
|
initialisation of the timer unit and UART baud-rate generation.
|
|
|
|
UART baud rate
|
|
CONFIG_BOOT_BAUDRATE
|
|
If booting from internal ROM is selected, use this value to
|
|
automatically set the UART baud-rate.
|
|
|
|
Select external baud-rate
|
|
CONFIG_BOOT_EXTBAUD
|
|
If you say Y here and booting from internal ROM is selected, the UART
|
|
baud-rate scaler register will be initialised from PIO[7:0].
|
|
|
|
Internal ROM addres bits
|
|
CONFIG_BOOT_PROMABITS
|
|
Defines the with of the internal ROM address bus. 11 bits is enough
|
|
for 2 kbytes.
|
|
|
|
UART debugging
|
|
CONFIG_DEBUG_UART
|
|
During simulation, the output from the UARTs is printed on the
|
|
simulator console. Since the ratio between the system clock and
|
|
UART baud-rate is quite high, simulating UART output will be very
|
|
slow. If you say Y here, the UARTs will print a character as soon
|
|
as it is stored in the transmitter data register. The transmitter
|
|
ready flag will be permanently set, speeding up simulation. However,
|
|
the output on the UART tx line will be garbled. Has not impact on
|
|
synthesis, but will cause the LEON test bench to fail.
|
|
|
|
IU register tracing
|
|
CONFIG_DEBUG_IURF
|
|
If you say Y here, all writes to the integer unit register file will be
|
|
printed on the simulator console.
|
|
|
|
FPU register tracing
|
|
CONFIG_DEBUG_FPURF
|
|
If you say Y here, all writes to the floating-point unit register file
|
|
will be printed on the simulator console.
|
|
|
|
Continue on reset trap
|
|
CONFIG_DEBUG_NOHALT
|
|
The SPARC standard mandates that when error mode is entered,
|
|
the processor should be halted. If you say Y here, a reset trap
|
|
(tt = 0x0) will be take on error mode and the processor will
|
|
not be halted. Use only for testing, since it will not be
|
|
possible to stop the processor with this option enabled!
|
|
|
|
32-bit program counters
|
|
CONFIG_DEBUG_PC32
|
|
Since the LSB 2 bits of the program counters always are zero, they are
|
|
normally not implemented. If you say Y here, the program counters will
|
|
be implemented with full 32 bits, making debugging of the VHDL model
|
|
much easier. Turn of this option for synthesis or you will be wasting
|
|
area.
|
|
|
|
|
|
|