Subversion Repositories light8080

\documentclass[11pt]{article}
\usepackage{graphicx}    % needed for including graphics e.g. EPS, PS
\usepackage{multirow}
\usepackage{alltt}
\topmargin -1.5cm        % read Lamport p.163
\oddsidemargin -0.04cm   % read Lamport p.163
\evensidemargin -0.04cm  % same as oddsidemargin but for left-hand pages
\textwidth 16.59cm
\textheight 21.94cm 
%\pagestyle{empty}       % Uncomment if don't want page numbers
\parskip 7.2pt           % sets spacing between paragraphs
%\renewcommand{\baselinestretch}{1.5} % Uncomment for 1.5 spacing between lines
\parindent 15pt		 % sets leading space for paragraphs
 
\begin{document}         
 
\section{Basic behavior}
\label{basics}
 
The microcoded machine ($\mu$M) is built around a register bank and an 8-bit
ALU with registered operands T1 and T2. It performs all its operations in two
cycles, so I have divided it in two stages: an operand stage and an ALU stage.
This is nothing more than a 2-stage pipeline. \\
 
In the operand stage, registers T1 and T2 are loaded with either the
contents of the register bank (RB) or the input signal DI.\\
In the ALU stage, the ALU output is written back into the RB or loaded
into the output register DO. Besides, flags are updated, or not, according to 
the microinstruction ($\mu$I) in execution.\\
 
