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

Subversion Repositories wbscope

Compare Revisions

  • This comparison shows the changes necessary to convert path 
    /wbscope/trunk/doc
    from Rev 2 to Rev 4
    ↔ Reverse comparison
  •

Rev 2 → Rev 4

/src/spec.tex
68,6 → 68,7
copy.
\end{license}
\begin{revisionhistory}
0.2 & 6/22/2015 & Gisselquist & Finished Draft \\\hline
0.1 & 6/22/2015 & Gisselquist & First Draft \\\hline
\end{revisionhistory}
% Revision History
76,8 → 77,24
% \listoffigures
\listoftables
\begin{preface}
This project began, years ago, for all the wrong reasons. Rather than pay a
high price to purchase a Verilog simulator and then to learn how to use it,
I took working Verilog code, to include a working bus, added features and
used the FPGA system as my testing platform. I arranged the FPGA to step
internal registers upon command, and to make many of those registers
available via the bus.
 
This, then, was and is the genesis of this project.
When I then needed to make the project run in real-time, as opposed to the
manually stepped approach, I generated a scope like this one. I had already
bench tested the components on the hardware itself. Thu, testing and
development continued on the hardware, and the scope helped me see what was
going right or wrong. The great advantage of the approach was that, at the
end of the project, I didn't need to do any hardware in the loop testing.
All of the testing that had been accomplished prior to that date was already
hardware in the loop testing.
 
When I left that job, I took this concept with me and rebuilt this piece of
infrastructure using a Wishbone Bus.
\end{preface}
 
\chapter{Introduction}
86,21 → 103,21
 
The wishbone Scope is a debugging tool for reading results from the chip after
events have taken place. In general, the scope records data until some
trigger has taken place, and then continues for some user programmable hold off.
Once the holdoff has been reached, the scope stops recording and asserts an
interrupt. At this time, data may be read from the scope in order from oldest
to most recent. That's the basics, now for two extra details.
 
First, the trigger and data that the scope records is implementation dependent.
The scope itself is designed to be easily reconfigurable from one build to the
next so that the actual configuration may even be build dependent.
 
some (programmable) holdoff number of data samples after a trigger has taken
place. Once the holdoff has been reached, the scope stops recording and
asserts an interrupt. At this time, data may be read from the scope in order
from oldest to most recent. That's the basics, now for two extra details.
First, the trigger and the data that the scope records are both implementation
dependent. The scope itself is designed to be easily reconfigurable from one
build to the next so that the actual configuration may even be build dependent.
Second, the scope is built to be able to run off of a separate clock from the
bus that commands and controls it. This is configurable, set the parameter
``SYNCHRONOUS'' to `1' to run off of a single clock. When running off of two
clocks, it means that actions associated with commands issued to the scope, such
as manual triggering or being disabled or released, will not act synchronously
with the scope itself.
``SYNCHRONOUS'' to `1' to run off of a single clock. When running off of two
clocks, it means that actions associated with commands issued to the scope,
such as manual triggering or being disabled or released, will not act
synchronously with the scope itself--but this is to be expected.
 
Third, the data clock associated with the scope has a clock enable line
associated with it. Depending on how often the clock enable line is enabled
107,10 → 124,40
may determine how fast the scope is primed, triggered, and eventually completes
its collection.
 
Finally, and in conclusion, this scope has been an invaluable tool for
testing, for figuring out what is going on internal to a chip, and for fixing
such things. I have fixed interactions over a PS/2 connection, Internal
Configuration Access Port (ICAPE2) interfaces, mouse controller interactions,
bus errors, quad-SPI flash interactions, and more using this scope.
% \chapter{Architecture}
\chapter{Operation}
So how shall one use the scope? The scope itself supports a series of
states:
\begin{enumerate}
\item RESET
 
So how shall one use the scope? First, before using the scope, the holdoff
Any write to the control register, without setting the high order bit,
will automatically reset the scope.
\item PRIMED
 
Following a reset, once the scope has filled its memory, it enters the
PRIMED state. Once it reaches this state, it will be sensitive to a
trigger.
\item TRIGGERED
 
The scope may be triggered either automatically, via an input port to
the core, or manually, via a wishbone bus command. Once a trigger
has been received, the core will record a user configurable number of
further samples before stopping.
 
\item STOPPED
 
Once the core has stopped, the data within it may be read back off.
\end{enumerate}
 
