| Line 162... |
Line 162... |
\section{Addressing}
|
\section{Addressing}
|
\label{sec:addressing}
|
\label{sec:addressing}
|
|
|
All addressing in \lxp{} is indirect. In order to access a memory location, its address must be stored in a register; any available register can be used for this purpose.
|
All addressing in \lxp{} is indirect. In order to access a memory location, its address must be stored in a register; any available register can be used for this purpose.
|
|
|
Some instructions, namely \instr{lsb} (\instrname{Load Signed Byte}), \instr{lub} (\instrname{Load Unsigned Byte}) and \instr{sb} (\instrname{Store Byte}) provide byte-granular access, in which case all 32 bits in the address are significant. Otherwise the least two address bits are ignored as \lxp{} doesn't support unaligned access to 32-bit data words (during simulation, a warning is emitted if such a transaction is attempted).
|
\lxp{} uses a 32-bit address space. Each address refers to an individual byte. Some instructions, namely \instr{lsb} (\instrname{Load Signed Byte}), \instr{lub} (\instrname{Load Unsigned Byte}) and \instr{sb} (\instrname{Store Byte}) provide byte-granular access, in which case all 32 bits in the address are significant. Otherwise the least two address bits are ignored as \lxp{} doesn't support unaligned access to 32-bit data words (during simulation, a warning is emitted if such a transaction is attempted).
|
|
|
A special rule applies to pointers that refer to instructions: since instructions are always word-aligned, the least significant bit is interpreted as the \code{IRF} (\emph{Interrupt Return Flag}). See Section \ref{sec:interrupthandling} for details.
|
A special rule applies to pointers that refer to instructions: since instructions are always word-aligned, the least significant bit is interpreted as the \code{IRF} (\emph{Interrupt Return Flag}). See Section \ref{sec:interrupthandling} for details.
|
|
|
\section{Stack}
|
\section{Stack}
|
\label{sec:stack}
|
\label{sec:stack}
|
| Line 439... |
Line 439... |
|
|
The values of \signal{lli\_re\_o} and \signal{lli\_adr\_o} are not guaranteed to be preserved by the master while the slave is busy.
|
The values of \signal{lli\_re\_o} and \signal{lli\_adr\_o} are not guaranteed to be preserved by the master while the slave is busy.
|
|
|
The simplest slaves such as on-chip RAM blocks which are never busy can be trivially connected to the LLI by connecting address, data and read enable ports and tying the \signal{lli\_busy\_i} signal to a logical \code{0} (you can even ignore \signal{lli\_re\_o} in this case, although doing so can theoretically increase power consumption).
|
The simplest slaves such as on-chip RAM blocks which are never busy can be trivially connected to the LLI by connecting address, data and read enable ports and tying the \signal{lli\_busy\_i} signal to a logical \code{0} (you can even ignore \signal{lli\_re\_o} in this case, although doing so can theoretically increase power consumption).
|
|
|
Note that the \signal{lli\_adr\_o} signal has a width of 30 bits since it addresses words, not bytes (instructions are always word-aligned).
|
|
|
|
Since the \signal{lli\_re\_o} output signal is not registered, this interface is not suitable for interaction with off-chip peripherals. Also, care should be taken to avoid introducing too much additional combinatorial delay on its outputs.
|
Since the \signal{lli\_re\_o} output signal is not registered, this interface is not suitable for interaction with off-chip peripherals. Also, care should be taken to avoid introducing too much additional combinatorial delay on its outputs.
|
|
|
|
The instruction bus, whether LLI or WISHBONE, doesn't support access to individual bytes and uses a 30-bit address port to address 32-bit words (instructions are always word-aligned). The lower two bits of the 32-bit address are ignored for the purpose of addressing. Consider the following example:
|
|
|
|
\begin{codeparbreakable}
|
|
\instr{lc} r0, 0x10000000
|
|
\instr{jmp} r0
|
|
\emph{// 0x04000000 will appear on lli_adr_o or ibus_adr_o}
|
|
\end{codeparbreakable}
|
|
|
\section{WISHBONE instruction bus}
|
\section{WISHBONE instruction bus}
|
|
|
The \lxp{}C CPU fetches instructions over the WISHBONE bus. Its parameters are defined in the WISHBONE datasheet (Appendix \ref{app:wishbonedatasheet}). For a detailed description of the bus protocol refer to the WISHBONE specification, revision B3.
|
The \lxp{}C CPU fetches instructions over the WISHBONE bus. Its parameters are defined in the WISHBONE datasheet (Appendix \ref{app:wishbonedatasheet}). For a detailed description of the bus protocol refer to the WISHBONE specification, revision B3.
|
|
|
With classic WISHBONE handshake decent throughput can be only achieved when the slave is able to terminate cycles asynchronously. It is usually possible only for the simplest slaves which should probably be using the Low Latency Interface instead. To maximize throughput for complex, high latency slaves, \lxp{}C instruction bus uses optional WISHBONE address tags [CTI\_O()] (Cycle Type Identifier) and [BTE\_O()] (Burst Type Extension). These signals are hints allowing the slave to predict the address that will be set by the master in the next cycle and prepare data in advance. The slave can ignore these hints, processing requests as classic WISHBONE cycles, although performance would almost certainly suffer in this case.
|
With classic WISHBONE handshake decent throughput can be only achieved when the slave is able to terminate cycles asynchronously. It is usually possible only for the simplest slaves which should probably be using the Low Latency Interface instead. To maximize throughput for complex, high latency slaves, \lxp{}C instruction bus uses optional WISHBONE address tags [CTI\_O()] (Cycle Type Identifier) and [BTE\_O()] (Burst Type Extension). These signals are hints allowing the slave to predict the address that will be set by the master in the next cycle and prepare data in advance. The slave can ignore these hints, processing requests as classic WISHBONE cycles, although performance would almost certainly suffer in this case.
|
| Line 462... |
Line 468... |
|
|
\section{WISHBONE data bus}
|
\section{WISHBONE data bus}
|
|
|
\lxp{} uses the WISHBONE bus to interact with data memory and other peripherals. This bus is distinct from the instruction bus; its parameters are defined in the WISHBONE datasheet (Appendix \ref{app:wishbonedatasheet}).
|
\lxp{} uses the WISHBONE bus to interact with data memory and other peripherals. This bus is distinct from the instruction bus; its parameters are defined in the WISHBONE datasheet (Appendix \ref{app:wishbonedatasheet}).
|
|
|
This bus uses a 30-bit \signal{dbus\_adr\_o} port to address 32-bit words; the \signal{dbus\_sel\_o} port is used to select individual bytes to be written or read. Alternatively, with the \code{DBUS\_RMW} option (Section \ref{sec:generics}) the \signal{dbus\_sel\_o} port is not used; byte-granular write access is performed using the read-modify-write cycle instead.
|
The data bus uses a 30-bit \signal{dbus\_adr\_o} port to address 32-bit words; the \signal{dbus\_sel\_o} port is used to select individual bytes to be written or read. The upper 30 bits of the address appear on the \signal{dbus\_adr\_o} port, while the lower two bits are decoded to create a 4-bit \signal{dbus\_sel\_o} signal. Consider:
|
|
|
|
\begin{codeparbreakable}
|
|
\instr{lc} r0, 0x20000002
|
|
\instr{sb} r0, 0x55
|
|
\emph{// write 0x55 to the address in r0}
|
|
\emph{// 0x08000000 will appear on dbus_adr_o}
|
|
\emph{// 0x4 will appear on dbus_sel_o}
|
|
\end{codeparbreakable}
|
|
|
|
The byte-granular access feature is optional. If it is not needed, the \signal{dbus\_sel\_o} port can be left unconnected. It is also possible to set the \code{DBUS\_RMW} generic to \code{true} to enable byte-granular access emulation using the read-modify-write (RMW) cycle, which works even if the interconnect or slave doesn't provide the [SEL\_I()] port (Section \ref{sec:generics}).
|
|
|
For a detailed description of the bus protocol refer to the WISHBONE specification, revision B3.
|
For a detailed description of the bus protocol refer to the WISHBONE specification, revision B3.
|
|
|
Typical timing diagrams for write and read cycles are shown on Figure \ref{fig:dbustiming}. In these examples the peripheral terminates the cycle asynchronously; however, it can also introduce wait states by delaying the \signal{dbus\_ack\_i} signal.
|
Typical timing diagrams for write and read cycles are shown on Figure \ref{fig:dbustiming}. In these examples the peripheral terminates the cycle asynchronously; however, it can also introduce wait states by delaying the \signal{dbus\_ack\_i} signal.
|
|
|
| Line 632... |
Line 648... |
|
|
To simulate the design, go to the \shellcmd{verify/lxp32/run/<\emph{simulator}>} directory and run \shellcmd{make}. The following make targets are supported:
|
To simulate the design, go to the \shellcmd{verify/lxp32/run/<\emph{simulator}>} directory and run \shellcmd{make}. The following make targets are supported:
|
|
|
\begin{itemize}
|
\begin{itemize}
|
\item \shellcmd{batch} -- simulate the design in batch mode. Results will be written to the standard output. This is the default target.
|
\item \shellcmd{batch} -- simulate the design in batch mode. Results will be written to the standard output. This is the default target.
|
\item \shellcmd{gui} -- simulate the design in GUI mode. Note: since GHDL doesn't have a GUI, the simulation itself will be run in batch mode; upon a successful completion, GTKWave will be run automatically to display dumped waveforms.
|
\item \shellcmd{gui} -- simulate the design in GUI mode. Note: since GHDL doesn't have a GUI, the simulation itself will be run in batch mode; upon a completion, GTKWave will be run automatically to display the dumped waveforms.
|
\item \shellcmd{compile} -- compile only, don't run simulation.
|
\item \shellcmd{compile} -- compile only, don't run simulation.
|
\item \shellcmd{clean} -- delete all the produced artifacts.
|
\item \shellcmd{clean} -- delete all the produced artifacts.
|
\end{itemize}
|
\end{itemize}
|
|
|
\section{Running simulation manually}
|
\section{Running simulation manually}
|
| Line 691... |
Line 707... |
\item Link.
|
\item Link.
|
|
|
Linkable objects are combined into a single executable module. References to symbols defined in external modules are resolved at this stage.
|
Linkable objects are combined into a single executable module. References to symbols defined in external modules are resolved at this stage.
|
\end{enumerate}
|
\end{enumerate}
|
|
|
In the simplest case there is only one input source file which doesn't contain external symbol references. If there are multiple input files, one of them must define the \code{entry} symbol at the beginning of the code.
|
In the simplest case there is only one input source file which doesn't contain external symbol references. If there are multiple input files, one of them must define the \code{entry} (or \code{Entry}) symbol at the beginning of the code.
|
|
|
\subsection{Command line syntax}
|
\subsection{Command line syntax}
|
\label{subsec:assemblercmdline}
|
\label{subsec:assemblercmdline}
|
|
|
\begin{codepar}
|
\begin{codepar}
|
| Line 1644... |
Line 1660... |
\subsection{Directives}
|
\subsection{Directives}
|
|
|
The first token of a directive statement always starts with the \code{\#} character.
|
The first token of a directive statement always starts with the \code{\#} character.
|
|
|
\begin{codepar}
|
\begin{codepar}
|
\instr{\#define} \emph{identifier} \emph{token} [ \emph{token} ... ]
|
\instr{\#define} \emph{identifier} [ \emph{token} ... ]
|
|
\end{codepar}
|
|
|
|
Defines a macro that will be substituted with zero or more tokens. The \code{\emph{identifier}} must satisfy the requirements listed in Section \ref{sec:symbols}. Tokens can be anything, including keywords, identifiers, literals and separators (i.e. comma and colon characters).
|
|
|
|
\begin{codepar}
|
|
\instr{\#error} [ \emph{msg} ]
|
\end{codepar}
|
\end{codepar}
|
|
|
Defines a macro that will be substituted with one or more tokens. The \code{\emph{identifier}} must satisfy the requirements listed in Section \ref{sec:symbols}. Tokens can be anything, including keywords, identifiers, literals and separators (i.e. comma and colon characters).
|
Raises a compiler error. If \emph{msg} is supplied, uses it as an error message.
|
|
|
\begin{codepar}
|
\begin{codepar}
|
\instr{\#export} \emph{identifier}
|
\instr{\#export} \emph{identifier}
|
\end{codepar}
|
\end{codepar}
|
|
|
Declares \code{\emph{identifier}} as an exported symbol. Exported symbols can be referenced by other modules.
|
Declares \code{\emph{identifier}} as an exported symbol. Exported symbols can be referenced by other modules.
|
|
|
\begin{codepar}
|
\begin{codepar}
|
|
\instr{\#ifdef} | \instr{\#ifndef} \emph{identifier}
|
|
\code{...}
|
|
\instr{\#else}
|
|
\code{...}
|
|
\instr{\#endif}
|
|
\end{codepar}
|
|
|
|
Define C preprocessor-style conditional sections which are processed or not based on whether a certain macro has been defined. \instr{\#else} is optional. Can be nested.
|
|
|
|
\begin{codepar}
|
\instr{\#import} \emph{identifier}
|
\instr{\#import} \emph{identifier}
|
\end{codepar}
|
\end{codepar}
|
|
|
Declares \code{\emph{identifier}} as an imported symbol. Used to refer to symbols exported by other modules.
|
Declares \code{\emph{identifier}} as an imported symbol. Used to refer to symbols exported by other modules.
|
|
|
| Line 1794... |
Line 1826... |
\bottomrule
|
\bottomrule
|
\end{ctabular}
|
\end{ctabular}
|
|
|
\chapter{List of changes}
|
\chapter{List of changes}
|
|
|
|
\section*{Version 1.2 (2021-10-21)}
|
|
|
|
This release introduces a few non-breaking changes to the software and testbench. The CPU RTL description hasn't been changed from the previous release.
|
|
|
|
\begin{itemize}
|
|
\item \shellcmd{lxp32asm} now supports C-style conditional processing directives: \instr{\#ifdef}, \instr{\#ifndef}, \instr{\#else} and \instr{\#endif}.
|
|
\item \instr{\#define} directive can now declare a macro with zero subsitute tokens.
|
|
\item A new \instr{\#error} directive.
|
|
\item Minor changes to the testbench.
|
|
\end{itemize}
|
|
|
\section*{Version 1.1 (2019-01-11)}
|
\section*{Version 1.1 (2019-01-11)}
|
|
|
This release introduces a minor but technically breaking hardware change: the START\_ADDR generic, which used to be 30-bit, has been for convenience extended to a full 32-bit word; the two least significant bits are ignored.
|
This release introduces a minor but technically breaking hardware change: the START\_ADDR generic, which used to be 30-bit, has been for convenience extended to a full 32-bit word; the two least significant bits are ignored.
|
|
|
The other breaking change affects the assembly language syntax. Previously all symbols used to be public, and multiple modules could not define symbols with the same name. As of now only symbols explicitly exported using the \instr{\#export} directive are public. \instr{\#extern} directive has been replaced by \instr{\#import}.
|
The other breaking change affects the assembly language syntax. Previously all symbols used to be public, and multiple modules could not define symbols with the same name. As of now only symbols explicitly exported using the \instr{\#export} directive are public. \instr{\#extern} directive has been replaced by \instr{\#import}.
|