Every microinstruction controls the operation of the operand stage
and the succeeding ALU stage; that is, the execution of a $\mu$I extends over 2
succeeding clock cycles, and microinstructions overlap each other. This means
that the part of the $\mu$I that controls the 2nd stage has to be pipelined; in 
the VHDL code, I have divided the $\mu$I in a field\_1 and a field\_2, the 
latter of which is registered (pipelined) and controls the 2nd $\mu$M stage 
(ALU). \\
Many of the control signals are encoded in the microinstructions in what I
have improperly called flags. You will see many references to flags in the
following text (\#end,\#decode, etc.). They are just signals that you can 
activate individually in each $\mu$I, some are active in the 1st stage, some in
the 2nd. They are all explained in section ~\ref{ucodeFlags}. \\
 
Note that microinstructions are atomic: both stages are guaranteed to
execute in all circumstances. Once the 1st stage of a $\mu$I has executed, 
the only thing that can prevent the execution of the 2nd stage is a reset.\\
It might have been easier to design the machine so that microinstructions
executed in one cycle, thus needing no pipeline for the $\mu$I itself. I 
arbitrarily chose to 'split' the microcode execution, figuring that it would be 
easier for me to understand and program the microcode; in hindsight it may have 
been a mistake but in the end, once the debugging is over, it makes little 
difference.\\
 
The core as it is now does not support wait states: it does all its
external accesses (memory or i/o, read or write) in one clock cycle. It would
not be difficult to improve this with some little modification to the
micromachine, without changes to the microcode.\\
Since the microcode rom is the same type of memory as will be used for program 
memory, the main advantage of microprogramming is lost. Thus, it would make 
sense to develop the core a bit further with support for wait states, so it 
could take advantage of the speed difference between the FPGA and external slow 
memory.\\
The register bank reads asynchronously, while writes are synchronous. This
is the standard behaviour of a Spartan LUT-based RAM. The register bank holds
all the 8080 registers, including the accumulator, plus temporary, 'hidden'
registers (x,y,w,z). Only the PSW register is held out of the register bank, in
a DFF-8 register.
 
\section{Micromachine control}
\label{umachineControl}
 
\subsection{Microcode operation}
\label{ucodeOperation}
 
There is little more to the core that what has already been said; all the
CPU operations are microcoded, including interrupt response, reset and
instruction opcode fetch. The microcode source code can be seen in file
\texttt{ucode/light8080.m80}, in a format I expect will be less obscure than a 
plain vhdl constant table.\\
 
The microcode table is a synchronous ROM with 512 32-bit words, designed
to fit in a Spartan 3 block ram. Each 32-bit word makes up a microinstruction.
The microcode 'program counter' (uc\_addr in the VHDL code) thus is a 9-bit
register.\\
Out of those 512 words, 256 (the upper half of the table) are used as a
jump-table for instruction decoding. Each entry at 256+NN contains a 'JSR' 
$\mu$I to the start of the microcode for the instruction whose opcode is NN. 
This seemingly unefficient use of RAM is in fact an optimization for the 
Spartan-3 architecture to which this design is tailored –-- the 2KB RAM blocks 
are too large for the microcode so I chose to fill them up with the decoding 
table.\\
This scheme is less than efficient where smaller RAM blocks are available (e.g.
Altera Stratix).\\
The jump table is built automatically by the microcode 
assembler, as explained in section ~\ref{ucodeAssembler}.\\
The upper half of the table can only be used for decoding; JSR
instructions can only point to the lower half, and execution from address 0x0ff
rolls over to 0x00 (or would; the actual microcode does not use this 
'feature').\\
 
The ucode address counter uc\_addr has a number of possible sources: the 
micromachine supports one level of micro-subroutine calls; it can also
return from those calls; the uc\_addr gets loaded with some constant values upon
reset, interrupt or instruction fetch. And finally, there is the decoding jump 
table mentioned above. So, in summary, these are the possible sources of 
uc\_addr each cycle:
 
\begin{itemize}
\item Constant value of 0x0001 at reset (see VHDL source for details).
\item Constant value of 0x0003 at the beginning (fetch cycle) of every
instruction.
\item Constant value of 0x0007 at interrupt acknowledge.
\item uc\_addr + 1 in normal microinstruction execution
\item Some 8-bit value included in JSR microinstructions (calls).
\item The return value preserved in the last JSR (used when flag \#ret is
raised)
\end{itemize}
 
All of this is readily apparent, I hope, by inspecting the VHDL source.
Note that there is only one jump microinstruction (JSR) which doubles as 'call';
whenever a jump is taken the the 1-level-deep 'return stack' is loaded with
the return address (address of the $\mu$I following the jump). You just have to
ignore the return address when you don't need it (e.g. the jumps in the decoding
jump table). I admit this scheme is awkward and inflexible; but it was the first
I devised, it works and fits the area budget: more than enough in this project.
A list of all predefined, 'special' microcode addresses follows.\\
\begin{itemize}
\item \textbf{0x001 –-- reset}\\
After reset, the $\mu$I program counter (uc\_addr in the VHDL code) is
initialized to 0x00. The program counter works as a pre-increment counter when
reading the microcode rom, so the $\mu$I at address 0 never gets executed (unless
'rolling over' from address 0x0ff, which the actual microcode does not). Reset
starts at address 1 and takes 2 microinstructions to clear PC to 0x0000. It does
nothing else. After clearing the PC the microcode runs into the fetch routine.
\item \textbf{0x003 –-- fetch}\\
The fetch routine places the PC in the address output lines while postincrementing
it, and then enables a memory read cycle. In doing so it relies on
T2 being 0x00 (necessary for the ADC to behave like an INC in the oversimplified
ALU), which is always true by design. After the fetch is done, the \#decode flag
is raised, which instructs the micromachine to take the value in the DI signal
(data input from external memory) and load it into the IR and the microcode
address counter, while setting the high address bit to 1. At the resulting
address there will be a JSR $\mu$I pointing to the microcode for the 8080 opcode in
question (the microcode assembler will make sure of that). The \#decode flag will
also clear registers T1 and T2.
\item \textbf{0x007 –-- halt}\\
Whenever a HALT instruction is executed, the \#halt flag is raised, which
when used in the same $\mu$I as flag \#end, makes the the micromachine jump to this
address. The $\mu$I at this address does nothing but raise flags \#halt and \#end. The
micromachine will keep jumping to this address until the halt state is left,
something which can only happen by reset or by interrupt. The \#halt flag, when
raised, sets the halt output signal, which will be cleared when the CPU exits
the halt state.
\end{itemize}
 
