Bah, I should have looked more closely... that is absolutely it.
Clearly, I was breaking the 32 boundary and triggering the need for a
bridge. I don't know what caused the initial error though.
--Ryan Monroe
626.773.0805
On 05/14/2013 11:13 PM, Andrew Martens wrote:
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
