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

Subversion Repositories zipcpu

[/] [zipcpu/] [trunk/] [rtl/] [cpudefs.v] - Diff between revs 64 and 69

Go to most recent revision | Show entire file | Details | Blame | View Log

Rev 64 Rev 69
Line 22... Line 22...
//      The number of LUTs the Zip CPU uses varies dramatically with the
//      The number of LUTs the Zip CPU uses varies dramatically with the
//      options defined in this file.
//      options defined in this file.
//
//
//
//
// Creator:     Dan Gisselquist, Ph.D.
// Creator:     Dan Gisselquist, Ph.D.
//              Gisselquist Tecnology, LLC
//              Gisselquist Technology, LLC
//
//
///////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////////
//
//
// Copyright (C) 2015, Gisselquist Technology, LLC
// Copyright (C) 2015, Gisselquist Technology, LLC
//
//
Line 51... Line 51...
//
//
// The first couple options control the Zip CPU instruction set, and how
// The first couple options control the Zip CPU instruction set, and how
// it handles various instructions within the set:
// it handles various instructions within the set:
//
//
//
//
// OPT_CONDITIONAL_FLAGS controls whether or not a conditional instruction
 
// is allowed to set flags.  If conditional instructions can set flags, then
 
// strings of conditional instructions will die whenever a flag setting 
 
// instruction is executed.  If they cannot, then you can execute a string
 
// of functions with no further conditions in them.  Set this flag to enable
 
// strings of instructions, as these can be a lot cheaper than the pipeline
 
// stalls associated with a conditional branch.
 
//
 
// This option will likely be changed in the future so that "CMP" and "TST"
 
// instructions set the flags even if they are conditional, to allow multiple
 
// conditions to be tested at once.
 
//
 
// I recommend setting this flag
 
//
 
`define OPT_CONDITIONAL_FLAGS
 
//
 
//
 
//
 
// OPT_ILLEGAL_INSTRUCTION is part of a new section of code that is supposed
// OPT_ILLEGAL_INSTRUCTION is part of a new section of code that is supposed
// to recognize illegal instructions and interrupt the CPU whenever one such
// to recognize illegal instructions and interrupt the CPU whenever one such
// instruction is encountered.  The goal is to create a soft floating point
// instruction is encountered.  The goal is to create a soft floating point
// unit via this approach, that can then be replaced with a true floating point
// unit via this approach, that can then be replaced with a true floating point
// unit.  As I'm not there yet, it just catches illegal instructions and
// unit.  As I'm not there yet, it just catches illegal instructions and
Line 97... Line 79...
//
//
`define OPT_MULTIPLY
`define OPT_MULTIPLY
//
//
//
//
//
//
 
// OPT_DIVIDE controls whether or not the divide instruction is built and
 
// included into the ZipCPU by default.  Set this option and a parameter will
 
// be set that causes the divide unit to be included.  (This parameter may
 
// still be overridden, as with any parameter ...)  If the divide is not
 
// included and OPT_ILLEGAL_INSTRUCTION is set, then the multiply will create
 
// an illegal instruction exception that will send the CPU into supervisor
 
// mode.
 
//
 
//
 
`define OPT_DIVIDE
 
//
 
//
 
//
 
// OPT_IMPLEMENT_FPU will (one day) control whether or not the floating point
 
// unit (once I have one) is built and included into the ZipCPU by default. 
 
// At that time, if this option is set then a parameter will be set that
 
// causes the floating point unit to be included.  (This parameter may
 
// still be overridden, as with any parameter ...)  If the floating point unit
 
// is not included and OPT_ILLEGAL_INSTRUCTION is set, then as with the
 
// multiply and divide any floating point instruction will result in an illegal
 
// instruction exception that will send the CPU into supervisor mode.
 
//
 
//
 
// `define      OPT_IMPLEMENT_FPU
 
//
 
//
 
//
 