\subsection{Conditional jumps}
\label{conditionalJumps}
 
There is a conditional branch microinstruction: TJSR. This instruction
tests certain condition and, if the condition is true, performs exactly as JSR.
Otherwise, it ends the microcode execution exactly as if the flag \#end had been
raised. This microinstruction has been made for the conditional branches and
returns of the 8080 CPU and is not flexible enough for any other use.
The condition tested is encoded in the register IR, in the field ccc (bits
5..3), as encoded in the conditional instructions of the 8080 –-- you can look
them up in any 8080 reference. Flags are updated in the 2nd stage, so a TJSR
cannot test the flags modified by the previous $\mu$I. But it is not necessary; this
instruction will always be used to test conditions set by previous 8080
instructions, separated at least by the opcode fetch $\mu$Is, and probably many
more. Thus, the condition flags will always be valid upon testing.
 
\subsection{Implicit operations}
\label{implicitOperations}
 
Most micromachine operations happen only when explicitly commanded. But
some happen automatically and have to be taken into account when coding the
microprogram:
 
\begin{enumerate}
\item Register IR is loaded automatically when the flag \#decode is raised. The
microcode program counter is loaded automatically with the same value as
the IR, as has been explained above. From that point on, execution resumes
normally: the jump table contains normal JSR microinstructions.
\item T1 is cleared to 0x00 at reset, when the flag \#decode is active or when
the flag \#clrt1 is used.
\item T2 is cleared to 0x00 at reset, when the flag \#decode is active or when
the flag \#end is used.
\item Microcode flow control:
  \begin{enumerate}
  \item When flag \#end is raised, execution continues at $\mu$code address 
        0x0003.
  \item When both flags \#halt and \#end are raised, execution continues at 
        $\mu$code address 0x0007, unless there is an interrupt pending.
  \item Otherwise, when flag \#ret is raised, execution continues in the address 
        following the last JSR executed. If such a return is tried before a JSR 
        has executed since the last reset, the results are undefined –-- this 
        should never happen with the microcode source as it is now.
  \item If none of the above flags are used, the next $\mu$I is executed.
  \end{enumerate}
\end{enumerate} 
 
Notice that both T1 and T2 are cleared at the end of the opcode fetch, so
they are guaranteed to be 0x00 at the beginning of the instruction microcode.
And T2 is cleared too at the end of the instruction microcode, so it is
guaranteed clear for its use in the opcode fetch microcode. T1 can be cleared 
if a microinstruction so requires. Refer to the section on microinstruction 
flags.
 
 
\section{Microinstructions}
\label{uinstructions}
 
The microcode for the CPU is a source text file encoded in a format
described below. This 'microcode source' is assembled by the microcode assembler
(described later) which then builds a microcode table in VHDL format. There's
nothing stopping you from assembling the microcode by hand directly on the VHDL
source, and in a machine this simple it might have been better.
 
 
\subsection{Microcode source format}
\label{ucodeFormat}
 
The microcode source format is more similar to some early assembly language 
that to other microcodes you may have seen. Each non-blank,
non-comment line of code contains a single microinstruction in the format
informally described below:
 
% there must be some cleaner way to do this in TeX...
 
