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

Subversion Repositories sd_card_controller

Compare Revisions

  • This comparison shows the changes necessary to convert path 
    /sd_card_controller/trunk/doc/src
    from Rev 11 to Rev 13
    ↔ Reverse comparison
  •

Rev 11 → Rev 13

/introduction.tex
48,9 → 48,9
\subsection{Purpose of the IP core}
\label{sec:purpose}
 
The \textit{Wishbone SD Card Controller IP Core} is MMC/SD communication controller designed to be used in System-on-Chip (img. \ref{img:ip_core}).
IP core provides simple interface for any MCU with Wishbone bus. The communication between the MMC/SD card controller and MMC/SD card
is performed according to the MMC/SD protocol.
The \textit{Wishbone SD Card Controller IP Core} is an MMC/SD communication controller designed to be used in a System-on-Chip (Fig. \ref{img:ip_core}).
The IP core provides a simple interface for any MCU which utilizes the Wishbone bus. Communications between the MMC/SD card controller and MMC/SD card
are performed according to the MMC/SD protocol.
\begin{figure}[H]
\centering
/usage.tex
74,15 → 74,15
}
\begin{description}
\item[\texttt{bench/verilog}] - verilog testbench sources,
\item[\texttt{bench/verilog}] - Verilog testbench sources,
\item[\texttt{doc}] - documentation files,
\item[\texttt{doc/src}] - documentation \LaTeX sources,
\item[\texttt{rtl/verilog}] - ip core verilog sources,
\item[\texttt{rtl/verilog}] - IP core Verilog sources,
\item[\texttt{sim/rtl\_sim/bin}] - simulation makefile and modelsim scripts,
\item[\texttt{sim/rtl\_sim/log}] - log files created during simulation,
\item[\texttt{sim/rtl\_sim/run}] - simulation execution directory,
\item[\texttt{sw/example}] - baremetal example application for or1k,
\item[\texttt{syn/quartus/bin}] - synthesis makefile and scripts for quartus example project,
\item[\texttt{syn/quartus/bin}] - synthesis makefile and scripts for Quartus example project,
\item[\texttt{syn/quartus/run}] - synthesis execution directory,
\item[\texttt{syn/quartus/src}] - example project sources.
\end{description}
90,13 → 90,13
\subsection{Simulation}
\label{sec:simulation}
To start simulation just enter to \path{sim/rtl_sim/run} directory and type \texttt{make}:
To start the simulation just change to the \path{sim/rtl_sim/run} directory and type \texttt{make}:
\begin{verbatim}
#> cd sim/rtl_sim/run
#> make
\end{verbatim}
Every testbench is written in SystemVerilog (mostly due to use of \texttt{assert} keyword). Every testbench is self checking. Test error are represented by
Every testbench is written in SystemVerilog (mostly due to use of \texttt{assert} keyword). Every testbench is self checking. Test errors are represented by
assert failures. Every testbench starts by displaying:
\begin{verbatim}
# testbench_name start ...
105,7 → 105,7
\begin{verbatim}
# testbench_name finish ...
\end{verbatim}
If no asserts are displayed between these lines, the test passes. Below is an example of passing test:
If no asserts are displayed between these lines, the test passed. Below is an example of passing test:
\begin{verbatim}
...
some compilation output
132,19 → 132,19
\subsubsection{Simulation makefile targets}
\label{sec:sim_make_targ}
 
