[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.