\begin{alltt}
\textless microinstruction line \textgreater :=
    [\textless label \textgreater]\footnote{Labels appear alone by themselves in a line} \textbar 
    \textless operand stage control \textgreater ; \textless ALU stage control \textgreater [; [\textless flag list \textgreater]] \textbar
    JSR \textless destination address \textgreater\textbar TJSR \textless destination address \textgreater
    \\
    \textless label \textgreater := \{':' immediately followed by a common identifier\}
    \textless destination address \textgreater := \{an identifier defined as a label anywhere in the file\}
    \textless operand stage control \textgreater := \textless op\_reg \textgreater = \textless op\_src \textgreater \textbar NOP
    \textless op\_reg \textgreater := T1 \textbar T2
    \textless op\_src \textgreater := \textless register \textgreater \textbar DI \textbar \textless IR register \textgreater
    \textless IR register \textgreater := \{s\}\textbar\{d\}\textbar\{p\}0\textbar\{p\}1\footnote{Registers are specified by IR field}
    \textless register \textgreater := \_a\textbar\_b\textbar\_c\textbar\_d\textbar\_e\textbar\_h\textbar\_l\textbar\_f\textbar\_a\textbar\_ph\textbar\_pl\textbar\_x\textbar\_y\textbar\_z\textbar\_w\textbar\_sh\textbar\_sl
    \textless ALU stage control \textgreater := \textless alu\_dst \textgreater = \textless alu\_op \textgreater \textbar NOP
    \textless alu\_dst \textgreater := \textless register \textgreater \textbar DO
    \textless alu\_op \textgreater := add\textbar adc\textbar sub\textbar sbb\textbar and\textbar orl\textbar not\textbar xrl\textbar rla\textbar rra\textbar rlca\textbar rrca\textbar aaa\textbar
    t1\textbar rst\textbar daa\textbar cpc\textbar sec\textbar psw
    \textless flag list \textgreater := \textless flag \textgreater [, \textless flag \textgreater ...]
    \textless flag \textgreater := \#decode\textbar\#di\textbar\#ei\textbar\#io\textbar\#auxcy\textbar\#clrt1\textbar\#halt\textbar\#end\textbar\#ret\textbar\#rd\textbar\#wr\textbar\#setacy 
          \#ld\_al\textbar\#ld\_addr\textbar\#fp\_c\textbar\#fp\_r\textbar\#fp\_rc\textbar\#clr\_acy \footnote{There are some restrictions on the flags that can be used together} \\
\end{alltt}
 
 
Please bear in mind that this is just an informal description; I made
it up from my personal notes and the assembler source. The ultimate reference is
the microcode source itself and the assembler source.\\
Due to the way that flags have been encoded (there's less than one bit per
flag in the microinstruction), there are restrictions on what flags can be used
together. See section ~\ref{ucodeFlags}.
 
The assembler will complain if the source does not comply with the
expected format; but syntax check is somewhat weak.
In the microcode source you will see words like \_\_reset, \_\_fetch, etc.
which don't fit the above syntax. Those were supposed to be assembler pragmas,
which the assembler would use to enforce the alignment of the microinstructions
to certain addresses. I finally decided not to use them and align the
instructions myself. The assembler ignores them but I kept them as a reminder.
 
The 1st part of the $\mu$I controls the ALU operand stage; we can load either
T1 or T2 with either the contents of the input signal DI, or the selected
register from the register bank. Or, we can do nothing (NOP).\\
The 2nd part of the $\mu$I controls the ALU stage; we can instruct the ALU to
perform some operation on the operands T1 and T2 loaded by this same
instruction, in the previous stage; and we can select where to load the ALU
result, eiher in the output register DO or in the register bank. Or we can do
nothing of the above (NOP).
 
The write address for the register bank used in the 2nd stage has to be the
same as the read address used in the 1st stage; that is, if both $\mu$I parts use the
RB, both have to use the same address (the assembler will enforce this
restriction). This is due to an early, silly mistake that I chose not to fix:
there is a single $\mu$I field that holds both addresses.\\
This is a very annoying limitation that unduly complicates the microcode
and wastes many microcode slots for no saving in hardware; I just did not want 
to make any major refactors until the project is working. As
you can see in the VHDL source, the machine is prepared to use 2 independent
address fields with little modification. I may do this improvement and others
in a later version, but only when I deem the design 'finished' (since the design
as it is already exceeds my modest performance target).
 
 
\subsection{Microcode ALU operations}
\label{ucodeAluOps}
 
\begin{tabular}{|l|l|l|l|}
\hline
\multicolumn{4}{|c|}{ALU operations} \\
\hline
Operation & encoding & result & notes \\ 
 