The default simulation target is to run all testbenches from \path{bench/verilog} directory that ends with \path{_.sv}. Other simulation targets are:
The default simulation target is to run all testbenches from \path{bench/verilog} directory that end with \path{_.sv}. Other simulation targets are:
\begin{description}
\item[\texttt{clean}] - remove all simulation output files,
\item[\texttt{print\_testbenches}] - lists all availible testbenches,
\item[\texttt{print\_testbenches}] - lists all available testbenches,
\item[\texttt{modelsim}] - compiles all sources and launches modelsim (see \ref{sec:sim_make_var}),
\item[\texttt{*\_tb}] - compiles and executes given testbench. All items listed by the \path{print_testbenches} target can be executed this way,
\item[\texttt{*\_tb\_gui}] - same as \path{*_tb} target, only instead of executing simulation in command-line, launches modelsim.
\item[\texttt{*\_tb}] - compiles and executes the given testbench. All items listed by the \path{print_testbenches} target can be executed this way,
\item[\texttt{*\_tb\_gui}] - same as \path{*_tb} target, only instead of executing the simulation via command-line, launches modelsim.
\end{description}
\subsubsection{Simulation makefile environment variables}
\label{sec:sim_make_var}
Simulation makefile uses couple of environment variables to setup simulation:
The simulation makefile uses a couple of environment variables to setup the simulation:
\begin{description}
\item[\texttt{MODELSIM\_DIR}] - modelsim installation directory (\path{\$(MODELSIM_DIR)/bin/vsim} should be a valid path),
\item[\texttt{VCD}] - when set to 1 - all waveforms are dumped to \path{sim/rtl_sim/out/*.vcd} files; when set to 0 - no waveforms are dumped (0 is default),
161,27 → 161,27
#> cd syn/quartus/run
#> make
\end{verbatim}
Example project consist of all verilog sources from \path{rtl/verilog} directory and \path{syn/quartus/src/sdc_controller_top.v} source file.
The purpose of the additional verilog file is to instantiate the \textit{Wishbone SD Card Controller IP Core} and register all inputs/outputs to/from the core.
The example project consists of all Verilog sources from the \path{rtl/verilog} directory and \path{syn/quartus/src/sdc_controller_top.v} source file.
The purpose of the additional Verilog file is to instantiate the \textit{Wishbone SD Card Controller IP Core} and register all inputs/outputs to/from the core.
This makes timing verification more accurate.
\subsubsection{Synthesis makefile targets}
\label{sec:syn_make_targ}
The default synthesis target is to synthesize the project and create .sof file in \path{syn/quartus/run} directory. Other synthesis targets are:
The default synthesis target is to synthesize the project and create a .sof file in the \path{syn/quartus/run} directory. Other synthesis targets are:
\begin{description}
\item[\texttt{clean}] - remove all synthesis output files,
\item[\texttt{print\_config}] - prints projects configuration of FPGA device,
\item[\texttt{project}] - creates quartus project files (.qpf and .qsf),
\item[\texttt{quartus}] - creates quartus project files and launches quartus IDE.
\item[\texttt{print\_config}] - prints project configuration of FPGA device,
\item[\texttt{project}] - creates Quartus project files (.qpf and .qsf),
\item[\texttt{quartus}] - creates Quartus project files and launches the Quartus IDE.
\end{description}
\subsubsection{Synthesis makefile environment variables}
\label{sec:syn_make_var}
Synthesis makefile uses couple of environment variables to setup synthesis:
The synthesis makefile uses a couple of environment variables to setup synthesis:
\begin{description}
\item[\texttt{QUARTUS\_DIR}] - quartus installation directory (\path{\$(QUARTUS_DIR)/bin/quartus} should be a valid path),
\item[\texttt{QUARTUS\_DIR}] - Quartus installation directory (\path{\$(QUARTUS_DIR)/bin/quartus} should be a valid path),
\item[\texttt{FPGA\_FAMILY}] - name of the FPGA device family,
\item[\texttt{FPGA\_PART}] - name of the FPGA device,
\item[\texttt{V}] - when set to 1 - enables verbose output; when set to 0 - normal simulation output (0 is default).
/hdl_if.tex
43,7 → 43,7
\section{HDL interface}
\label{sec:hdl_if}
 
IP core has very simple interface:
This IP core has a very simple interface:
\begin{figure}[H]
\centering
\includegraphics[width=11cm]{../bin/ip_core_if.png}
51,16 → 51,16
\caption{Wishbone SD Card Controller IP Core interface}
\label{img:ip_core_if}
\end{figure}
Wishbone slave interface provides access from CPU to all IP core registers (see \ref{sec:regs}). It must
be connected to CPU data master. Wishbone master interface provides access for DMA engine to RAM (see \ref{sec:dma}).
It must be connected to RAM memory slave. Interrupts signals provides mechanism to notify the CPU about finished transactions (data and command tranfers).
They are not necesary for proper operation (if You don't want to use interrupts). MMC/SD card interface provides communication with external MMC/SD cards.
It must be connected to external pins of the FPGA wich are connected to MMC/SD card connector. Because those external pins are bidirectional, IP core
The Wishbone slave interface provides access from CPU to all IP core registers (see \ref{sec:regs}). It must
be connected to a data master. The Wishbone master interface provides access from the DMA engine to RAM (see \ref{sec:dma}).
It must be connected to a RAM memory slave. Interrupt signals provide a mechanism to notify the CPU about finished transactions (data and command tranfers).
They are not necessary for proper operation, if you don't want to use interrupts. The MMC/SD card interface communicates with external MMC/SD cards.
It must be mapped to external pins of the FPGA which are connected to a MMC/SD card connector. Because those external pins are bidirectional, this IP core
provides inputs, outputs and output enables for these signals.
Table \ref{tab:singals} presents all IP core signals with descriptions.
Table \ref{tab:signals} presents all the IP core signals with descriptions.
\begin{table}
\caption{Signals description}
\caption{Description of signals}
\begin{center}
\begin{tabular}{l|l|l|l}
\rowcolor[gray]{0.7} name & direction & width & description \\ \hline \hline
101,7 → 101,7
\texttt{int\_data} & output & 1 & data transaction finished interrupt \\ \hline
\hline
\end{tabular}
\label{tab:singals}
\label{tab:signals}
\end{center}
\end{table}
108,31 → 108,31
\subsection{Clock consideration}
\label{sec:clock}
IP core needs two clock sources. First one is for Wishbone bus operation (\texttt{wb\_clk\_i}). There are no constraints for this clock.
Second one is for MMC/SD interface operation (\texttt{sd\_clk\_i\_pad}).
\texttt{sd\_clk\_i\_pad} is used to drive \texttt{sd\_clk\_o\_pad} output, which is the external MMC/SD card clock source, through internal
clock devider. This clock devider is able to devide \texttt{sd\_clk\_i\_pad} clock by 2, 4, 6, 8, ... etc. (2*n where n = [1..256]).
\texttt{sd\_clk\_o\_pad} clock frequency depends on MMC/SD specification. To fully utilize the transmission bandwidth \texttt{sd\_clk\_o\_pad}
should be able to perform at 25MHz frequency which imposes constraint of minimum 50MHz on \texttt{sd\_clk\_i\_pad} clock.
The IP core needs two clock sources. The first is for Wishbone bus operation (\texttt{wb\_clk\_i}). There are no constraints for this clock.
The second is for MMC/SD interface operation (\texttt{sd\_clk\_i\_pad}).
\texttt{sd\_clk\_i\_pad} is used to drive the \texttt{sd\_clk\_o\_pad} output, which is the external MMC/SD card clock source, through an internal
clock divider. This clock divider is able to divide the \texttt{sd\_clk\_i\_pad} clock by 2, 4, 6, 8, ... etc. (2*n where n = [1..256]).
The \texttt{sd\_clk\_o\_pad} clock frequency depends on the MMC/SD specification. To fully utilize the transmission bandwidth \texttt{sd\_clk\_o\_pad}
should be able to perform at 25MHz frequency which imposes a minimum constraint of 50MHz on \texttt{sd\_clk\_i\_pad} clock.
Clock inputs \texttt{wb\_clk\_i} and \texttt{sd\_clk\_i\_pad} can be sourced by the same signal.
\subsection{DMA engine}
\label{sec:dma}
DMA engine is used to lower the CPU usage during data transactions\footnote{Data transaction refers to any traffic on the data lines of MMC/SD card interface.}.
DMA starts its operation imidiately after succesful end of any read or write command transactions\footnote{Command transaction refers to any traffic on the command line.}
\footnote{Read or write command refer to command with data payload such as \textit{block read}(CMD17) or \textit{block write}(CMD24).}.
During write transactions, data is fetched from RAM automatically, starting from known address. This addres has to be configured by the CPU before sending any write command.
Similarly, during read transactions, data is written to RAM automatically, starting from known address.
This address also has to be configured by the CPU before sending any read command. Because data transmission is half-duplex,
read and write addresses are placed in the same configuration register. Function of this register depends on the command to be sent.
The DMA engine is used to lower the CPU usage during data transactions\footnote{"Data transaction" refers to any traffic on the data lines of MMC/SD card interface.}.
The DMA engine starts its operation immediately after the successful end of any read or write command transactions\footnote{"Command transaction" refers to any traffic on the command line.}
\footnote{"Read" or "write" commands refer to commands with data payload such as \textit{block read}(CMD17) or \textit{block write}(CMD24).}.
During write transactions, data is fetched from RAM automatically, starting from a known address. This address has to be configured by the CPU before sending any write commands.
Similarly, during read transactions, data is written to RAM automatically, starting from a known address.
This address also has to be configured by the CPU before sending any read commands. Because data transmission is half-duplex,
read and write addresses are placed in the same configuration register. The function of this register thus depends on the command to be sent.
\subsection{Interrupt generation}
\label{sec:interrupt}
Interrupts are useful when polling technique is not an option. There are two interrupt sources. One to notify the end of the commans transaction (\texttt{int\_cmd} signal) and
one to notify the end of the data transaction (\texttt{int\_data} signal). Both interrupts has active high logic. All events that triger each interrupts can be masked(see \ref{sec:regs})
and therefore, do not participate in interrupt generation(see \ref{img:events}).
Interrupts are useful when polling is not an option. There are two interrupt sources: One to signify the end of the command transaction (\texttt{int\_cmd} signal) and
one to signify the end of the data transaction (\texttt{int\_data} signal). Both interrupts use active high logic. All events that trigger an interrupt can be masked. (see \ref{sec:regs})
Events which are masked do not participate in interrupt generation(see Fig. \ref{img:events}).
\begin{figure}[H]
\centering
\includegraphics[width=11cm]{../bin/events.png}
144,12 → 144,12
\subsubsection{Command transaction events}
\label{sec:cmd_events}
 
Command transaction end interrupt is driven by the command transaction events. The events are:
The command transaction end interrupt is driven in response to command transaction events. The events are:
\begin{description}
\item[completion] - transaction completed succesfuly,
\item[error] - transaction completed with error (one or more of the following events occured),
\item[completion] - transaction completed successfully,
\item[error] - transaction completed with error (one or more of the following events occurred),
\item[timeout] - timeout error (the card did not respond in a timely fashion),
\item[wrong crc] - crc check error (crc calculated from received response data did not match to the crc field of the response),
\item[wrong CRC] - CRC check error (CRC calculated from received response data did not match to the CRC field of the response),
\item[wrong index] - index check error (response consists of wrong index field value).
\end{description}
156,13 → 156,13
\subsubsection{Data transaction events}
\label{sec:data_events}
 
Data transaction end interrupt is driven by the data transaction events. The events are:
The data transaction end interrupt is driven in response to data transaction events. The events are:
\begin{description}
\item[completion] - transaction completed succesfuly,
\item[wrong crc] - crc check error (in case of write transaction, crc received in response to write transaction was different than one calculated by the core;
in case of read transaction, crc calculated from received data did not match to the crc field of received data),
\item[fifo error] - internal fifo error (in case of write transaction, tx fifo became empty before all data was send; in case of read transaction, rx fifo became
full; both cases are caused by to slow wishbone bus or wishbone bus been busy for to long)).
\item[completion] - transaction completed successfully,
\item[wrong CRC] - CRC check error (in case of write transaction, CRC received in response to write transaction was different than the one calculated by the core;
in case of read transaction, the CRC calculated from received data did not match to the CRC field of the received data),
\item[FIFO error] - internal FIFO error (in case of write transaction, tx FIFO became empty before all data was sent; in case of read transaction, rx FIFO became
full; both cases are caused by too slow of a wishbone bus or the wishbone bus being busy for too long)).
\end{description}
 
/sw_if.tex
43,7 → 43,7
\section{Software interface}
\label{sec:sw_if}
 
Access to IP core registers is provided through Wishbone slave interface.
Access to IP core registers is provided through a Wishbone slave interface.
\subsection{IP Core registers}
\label{sec:regs}
60,7 → 60,7
\texttt{response3} & \texttt{0x14} & R & bits 119-96 of the response \\ \hline
\texttt{control} & \texttt{0x1C} & RW & IP core control settings \\ \hline
\texttt{timeout} & \texttt{0x20} & RW & timeout configuration \\ \hline
\texttt{clock\_devider} & \texttt{0x24} & RW & MMC/SD interface clock devider \\ \hline
\texttt{clock\_divider} & \texttt{0x24} & RW & MMC/SD interface clock divider \\ \hline
\texttt{reset} & \texttt{0x28} & RW & software reset \\ \hline
\texttt{voltage} & \texttt{0x2C} & R & power control information \\ \hline
\texttt{capabilities} & \texttt{0x30} & R & capabilities information \\ \hline
79,7 → 79,7
\subsubsection{Argument register}
\label{sec:arg_reg}
Write operation to this register triggers command transaction (command register has to be configured before writing to this register).
A write operation to this register triggers a command transaction (The command register has to be configured before writing to this register).
\begin{table}[H]
\caption{Argument register}
94,7 → 94,7
\subsubsection{Command register}
\label{sec:cmd_reg}
This register configures all aspects of command to be sent.
This register configures all aspects of the command to be sent.
\begin{table}[H]
\caption{Command register}
106,9 → 106,9
\texttt{[6:5]} & \texttt{0x0} & RW & data transfer specification. 0x0 - no data transfer; 0x1 - triggers read data transaction after command transaction;
0x2 - triggers write data transaction after command transaction\\ \hline
\texttt{[4]} & \texttt{0x0} & RW & check response for correct command index \\ \hline
\texttt{[3]} & \texttt{0x0} & RW & check response crc \\ \hline
\texttt{[3]} & \texttt{0x0} & RW & check response CRC \\ \hline
\texttt{[2]} & \texttt{0x0} & RW & check for busy signal after command transaction (if busy signal will be asserted after command transaction,
core will wait for as long as busy signal remains) \\ \hline
the core will wait for as long as the busy signal remains) \\ \hline
\texttt{[1:0]} & \texttt{0x0} & RW & response check configuration. 0x0 - don't wait for response; 0x1 - wait for short response (48-bits);
0x2 - wait for long response (136-bits) \\ \hline
\hline
119,7 → 119,7
\subsubsection{Response register 0-3}
\label{sec:resp_reg}
Response registers 0-3 contains response data bits after end of succesful command transaction (if bits 1-0 of command register were configured to wait for response).
Response registers 0-3 contain response data bits after a successful command transaction (if bits 1-0 of command register were configured to wait for response).
\begin{table}[H]
\caption{Response register 0-3}
149,10 → 149,10
\subsubsection{Timeout register}
\label{sec:timeout_reg}
Timeout register configures transaction watchdog counter. If any transaction will last longer than configured timeout, interrupt will be generated.
Value in timeout register represents the number of \texttt{sd\_clk\_o\_pad} clock cyckles. Register value is calculated by following formula:
The timeout register configures the transaction watchdog counter. If any transaction lasts longer than the configured timeout, an interrupt will be generated.
The value in the timeout register represents the number of \texttt{sd\_clk\_o\_pad} clock cycles. The register value is calculated by the following formula:
\begin{equation}
REG = \frac{timeout[s] * frequency_{\texttt{sd\_clk\_i\_pad}}[Hz]}{(2*(\texttt{clock\_devider} + 1))}
REG = \frac{timeout[s] * frequency_{\texttt{sd\_clk\_i\_pad}}[Hz]}{(2*(\texttt{clock\_divider} + 1))}
\end{equation}
\begin{table}[H]
166,21 → 166,21
\label{tab:timeout_reg}
\end{table}
\subsubsection{Clock devider register}
\subsubsection{Clock divider register}
\label{sec:div_reg}
Clock devider register control division of \texttt{sd\_clk\_i\_pad} signal frequency. Output of this devider is routed to MMC/SD interface clock domain.
Register value is calculated by following formula:
The clock divider register controls division of the \texttt{sd\_clk\_i\_pad} signal frequency. The output of this divider is routed to the MMC/SD interface clock domain.
The register value is calculated by following formula:
\begin{equation}
REG = \frac{frequency_{\texttt{sd\_clk\_i\_pad}}[Hz]}{2*frequency_{\texttt{sd\_clk\_i\_pad}}[Hz]} - 1
\end{equation}
\begin{table}[H]
\caption{Clock devider register}
\caption{Clock divider register}
\begin{tabular}{m{1.3cm}|m{2cm}|m{1cm}|m{8cm}}
\rowcolor[gray]{0.7} bit \# & reset value & access & description \\ \hline \hline
\texttt{[31:8]} & & & reserved \\ \hline
\texttt{[7:0]} & \texttt{0x0} & RW & devider ratio \\ \hline
\texttt{[7:0]} & \texttt{0x0} & RW & divider ratio \\ \hline
\hline
\end{tabular}
\label{tab:div_reg}
203,7 → 203,7
\subsubsection{Voltage information register}
\label{sec:voltage_reg}
This register contains the value of power supply voltage expressed in mV. It is read-only register and its
This register contains the value of the card power supply voltage expressed in mV. It is a read-only register and its
value is configured in HDL.
\begin{table}[H]
232,7 → 232,7
\subsubsection{Command events status register}
\label{sec:cmd_evt_reg}
This register holds all pending event flags related to command transactions. Write operation to this register
This register holds all pending event flags related to command transactions. Any write operation to this register
clears all flags.
\begin{table}[H]
241,7 → 241,7
\rowcolor[gray]{0.7} bit \# & reset value & access & description \\ \hline \hline
\texttt{[31:5]} & & & reserved \\ \hline
\texttt{[4]} & \texttt{0x0} & RW & index error event \\ \hline
\texttt{[3]} & \texttt{0x0} & RW & crc error event \\ \hline
\texttt{[3]} & \texttt{0x0} & RW & CRC error event \\ \hline
\texttt{[2]} & \texttt{0x0} & RW & timeout error event \\ \hline
\texttt{[1]} & \texttt{0x0} & RW & error event (logic sum of all error events) \\ \hline
\texttt{[0]} & \texttt{0x0} & RW & command transaction succesful completion event \\ \hline
253,7 → 253,7
\subsubsection{Command transaction events enable register}
\label{sec:cmd_ena_reg}
This register acts as event \textit{and} mask. To enable given event, corresponding bit must be set to 1.
This register acts as an event \textit{and} mask. To enable a given event, the corresponding bit must be set to 1.
\begin{table}[H]
\caption{Command transaction events enable register}
261,10 → 261,10
\rowcolor[gray]{0.7} bit \# & reset value & access & description \\ \hline \hline
\texttt{[31:5]} & & & reserved \\ \hline
\texttt{[4]} & \texttt{0x0} & RW & enable index error event \\ \hline
\texttt{[3]} & \texttt{0x0} & RW & enable crc error event \\ \hline
\texttt{[3]} & \texttt{0x0} & RW & enable CRC error event \\ \hline
\texttt{[2]} & \texttt{0x0} & RW & enable timeout error event \\ \hline
\texttt{[1]} & \texttt{0x0} & RW & enable error event (logic sum of all error events) \\ \hline
\texttt{[0]} & \texttt{0x0} & RW & enable command transaction succesful completion event \\ \hline
\texttt{[0]} & \texttt{0x0} & RW & enable command transaction successful completion event \\ \hline
\hline
\end{tabular}
\label{tab:cmd_ena_reg}
273,7 → 273,7
\subsubsection{Data transaction events status register}
\label{sec:data_evt_reg}
This register holds all pending event flags related to data transactions. Write operation to this register
This register holds all pending event flags related to data transactions. Any write operation to this register
clears all flags.
\begin{table}[H]
282,8 → 282,8
\rowcolor[gray]{0.7} bit \# & reset value & access & description \\ \hline \hline
\texttt{[31:3]} & & & reserved \\ \hline
\texttt{[2]} & \texttt{0x0} & RW & fifo error event \\ \hline
\texttt{[1]} & \texttt{0x0} & RW & crc error event \\ \hline
\texttt{[0]} & \texttt{0x0} & RW & data transaction succesful completion event \\ \hline
\texttt{[1]} & \texttt{0x0} & RW & CRC error event \\ \hline
\texttt{[0]} & \texttt{0x0} & RW & data transaction successful completion event \\ \hline
\hline
\end{tabular}
\label{tab:data_evt_reg}
292,7 → 292,7
\subsubsection{Data transaction events enable register}
\label{sec:data_ena_reg}
This register acts as event \textit{and} mask. To enable given event, corresponding bit must be set to 1.
This register acts as an event \textit{and} mask. To enable a given event, the corresponding bit must be set to 1.
\begin{table}[H]
\caption{Data transaction events enable register}
300,8 → 300,8
\rowcolor[gray]{0.7} bit \# & reset value & access & description \\ \hline \hline
\texttt{[31:3]} & & & reserved \\ \hline
\texttt{[2]} & \texttt{0x0} & RW & enable fifo error event \\ \hline
\texttt{[1]} & \texttt{0x0} & RW & enable crc error event \\ \hline
\texttt{[0]} & \texttt{0x0} & RW & enable data transaction succesful completion event \\ \hline
\texttt{[1]} & \texttt{0x0} & RW & enable CRC error event \\ \hline
\texttt{[0]} & \texttt{0x0} & RW & enable data transaction successful completion event \\ \hline
\hline
\end{tabular}
\label{tab:data_ena_reg}
310,7 → 310,7
\subsubsection{Block size register}
\label{sec:blocksize_reg}
This register controls the number of bytes to write/read in a single block. Data transaction will transmit number of bytes equal to size of block times blocks count.
This register controls the number of bytes to write/read in a single block. A data transaction will transmit a number of bytes equal to the block size times the block count.
\begin{table}[H]
\caption{Block size register}
317,7 → 317,7
\begin{tabular}{m{1.3cm}|m{2cm}|m{1cm}|m{8cm}}
\rowcolor[gray]{0.7} bit \# & reset value & access & description \\ \hline \hline
\texttt{[31:12]} & & & reserved \\ \hline
\texttt{[11:0]} & \texttt{0x200} & RW & number of byes in a single block \\ \hline
\texttt{[11:0]} & \texttt{0x200} & RW & number of bytes in a single block \\ \hline
\hline
\end{tabular}
\label{tab:blocksize_reg}
326,8 → 326,8
\subsubsection{Block count register}
\label{sec:blockcnt_reg}
This register controls the number of blocks to write/read in data transaction. Data transaction will transmit number of bytes equal to value blocks count times block size.
Register value is calculated by following formula:
This register controls the number of blocks to write/read in a data transaction. A data transaction will transmit a number of bytes equal to the block count times block size.
The register value is calculated by following formula:
\begin{equation}
REG = number\_of\_blocks - 1
\end{equation}
346,8 → 346,8
\subsubsection{DMA destination / source register}
\label{sec:dst_src_reg}
This registers configures the DMA source / destination address. For write transactions, this address points to the begining of data block to be sent.
For read transactions, this address points to the begining of data block to be written.
This registers configures the DMA source / destination address. For write transactions, this address points to the begining of the data block to be sent.
For read transactions, this address points to the begining of data block to be received and written to RAM.
\begin{table}[H]
\caption{DMA destination / source register}

powered by: WebSVN 2.1.0

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