Let's go through that list again. First, before using the scope, the holdoff
needs to be set. The scope is designed so that setting the scope control value
to the holdoff alone will reset the scope from whatever condition it was in,
freeing it to run. Once running, then upon every clock enabled clock, one
118,31 → 165,48
is filled, the scope has been {\tt PRIMED}. Once the scope has been
{\tt PRIMED}, it will then be responsive to its trigger. Should the trigger be
active on a clock--enabled input, the scope will then be {\tt TRIGGERED}. It
will then count for the number of clocks in the holdoff before stopping collection, placing it in the {\tt STOPPED} state. If the holdoff is zero, the last
sample in the buffer will be the sample containing the trigger.
 
will then count for the number of clocks in the holdoff before stopping
collection, placing it in the {\tt STOPPED} state. If the holdoff is zero,
the last sample in the buffer will be the sample containing the trigger.
Likewise if the holdoff is one less than the size of the memory, the first
sample in the buffer will be the one containing the trigger.
There are two further commands that will affect the operation of the scope. The
first is the {\tt MANUAL} trigger command/bit. This will cause the scope to
trigger immediately if set. If coupled with a {\tt RESET} command, the trigger
will first wait until it is {\tt PRIMED} before the manual trigger takes
first is the {\tt MANUAL} trigger command/bit. This bit may be set by writing
the holdoff to the control register while setting this bit high. This will
cause the scope to trigger immediately. If coupled with a {\tt RESET} command,
that is if the RESET_n bit isn't also set, then the trigger will first wait
until the scope enters its {\tt PRIMED} state before the manual trigger takes
effect.
 
The last command that can affect the operation of the scope is the {\tt DISABLE}
command/bit. This command will prevent the scope from triggering, or if
triggered, prevent the scope from generating an interrupt.
command/bit in the control register. Setting this bit will prevent the scope
from triggering, or if triggered, it will prevent the scope from generating an
interrupt.
 
Finally, be careful how you set the clock enable line. If the clock enable
line leaves the clock too often disabled, the scope might never prime in any
reasonable amount of time.
 
So, in summary, to use this scope you first set the holdoff value in the
control register. Second, you wait until the scope has been triggered and
stopped. Finally, you read from the data register once for every memory value
in the buffer and you can then sit back, relax, and study what took place
within the FPGA.
\chapter{Registers}
 
This scope core supports two registers, as listed in
Tbl.~\ref{tbl:reglist}. The first is the control register, whereas the second
is the data register.
Tbl.~\ref{tbl:reglist}: a control register and a data register.
\begin{table}[htbp]
\begin{center}
\begin{reglist}
WBSCOPE & 0 & 32 & R/W & Configuration, control, and status of the
scope.\\\hline
WBSCOPEDATA & 1 & 32 & R & Read out register, to read out the data
from the core.\\\hline
WBSCOPE & 0 & 32 & R/W & Configuration, control, and status of the
scope.\\\hline
WBSCOPEDATA & 1 & 32 & R/W & Read out register, to read out the data
from the core. Writes to this register reset the read address
to the beginning of the buffer, but are otherwise ignored.
\\\hline
\end{reglist}\caption{List of Registers}\label{tbl:reglist}
\end{center}\end{table}
Each register will be discussed in detail in this chapter.
171,7 → 235,36
\end{bitlist}
\caption{Control Register}\label{tbl:control}
\end{center}\end{table}
The register has been designed so that one need only write the holdoff value to
it, while leaving the other bits zero, to get the scope going. On such a write,
the RESET\_n bit will be a zero, causing the scope to internally reset itself.
Further, during normal operation, the high order nibble will go from 4'h8
(a nearly instantaneous reset state) to 4'h0 (running), to 4'h1 (primed),
to 4'h3 (triggered), and then stop at 4'h7 (primed, triggered, and stopped).
Finally, user's are cautioned not to adjust the holdoff between the time the
scope triggers and the time it stops--just to guarantee data coherency.
 
While this approach works, the scope has some other capabilities. For example,
if you set the MANUAL bit, the scope will trigger as soon as it is primed.
If you set the MANUAL bit and the RESET\_n bit, it will trigger immediately
if the scope was already primed. If not, a reset will take place, the scope
will collect enough data to be primed, and then immediately trigger.
 
A second optional capability is to disable the scope entirely. This might be
useful if, for example, certain irrelevant things might trigger the scope.
By setting the DISABLE bit, the scope will not automatically trigger. It will
still record into its memory, and it will still prime itself, it will just
not trigger automatically. The scope may still be manually triggered while
the DISABLE bit is set. Likewise, if the DISABLE bit is set after the scope
has been triggered, the scope will continue to its natural stopped state--it
just won't generate an interrupt.
 