\hline ADD & 001100 & T2 + T1 & \\
\hline ADC & 001101 & T2 + T1 + CY & \\
\hline SUB & 001110 & T2 - T1 & \\
\hline SBB & 001111 & T2 – T1 - CY & \\
\hline AND & 000100 & T1 AND T2 & \\
\hline ORL & 000101 & T1 OR T2 & \\
\hline NOT & 000110 & NOT T1 & \\
\hline XRL & 000111 & T1 XOR T2 & \\
\hline RLA & 000000 & 8080 RLC & \\
\hline RRA & 000001 & 8080 RRC & \\
\hline RLCA & 000010 & 8080 RAL & \\
\hline RRCA & 000011 & 8080 RAR & \\
\hline T1 & 010111 & T1 & \\
\hline RST & 011111 & 8*IR(5..3) & as per RST instruction \\
\hline DAA & 101000 & DAA T1 & but only after executing 2 in a row \\
\hline CPC & 101100 & UNDEFINED & CY complemented \\
\hline SEC & 101101 & UNDEFINED & CY set \\
\hline PSW & 110000 & PSW & \\
\hline
 
\end{tabular}
 
 
 
Notice that ALU operation DAA takes two cycles to complete; it uses a
dedicated circuit with an extra pipeline stage. So it has to be executed twice
in a row before taking the result -- refer to microcode source for an example.\\
The PSW register is updated with the ALU result at every cycle, whatever
ALU operation is executed –- though every ALU operation computes flags by
different means, as it is apparent in the case of CY. Which flags are updated,
and which keep their previous values, is defined by a microinstruction field
named flag\_pattern. See the VHDL code for details.
 
 
\subsection{Microcode binary format}
\label{ucodeBinFormat}
 
\begin{tabular}{|l|l|l|}
\hline
\multicolumn{3}{|c|}{Microcode word bitfields} \\ \hline
POS & VHDL NAME & PURPOSE \\ \hline
31..29 & uc\_flags1 & Encoded flag of group 1 (see section on flags) \\ \hline 
28..26 & uc\_flags2 & Encoded flag of group 2 (see section on flags) \\ \hline
25 & load\_addr & Address register load enable (note 1) \\ \hline
24 & load\_al & AL load enable (note 1) \\ \hline
23 & load\_t1 & T1 load enable \\ \hline
22 & load\_t2 & T2 load enable \\ \hline
21 & mux\_in & T1/T2 source mux control (0 for DI, 1 for reg bank) \\ \hline
20..19 & rb\_addr\_sel & Register bank address source control (note 2) \\ \hline
18..15 & ra\_field & Register bank address (used both for write and read) \\ \hline
14 & clr\_acy & Clear CY and AC -- see explaination below (pipelined signal) \\ \hline
13..10 & (unused) & Reserved for write register bank address, unused yet \\ \hline
11..10 & uc\_jmp\_addr(7..6) & JSR/TJSR jump address, higher 2 bits \\ \hline
9..8 & flag\_pattern & PSW flag update control (note 3) (pipelined signal) \\ \hline
7 & load\_do & DO load enable (note 4) (pipelined signal) \\ \hline
6 & we\_rb & Register bank write enable (pipelined signal) \\ \hline
5..0 & uc\_jmp\_addr(5..0) & JSR/TJSR jump address, lower 6 bits \\ \hline
5..0 & (several) & Encoded ALU operation \\ \hline
\end{tabular}
 
\begin{itemize}
\item {\bf Note 1: load\_al}\\
AL is a temporary register for the lower byte of the external 16 bit
address. The memory interface (and the IO interface) assumes external
synchronous memory, so the 16 bit address has to be externally loaded as
commanded by load\_addr.
Note that both halves of the address signal load directly from the
register bank output; you can load AL with PC, for instance, in the same cycle
in which you modify the PC –- AL will load with the pre-modified value.
 
