Re-added the old opb_dram_sniffer block which serves as the CPU interface for the DRAM.

Changes are forth-coming to make this work properly with the new DDR3 controller and
async FIFO pcores.

This reverts part of commit bd4df168351ce584a45fb7843c7b14e56ada09b4.
Merge branch 'master' into ddr3_devel
[opb_dram_sniffer] Rewrote a lot of the OPB DDR3 slave.

Lots of changes here. Mostly a totaly rewrite of dram_arbiter and
mem_opb_attach to work with the newest DDR3 block for ROACH2.

NOTE: Presently this DOES NOT WORK and is a state of development.
edited xps_library/\@xps_dram/gen_mhs_ip.m to change the ddr3_controller variable for ROACH2 DDR3_APP to ddr3_ctrl instead of ddr3_app.  this change allows us to insert the OPB interface when previously it was not accounted for.  As of now, no plans to relabel DDR3_APP variable in the ddr3_controller files, but the naming discrepancy is noted.
added opb_dram_sniffer instantiation for ROACH2 into @xps_dram/gen_mhs_ip.m

This commit adds the opb_dram_sniffer for the ROACH2 case,
previously omitted in the gen_mhs_ip.m file.  This alteration,
along with the previously committed port change to the ddr3_contr-
oller instantiation in the gen_mhs_ip.m file fully hooks the
current opb_dram_sniffer under test into the design.
[opb_dram_sniffer] Removed logic for setting Sl_errAck in mem_opb_attach.v

I believe this was causing the PowerPC to hang when writing to or reading from
other OPB slaves since the error was being set when OPB_select=1 and the OPB_ABus
was out of range of the slave. This was not strictly needed so it's been removed
and it seems to fix the hanging issue.
[core_info.tab] now includes ddr3_ctrl and ddr3_mem registers

I removed previous dram inclusions as they pertained specifically
to the ROACH, rather than the ROACH2.  I've added dram registers
for the OPB slaves, ddr3_ctrl and ddr3_mem, read-write capable,
and used the addresses specified in system.mhs.
[opb_dram_sniffer] added transfer states to opb state machine in mem_opb_attach.v

Looking at timing diagrams for OPB protocol I noticed through simulation that given the timing of OPB_select and Sl_xferAck, the code as it was triggered an extra read operation after OPB_select goes low.  This should not be the case, and adding an extra clock cycle via a transfer state corrects for this.  In testing a compiled design this change appears to lead to better performance but does not correct for all of the misbehavior.  Namely, there is a place where the reading operation hangs in the opb state READ and the DDR3 state WRITE.  Puzzling as this should only occur (as the code is written, to my current understanding) with OPB_RNW set to 0.
[ctrl_opb_attach.v] Removed combinational process

After noticing that occasionally after writing an arbiter override
into the ddr3_ctrl (0x81 into offset 8), we would read the software
address register (ddr3_ctrl offset 0) and see this same 0x81.  This
should not be happening. The override and the software address are
actually the only places that can be written, so this suggested
funny timing in the state machine such that these writes/reads were
crossing into the incorrect address space.  Simulation, however,
indicated no errors in timing.  Rurik noticed the always @(*) process
and suggested that piece can cause funny thigns to happen, so I
rewrote the ctrl_opb_attach.v code incorporating that logic into the
main process.  The code simulated and produced identical timing as
the previous version, but when implemented in the FPGA we no longer
saw this mistaken writing to or reading from the wrong address.
[opb_dram_sniffer/tb/isim] Added isim test bench for ctrl_opb_attach.v and mem_opb_attach.v

Added test benches for isim that I have been using to work out bugs
with ctrl and mem.
[mem_opb_attach.v] added states to OPB state machine, added probe for max_clocks

To follow OPB documentation and timing more clearly, I have added
"Select" and "transfer" states to the OPB state machine.  This has
not successfully fixed the bugs, but it makes the timing simulate
in a way that agrees with the documentation.  Also prompting this
commit is adding a probe for "max clocks" that is, the maximum
number of clock cycles to complete a single OPB action.  A fear
is that the timeout suppress signal may not be routed, and with
random latency in the ddr3 we may enter a state that aborts in
the middle of a read due to a timeout and the code is not handlign
that properly.
[pcores] adding in removed pcores
[ctrl_opb_attach.v] Fixed timing so Sl_DBus only non-zero on Sl_xferAck

Added a condition that executes on the posedge of the opb clock that
sets the Sl_DBus to 32'b0, so this condition is only changed in
the state machine with the Sl_xferAck firing at the same time.
[opb_dram_sniffer.v] added max_clks probe for max latency in ddr3 opb reads