There are two other interesting bits in this control register. The RZERO bit
indicates that the next read from the data register will read from the first
value in the memory, while the LGMEMLEN bits indicate how long the memory is.
Thus, if LGMEMLEN is 10, the FIFO will be (1<<10) or 1024 words long, whereas
if LGMEMLEN is 14, the FIFO will be (1<<14) or 16384 words long.
 
\section{Data Register}
 
This is perhaps the simplest register to explain. Before the core stops
183,15 → 276,20
increments an internal memory address, so that after $N$ reads (for however
long the internal memory is), the entire memory has been returned over the bus.
If you would like some assurance that you are reading from the beginning of the
memory, check the control register's {\tt RZERO} flag.
 
memory, you may either check the control register's {\tt RZERO} flag which will
be `1' for the first value in the buffer, or you may write to the data register.
Such writes will be ignored, save that they will reset the read address back
to the beginning of the buffer.
\chapter{Clocks}
 
This scope supports two clocks: a wishbone bus clock, and a data clock.
If the internal parameter ``SYNCHRONOUS'' is set to zero, proper transfers
will take place between these two clocks. Setting this parameter to a one
will save some flip flops and logic in implementation.
 
will save some flip flops and logic in implementation. The speeds of the
respective clocks are based upon the speed of your device, and not specific
to this core.
\chapter{Wishbone Datasheet}\label{chap:wishbone}
Tbl.~\ref{tbl:wishbone}
\begin{table}[htbp]
222,8 → 320,10
is required by the wishbone specification, and so
it is included here. The big thing to notice is that this core
acts as a wishbone slave, and that all accesses to the wishbone scope
registers become 32--bit reads and writes to this interface.
 
registers become 32--bit reads and writes to this interface. You may also wish
to note that the scope supports pipeline reads from the data port, to speed
up reading the results out.
\chapter{IO Ports}
 
The ports are listed in Table.~\ref{tbl:ioports}.
232,19 → 332,25
\begin{portlist}
i\_clk & 1 & Input & \\\hline
i\_ce & 1 & Input & Clock Enable. Set this high to clock data in and
out.\\\hline
i\_trigger & 1 & Input &
\\\hline
i\_data & 32 & Input &
\\\hline
out.\\\hline
i\_trigger & 1 & Input & An active high trigger line. If this trigger is
set to one on any clock enabled data clock cycle, once
the scope has been primed, it will then enter into its
TRIGGERED state.
\\\hline
i\_data & 32 & Input & 32--wires of ... whatever you are interested in
recording and later examining. These can be anything, only
they should be synchronous with the data clock.
\\\hline
i\_wb\_clk & 1 & Input & The clock that the wishbone interface runs on.
\\\hline
i\_wb\_cyc & 1 & Input & Indicates a wishbone bus cycle is active when high.
\\\hline
i\_wb\_stb & 1 & Input & Indicates a wishbone bus cycle for this peripheral
when high. \\\hline
i\_wb\_we & 1 & Input & Write enable, allows configuring the part.
\\\hline
when high. (See the wishbone spec for more details) \\\hline
i\_wb\_we & 1 & Input & Write enable, allows indicates a write to one of the
two registers when i\_wb\_stb is also high.
\\\hline
i\_wb\_addr & 1 & Input & A single address line, set to zero to access the
configuration and control regiseter, to one to access the data
register. \\\hline
259,11 → 365,24
zero in this implementation.
\\\hline
o\_wb\_data & 32 & Output & Values read, either control or data, headed back
to the wishbone bus.
\\\hline
to the wishbone bus. These values will be valid during any
read cycle when the {\tt i\_wb\_ack} line is high.
\\\hline
\end{portlist}
\caption{List of IO ports}\label{tbl:ioports}
\end{center}\end{table}
At this point, most of these ports should have been well defined and described
earlier in this document. The only new things are the data clock, {\tt i\_clk},
the clock enable for the data, {\tt i\_ce}, the trigger, {\tt i\_trigger}, and
the data of interest itself, {\tt i\_data}. Hopefully these are fairly self
explanatory by this point. If not, just remember the data, {\tt i\_data},
are synchronous to the clock, {\tt i\_clk}. On every clock where the clock
enable line is high, {\tt i\_ce}, the data will be recorded until the scope
has stopped. Further, the scope will stop some programmable holdoff number
of clock enabled data clocks after {\tt i\_trigger} goes high. Further,
{\tt i\_trigger} need only be high for one clock cycle to be noticed by the
scope.
 
% Appendices
% Index
\end{document}

powered by: WebSVN 2.1.0

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