\item {\bf Note 2 : rb\_addr\_sel}\\
A microinstruction can access any register as specified by ra\_field, or
the register fields in the 8080 instruction opcode: S, D and RP (the
microinstruction can select which register of the pair). In the microcode source
this is encoded like this:
\begin{description}
\item[\{s\}] $\Rightarrow$ 0 \& SSS
\item[\{d\}] $\Rightarrow$ 0 \& DDD
\item[\{p\}0] $\Rightarrow$ 1 \& PP \& 0 (HIGH byte of register pair)
\item[\{p\}1] $\Rightarrow$ 1 \& PP \& 1 (LOW byte of register pair)
\end{description}
\small SSS = IR(5 downto 3) (source register)\\
\small DDD = IR(2 downto 0) (destination register)\\
\small PP = IR(5 downto 4) (register pair)\\
 
\item {\bf Note 3 : flag\_pattern}\\
Selects which flags of the PSW, if any, will be updated by the
microinstruction:
\begin{itemize}
\item When flag\_pattern(0)='1', CY is updated in the PSW.
\item When flag\_pattern(1)='1', all flags other than CY are updated in the PSW.
\end{itemize}
 
\item {\bf Note 4 : load\_do}\\
DO is the data ouput register that is loaded with the ALU output, so the
load enable signal is pipelined.
 
\item {\bf Note 5 : JSR-H and JSR-L}\\
These fields overlap existing fields which are unused in JSR/TJSR
instructions (fields which can be used with no secondary effects).
 
\end{itemize}
 
\subsection{Microcode flags}
\label{ucodeFlags}
 
 
Flags is what I have called those signals of the microinstruction that you
assert individually in the microcode source. Due to the way they have been
encoded, I have separated them in two groups. Only one flag in each group can be
used in any instruction. These are all the flags in the format thay appear in
the microcode source:
 
\begin{itemize}
\item Flags from group 1: use only one of these
  \begin{itemize}
  \item \#decode : Load address counter and IR with contents of data input
  lines, thus starting opcode decoging.
  \item \#ei : Set interrupt enable register.
  \item \#di : Reset interrupt enable register.
  \item \#io : Activate io signal for 1st cycle.
  \item \#auxcy : Use aux carry instead of regular carry for this $\mu$I.
  \item \#clrt1 : Clear T1 at the end of 1st cycle.
  \item \#halt : Jump to microcode address 0x07 without saving return value,
  when used with flag \#end, and only if there is no interrupt
  pending. Ignored otherwise.
  \end{itemize} 
 
\item Flags from group 2: use only one of these
  \begin{itemize}
  \item \#setacy : Set aux carry at the start of 1st cycle (used for ++).
  \item \#end : Jump to microinstruction address 3 after the present m.i.
  \item \#ret : Jump to address saved by the last JST or TJSR m.i.
  \item \#rd : Activate rd signal for the 2nd cycle.
  \item \#wr : Activate wr signal for the 2nd cycle.
  \end{itemize} 
 
\item Independent flags: no restrictions
  \begin{itemize}
  \item \#ld\_al : Load AL register with register bank output as read by opn. 1
  (used in memory and io access).
  \item \#ld\_addr : Load address register (H byte = register bank output as read
  by operation 1, L byte = AL).
  Activate vma signal for 1st cycle.  
  \item \#clr\_acy : Clear PSW flags AC and CY, except for AND instructions 
  (ALU operation = 000100), where AC is set.
  Meant to be used with flag \#fp\_rc for the logic instructions (AND, OR, XOR).
  See \ref{compatibility} for a note about compatibility to the original 8080.
  \end{itemize}  
 
\item PSW update flags: use only one of these
  \begin{itemize}
  \item \#fp\_r : This instruction updates all PSW flags except for C.
  \item \#fp\_c : This instruction updates only the C flag in the PSW.
  \item \#fp\_rc : This instruction updates all the flags in the PSW.
  \end{itemize}
 
\end{itemize}
 
\section{Notes on the microcode assembler}
\label{ucodeAssembler}
 