// OPT_NEW_INSTRUCTION_SET controls whether or not the new instruction set
 
// is in use.  The new instruction set contains space for floating point
 
// operations, signed and unsigned divide instructions, as well as bit reversal
 
// and ... at least two other operations yet to be defined.  The decoder alone
 
// uses about 70 fewer LUTs, although in practice this works out to 12 fewer
 
// when all works out in the wash.  Further, floating point and divide
 
// instructions will cause an illegal instruction exception if they are not
 
// implemented--so software capability can be built to use these instructions
 
// immediately, even if the hardware is not yet ready.
 
//
 
// This option is likely to go away in the future, obsoleting the previous
 
// instruction set, so I recommend setting this option and switching to the
 
// new instruction set as soon as possible.
 
//
 
`define OPT_NEW_INSTRUCTION_SET
 
//
 
//
 
//
 
//
 
//
 
//
// OPT_SINGLE_FETCH controls whether or not the prefetch has a cache, and 
// OPT_SINGLE_FETCH controls whether or not the prefetch has a cache, and 
// whether or not it can issue one instruction per clock.  When set, the
// whether or not it can issue one instruction per clock.  When set, the
// prefetch has no cache, and only one instruction is fetched at a time.
// prefetch has no cache, and only one instruction is fetched at a time.
// This effectively sets the CPU so that only one instruction is ever 
// This effectively sets the CPU so that only one instruction is ever 
// in the pipeline at once, and hence you may think of this as a "kill 
// in the pipeline at once, and hence you may think of this as a "kill 
Line 135... Line 165...
//
//
`ifndef OPT_SINGLE_FETCH
`ifndef OPT_SINGLE_FETCH
//
//
//
//
//
//
// OPT_PRECLEAR_BUS allows an upcoming, unconditional, LOD/STO instruction
// OPT_PIPELINED is the natural result and opposite of using the single 
// to kick the prefetch off the memory bus so that the LOD/STO instruction may
// instruction fetch unit.  If you are not using that unit, the ZipCPU will
// use the bus without waiting for the prefetch cycle to complete.  While it
// be pipelined.  The option is defined here more for readability than 
// sounds like this should speed things up, it isn't clear that it speeds up
// anything else, since OPT_PIPELINED makes more sense than OPT_SINGLE_FETCH,
// programs that much--often the bus gets precleared for the LOD/STO, only
// well ... that and it does a better job of explaining what is going on.
// to have the next instruction stall because it wasn't loaded in time.
//
 
// In other words, leave this define alone--lest you break the ZipCPU.
 
//
 
`define OPT_PIPELINED
//
//
// While I recommend setting this flag, that recommendation may change in the
 
// future.
 
//
//
`define OPT_PRECLEAR_BUS
//
 
// OPT_TRADITIONAL_PFCACHE allows you to switch between one of two prefetch
 
// caches.  If enabled, a more traditional cache is implemented.  This more
 
// traditional cache (currently) uses many more LUTs, but it also reduces
 
// the stall count tremendously over the alternative hacked pipeline cache.
 
// (The traditional pfcache is also pipelined, whereas the pipeline cache
 
// implements a windowed approach to caching.)
 
//
 
// If you have the fabric to support this option, I recommend including it.
 
//
 
`define OPT_TRADITIONAL_PFCACHE
//
//
//
//
//
//
// OPT_EARLY_BRANCHING is an attempt to execute a BRA statement as early
// OPT_EARLY_BRANCHING is an attempt to execute a BRA statement as early
// as possible, to avoid as many pipeline stalls on a branch as possible.
// as possible, to avoid as many pipeline stalls on a branch as possible.
// It's not tremendously successful yet--BRA's suffer 3 stalls instead of 5,
// It's not tremendously successful yet--BRA's still suffer stalls,
// but I intend to keep working on this approach until the number of stalls
// but I intend to keep working on this approach until the number of stalls
// gets down to one or (ideally) zero.  That way a "BRA" can be used as the
// gets down to one or (ideally) zero.  (With the OPT_TRADITIONAL_PFCACHE, this
// compiler's branch prediction optimizer: BRA's don't stall, while branches on 
// gets down to a single stall cycle ...)  That way a "BRA" can be used as the
// conditions will always suffer about 5 stalls or so.
// compiler's branch prediction optimizer: BRA's barely stall, while branches
 
