Hi Ryan
Hey all, just an update on this: First, I reverted to an old copy of
the libraries -- it didn't work, but had a different problem. It
looks like after you have more than a certain number of yellow blocks
in use, the tools start using the opb2opb_lite pcore, which can be had
from the pcores_for_ise13 that I made a while back. I only copied the
two cores it required (I found out about the second one on the second
build attempt) -- didn't copy all of them in fear of running into the
coregen issue for some reason. Now it's building quite nicely.
So, long story short, be wary of weird behavior when you have /many/
yellow blocks.
The logic deciding how to set up the yellow blocks in the system (in
casper_library/gen_xps_mod_mhs.m) works as follows;
Most yellow blocks are hard-coded to use the primary opb bus (opb0) at a
fixed address offset, e.g SDRAM, QDR SRAM, 10Ge etc. Shared BRAM and
software registers as a group are allocated a fixed address space but
are added as they are required.
The bus controller for the primary opb0 bus can support up to 32 slaves,
and a fixed address space size. If more slaves are instantiated, or the
address space required is greater than what it can support, an opb
bridge (opb2opb_lite) is connected to the controller, and a new
controller connected to this bridge, which adds another opb bus (opb1)
to the system. This process is repeated (add a bridge to opb0, connect
it to a controller to make a new bus etc) if more opb busses are
required allowing many hundreds of Shared BRAMs and/or software
registers. The upper limit is reached when there as many secondary
(opb1, opb2 etc) busses as there are open slots (minus any fixed opb0
devices) available on the primary opb0 bus controller.
Regards
Andrew