The microcode assembler is a Perl script (\texttt{util/uasm.pl}). Please refer 
to the comments in the script for a reference on the usage of the assembler.\\
I will admit up front that the microcode source format and the assembler
program itself are a mess. They were hacked quickly and then often retouched 
but never redesigned, in order to avoid the 'never ending project' syndrome.\\
Please note that use of the assembler, and the microcode assembly source,
is optional and perhaps overkill for this simple core. All you need to build the
core is the vhdl source file.\\
 
The perl assembler itself accounted for more than half of all the bugs I caught 
during development. 
Though the assembler certainly saved me a lot of mistakes in the hand-assembly 
of the microcode, a half-cooked assembler like
this one may do more harm than good. I expect that the program now behaves
correctly; I have done a lot of modifications to the microcode source for
testing purposes and I have not found any more bugs in the assembler. But you
have been warned: don't trust the assembler too much (in case someone actually
wants to mess with these things at all).\\
The assembler is a Perl program (\texttt{util/uasm.pl}) that will read a 
microcode text source file and write to stdout a microcode table in the form of 
a chunk of VHDL code. You are supposed to capture that output and paste it into 
the VHDL source (Actually, I used another perl script to do that, but I don't 
want to overcomplicate an already messy documentation).\\
The assembler can do some other simple operations on the source, for debug 
purposes. The invocation options are documented in the program file.\\
You don't need any extra Perl modules or libraries, any distribution of Perl 5 
will do -– earlier versions should too but might not, I haven't
tested.
 
\section{CPU details}
\label{cpuDetails}
 
\subsection{Synchronous memory and i/o interface}
\label{syncMem}
 
The core is designed to connect to external synchronous memory similar to
the internal fpga ram blocks found in the Spartan series. It can be used with
asynchronous ram provided that you add the necessary registers (I have used it
with external SRAM included on a development board with no trouble).
 
Signal 'vma' is the master read/write enable. It is designed to be used as
a synchronous rd/wr enable. All other memory/io signals are only valid when vma
is active. Read data is sampled in the positive clock edge following deassertion
of vma. Than is, the core expects external memory and io to behave as an
internal fpga block ram would.\\
I think the interface is simple enough to be fully described by the
comments in the header of the VHDL source file.
 
\subsection{Interrupt response}
\label{irqResponse}
 
Interrupt response has been greatly simplified, but it follows the outline
of the original procedure. The biggest difference is that inta is
active for the entire duration of the instruction, and not only the opcode fetch
cycle.
 
Whenever a high value is sampled in line intr in any positive clock edge,
an interrupt pending flag is internally raised. After the current instruction
finishes execution, the interrupt pending flag is sampled. If active, it is
cleared, interrupts are disabled and the processor enters an inta cycle. If
inactive, the processor enters a fetch cycle as usual.
The inta cycle is identical to a fetch cycle, with the exception that inta
signal is asserted high.
 
The processor will fetch an opcode during the first inta cycle and will
execute it normally, except the PC increment will not happen and inta will be
high for the duration of the instruction. Note that though pc increment is
inhibited while inta is high, pc can be explicitly changed (rst, jmp, etc.).
After the special inta instruction execution is done, the processor
resumes normal execution, with interrupts disabled.\\
The above means that any instruction (even XTHL, which the original 8080
forbids) can be used as an interrupt vector and will be executed normally. The
core has been tested with rst, lxi and inr, for example.
 
Since there's no M1 signal available, feeding multi-byte instructions as
interrupt vectors can be a little complicated. It is up to you to deal with this
situation (i.e. use only single-byte vectors or make up some sort of cycle 
counter). 
 
\subsection{Instruction timing}
\label{timing}
 
This core is slower than the original in terms of clocks per instruction.
Since the original 8080 was itself one of the slowest micros ever, this does not
say much for the core. Yet, one of these clocked at 50MHz would outperform an
original 8080 at 25 Mhz, which is fast enough for many control applications ---
except that there are possibly better alternatives.\\
A comparative table follows.
 
 
\begin{tabular}{|l|l|l|l|l|l|l|}
\hline
\multicolumn{7}{|c|}{Instruction timing (core vs. original)} \\ \hline
 