// on conditions will always suffer about 4 stall cycles or so.
//
//
// I recommend setting this flag, so as to turn early branching on.
// I recommend setting this flag, so as to turn early branching on.
//
//
`define OPT_EARLY_BRANCHING
`define OPT_EARLY_BRANCHING
//
//
Line 179... Line 221...
//
//
`define OPT_PIPELINED_BUS_ACCESS
`define OPT_PIPELINED_BUS_ACCESS
//
//
//
//
//
//
// OPT_SINGLE_CYCLE controls how the Zip CPU handles operations where the
`ifdef  OPT_NEW_INSTRUCTION_SET
// second of two instructions uses a register output from the first of the
//
// two.  If set, there will be no stalling between such a pair of instructions.
//
// If not set, the CPU will insert a stall between such a pair to give the
 
// result time to propagate to the second instruction.  Other than the existence
 
// of a stall, the CPU will still yield the same results for the same
 
// instructions.
 
//
 
// The purpose of this is really timing: With this option defined, a logical
 
// or combinatorial mux is placed prior to the input of the ALU.  This mux,
 
// together with whatever ALU operation is to take place, must both fit within
 
// one clock cycle.  If they cannot be made to fit within the one clock cycle,
 
// then either the clock must be slowed down so that they can fit, or this
 
// flag needs to be turned off (not set) to get rid of the mux--hence speeding
 
// up the clock while slowing down some instructions.
 
//
//
`define OPT_SINGLE_CYCLE
// The new instruction set also defines a set of very long instruction words.
 
// Well, calling them "very long" instruction words is probably a misnomer,
 
// although we're going to do it.  They're really 2x16-bit instructions---
 
// instruction words that pack two instructions into one word.  (2x14 bit
 
// really--'cause you need a bit to note the instruction is a 2x instruction,
 
// and then 3-bits for the condition codes ...)  Set OPT_VLIW to include these
 
// double instructions as part of the new instruction set.  These allow a single
 
// instruction to contain two instructions within.   These instructions are
 
// designed to get more code density from the instruction set, and to hopefully
 
// take some pain off of the performance of the pre-fetch and instruction cache.
 
//
 
// These new instructions, however, also necessitate a change in the Zip
 
// CPU--the Zip CPU can no longer execute instructions atomically.  It must
 
// now execute non-VLIW instructions, or VLIW instruction pairs, atomically. 
 
// This logic has been added into the ZipCPU, but it has not (yet) been
 
// tested thoroughly.
 
//
 
// Oh, and the assembler, the debugger, and the object file dumper, and the
 
// simulator all need to be updated as well ....
 
//
 
`define OPT_VLIW
 
//
 
//
 
`endif
//
//
//
//
`endif  // OPT_SINGLE_FETCH
`endif  // OPT_SINGLE_FETCH
//
//
//
//
 
//
 
// Now let's talk about peripherals for a moment.  These next two defines
 
// control whether the DMA controller is included in the Zip System, and
 
// whether or not the 8 accounting timers are also included.  Set these to
 
// include the respective peripherals, comment them out not to.
 
//
 
`define INCLUDE_DMA_CONTROLLER
 
`define INCLUDE_ACCOUNTING_COUNTERS
 
//
 
//
 
// `define      DEBUG_SCOPE
 
`define NEW_PREFETCH_VERSION
 
//
`endif  // CPUDEFS_H
`endif  // CPUDEFS_H
 
 
 No newline at end of file
 No newline at end of file

powered by: WebSVN 2.1.0

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