Added max_clks to instantiations of mem_opb_attach and ctrl_opb_attach
so that this quantity can be viewed by reading from the ddr3_ctrl
virtual memory space.  This quantity is 8 bits and when executing a
katcp read command to offset 4 of ddr3_ctrl, you obtain a 32 bit
number: {16'b0,max_clks,mem_opb_state,mem_dram_state} where max_clks
is 8 bits and the two states are 4 bits each.
[mem_opb_attach.v] no longer hangs after sequential reads

Several adjustments here.  The first is the addition of counters
and reset counter signals added into mem_opb_attach.v.  This allowed
us information about latency and in which state of the state
machines the code was getting stuck.

After examination of these numbers, it was clear that OPB was
issuing a read, but the ddr3 state machine was not exiting
the IDLE state.  The info showed that toutsup must have been
working as expected as the OPB held in the read state for 1001
clocks (timeout occurs on 16 clocks if toutsup not held).  However,
this showed us that there is perhaps some overall timeout that
deselects the opb device after 1000(ish) clocks.

Inspecting the mem_opb_attach ddr3 state machine we saw that to
initialize a read, the ddr3 must see a "rising edge" determined by
comparing two parameters:  a read enable derived from the opb clock
and the previous read_enable sampled at the ddr3 clock.  by sampling
the opb read_en signal in the ddr3 state machine for 2 clocks, we
now compare those to find a positive edge.  Later in the ddr3 state
machine, there was also a comparison to the opb timed read_en signal
which was replaced by the ddr3 read_en signal, read_en_z.
[opb_dram]  initial addition of mapping of opb address space to ddr3 address space

Added more probes to determine the actual opb_addr generated by a "read" command
in opb address space.  turns out its always a multiple of 4.  Turns out when
putting this value directly into the ddr3 address space, i get the counter
back perfectly the way JP writes it in simulink.  this is suspicious to me...

regardless to account for this, I take a step to map opb_addr values
to 32-bit words in the 288 ddr3 address space.  this leaves a word in the ddr3
memory unretrieved (the 9th 32 bit word), but this is just the simple mapping
to start with.  For now, translate is called but the outputs are not used.
I'm just setting things up for some testing.
[mem_opb_attach.v] now uses "translate" to map between opb_addr and ddr3_addr space

This translate code unfortunately only grabs 8 bits per word, and does not use
the software_address link from control, so only can grab up to 2^29 ddr3 addresses,
much more than the 2^21 we need, but both still exceed the memory limits of the
opb address space.  Nonetheless, this works currently.  Still buggy reads (99.9%)
data is read correctly, and arbiter only works in override mode.
[translate and mem_opb_attach] adjusts translate code to skip addresses by 8

According to the MIG documentation and the ddr3_controller code,
the MIG is set up with BL8 encoding (Burst Length 8) where word
length is 72, so a burst of 8 is in fact 288*2 bits.  The address
should skip by 8 every time, so that for a given address 2 288 bit
words are retrieved from the ddr3, each on a separate clock cycle.
This has been tested and cuts the errors in half relative
to the mistaken skip by 4 addressing.  Errors now occur on 0.03%
of reads, but the errors can be large as they are either 0 or
have a few bits flipped.
[opbaddr_2_Dnum_O9num.v] maps all 9 32-bit words from ddr3 288 bit word, and maps the rest of the space to 0

this maps between the opb virtual address space and the ddr3 address space

BL8 encoding is used in the MIG, so for a given ddr3 address, 8 72-bit
words are produced as 2 288-bit words (denoted here as DXa and DXb where X
is the ddr3 address value given to the controller, skips by 8.) These
two words are produced on consecutive ddr3 clock cycles.

Unfortunately, in a 288 bit word there are 9 32-bit words, or 9 opb-sized
words.  example: opb read from opb address space 17 will produce data
from the second 288 bit ddr3 word produced from ddr3 address 0, and from that
word we will map to chunk 1 (starting from 0) indicating a slice of bits 32:63.
I am arbitrarily saying that opb address 17 then maps to D0b-O1. "D" indicates
ddr3 sized words (288) and O indicates opb-sized words (32).  The first
48 consecutive reads from opb space are shown below:

0      1      2      3      4      5      6      7      8      9  10  11  12  13  14  15
D0a-O0 D0a-O1 D0a-O2 D0a-O3 D0a-O4 D0a-O5 D0a-O6 D0a-O7 D0a-O8 0  0   0   0   0   0   0

16     17     18     19     20     21     22     23     24     25 26  27  28  29  30  31
D0b-O0 D0b-O1 D0b-O2 D0b-O3 D0b-O4 D0b-O5 D0b-O6 D0b-O7 D0b-O8 0  0   0   0   0   0   0

32     33     34     35     36     37     38     39     40     41 42  43  44  45  46  47
D8a-O0 D8a-O1 D8a-O2 D8a-O3 D8a-O4 D8a-O5 D8a-O6 D8a-O7 D8a-O8 0  0   0   0   0   0   0

with some opb virtual memory locations mapped to 0 arbitrarily.
can still implement a divide by 9, but this is ok for now. All of this
map shown above would be produced from executing a read from ddr3
address 0 as given to the ddr3 controller.  The next ddr3 address
given to the controller will be 8, and the code developed here
accounts for that.

In terms of opb virtual memory space, only 2^16 bytes are allocated.
So given that roughly half are mapped to 0, this lets us read 2^15 bytes of
data, or roughly 32 kB.  To access all 4 GB of data from the ddr3
address, the "software_address_bits" are used to designate which 2^16 byte
chunk of data to which the opb address space is currently mapped.
Merge branch 'ddr3_devel'