Opcode & Intel 8080 & Light8080 & & Opcode & Intel 8080 & Light8080 \\ \hline
 
MOV r1, r2 & 5 & 6 & &        XRA M & 7 & 9 \\ \hline
MOV r, M & 7 & 9 & &          XRI data & 7 & 9 \\ \hline
MOV M, r & 7 & 9 & &          ORA r & 4 & 6 \\ \hline
MVI r, data & 7 & 9 & &       ORA M & 7 & 9 \\ \hline
MVI M, data & 10 & 12 & &     ORI data & 7 & 9 \\ \hline
LXI rp, data16 & 10 & 14 & &  CMP r & 4 & 6 \\ \hline
LDA addr & 13 & 16 & &        CMP M & 7 & 9 \\ \hline
STA addr & 13 & 16 & &        CPI data & 7 & 9 \\ \hline
LHLD addr & 16 & 19 & &       RLC & 4 & 5 \\ \hline
SHLD addr & 16 & 19 & &       RRC & 4 & 5 \\ \hline
LDAX rp & 7 & 9 & &           RAL & 4 & 5 \\ \hline
STAX rp & 7 & 9 & &           RAR & 4 & 5 \\ \hline
XCHG & 4 & 16 & &             CMA & 4 & 5 \\ \hline
ADD r & 4 & 6 & &             CMC & 4 & 5 \\ \hline
ADD M & 7 & 9 & &             STC & 4 & 5 \\ \hline
ADI data & 7 & 9 & &          JMP & 10 & 15 \\ \hline
ADC r & 4 & 6 & &             Jcc & 10 & 12/16 \\ \hline
ADC M & 7 & 9 & &             CALL & 17 & 29 \\ \hline
ACI data & 7 & 9 & &          Ccc & 11/17 & 12/30 \\ \hline
SUB r & 4 & 6 & &             RET & 10 & 14 \\ \hline
SUB M & 7 & 9 & &             Rcc & 5/11 & 5/15 \\ \hline
SUI data & 7 & 9 & &          RST n & 11 & 20 \\ \hline
SBB r & 4 & 6 & &             PCHL & 5 & 8 \\ \hline
SBB M & 7 & 9 & &             PUSH rp & 11 & 19 \\ \hline
SBI data & 7 & 9 & &          PUSH PSW & 11 & 19 \\ \hline
INR r & 5 & 6 & &             POP rp & 10 & 14 \\ \hline
INR M & 10 & 13 & & POP PSW & 10 & 14 \\ \hline
INX rp & 5 & 6 & & XTHL & 18 & 32 \\ \hline
DCR r & 5 & 6 & & SPHL & 5 & 8 \\ \hline
DCR M & 10 & 14 & & EI & 4 & 5 \\ \hline
DCX rp & 5 & 6 & & DI & 4 & 5 \\ \hline
DAD rp & 10 & 8 & & IN port & 10 & 14 \\ \hline
DAA & 4 & 6 & & OUT port & 10 & 14 \\ \hline
ANA r & 4 & 6 & & HLT & 7 & 5 \\ \hline
ANA M & 7 & 9 & & NOP & 4 & 5 \\ \hline
ANI data & 7 & 9 & & & & \\ \hline
XRA r & 4 & 6 & & & & \\ \hline
 
\end{tabular}
 
\clearpage
 
\subsection{Binary compatibility to original 8080}
\label{compatibility}
 
Flag AC (auxiliary carry) does not work exactly as in the original 8080. In the 
original 8080, ANI and ANA don't clear AC but set it to the OR'ing of
bits 3 of the ALU operands.
 
In this core, these two instructions instead set the AC flag to 1. In this, the
core is compatible to the 8085 ad not to the 8080.
 
That is the only difference to the original 8080 that I am aware of. 
Unfortunately, the only test bench that I have available right now is not 
exhaustive enough to pick that kind of detail. Until I develop a stronger test 
bench, full compatibility to the 8080 can't be guaranteed.
 
\end{document}