Re: [casper] Problem using shared bram/snap blocks for Roach 2
Hi Nimish
However, the problem still remains with my main design. I believe it
has to do with number of software registers and shared brams in the
design.
At the moment the EPB bus from the PowerPC is connected to an OPB bus
(opb0 in your system.mhs). Each OPB bus can handle up to 32 devices and
has a fixed size address space.
When more devices are used (or the address space for the bus is
exhausted), an opb to opb bridge (opb2opb) is instantiated and replaces
one of the devices on opb0 (which is added to the new bridge). New
devices are connected to the bus attached to this bridge (opb1) until
the bus is full. At that point another bridge replaces a device on opb0
and another bus (opb2) can be filled.
Controllers for ADCs, QDRs, 10Ge blocks etc are hard-coded to reside on
the opb0 bridge. The remaining slots can all be filled with opb2opb
bridges.
Assuming around 16 hard-coded controllers on opb0 (a lot), and shared
bram sizes that don't exhaust the address space for each bridge, there
should be space for at least (16 * 32 =) 512 software registers and
shared brams before the slots on opb0 are exhausted.
(For those interested, the logic to allocate devices, create bridges etc
resides in xps_library/gen_xps_mod_mhs.m. You can also see the address
allocation whilst compiling by setting 'casper_log_groups =
{'gen_xps_mod_mhs_debug'}' from the Matlab prompt before compilation or
by looking at the generated system.mhs file)
I am routinely exceeding this limit and the only way I can get things
work is by somehow reducing the number of software registers or shared
brams in the design. It is more of trial and error. Is there any way
to figure out that limit or ways to avoid that?
It may be that your shared brams are very large, causing the need for
many bridges as you blow through the allocated space per bridge. Please
check that you need the space you are asking for.
I would advise using the snapshot block rather than snap64. The snapshot
block uses a single shared BRAM rather than two, halving the number of
devices on the bus (and you don't have to merge the data from both BRAMs
again later in software).
Also note that the shared BRAM can output (and input) non-32-bit busses
from your design (8, 16, 32, 64 and 128 bit are all possible). So output
a 64 bit bus and split it into two 32 bit busses (for example). This can
be used to reduce the number of shared BRAMs (also reducing address
decoding logic, and possibly actual BRAMs) required for the same
operation.
Please send me your (zipped) .mdl file if you still have problems.
Regards
Andrew
Re: [casper] Problem using shared bram/snap blocks for Roach 2
Hi Andrew,
Thanks for this detailed information. I realized that snapshot block is
going to be the preferred choice in future from one of the warnings in the
latest github version. It certainly looks nice. I will need some time to go
through your suggestions and try them out, but now I know where to look for
the problem.
Thanks,
Nimish
On Mon, Aug 13, 2012 at 3:26 AM, Andrew Martens and...@ska.ac.za wrote:
Hi Nimish
However, the problem still remains with my main design. I believe it
has to do with number of software registers and shared brams in the
design.
At the moment the EPB bus from the PowerPC is connected to an OPB bus
(opb0 in your system.mhs). Each OPB bus can handle up to 32 devices and
has a fixed size address space.
When more devices are used (or the address space for the bus is
exhausted), an opb to opb bridge (opb2opb) is instantiated and replaces
one of the devices on opb0 (which is added to the new bridge). New
devices are connected to the bus attached to this bridge (opb1) until
the bus is full. At that point another bridge replaces a device on opb0
and another bus (opb2) can be filled.
Controllers for ADCs, QDRs, 10Ge blocks etc are hard-coded to reside on
the opb0 bridge. The remaining slots can all be filled with opb2opb
bridges.
Assuming around 16 hard-coded controllers on opb0 (a lot), and shared
bram sizes that don't exhaust the address space for each bridge, there
should be space for at least (16 * 32 =) 512 software registers and
shared brams before the slots on opb0 are exhausted.
(For those interested, the logic to allocate devices, create bridges etc
resides in xps_library/gen_xps_mod_mhs.m. You can also see the address
allocation whilst compiling by setting 'casper_log_groups =
{'gen_xps_mod_mhs_debug'}' from the Matlab prompt before compilation or
by looking at the generated system.mhs file)
I am routinely exceeding this limit and the only way I can get things
work is by somehow reducing the number of software registers or shared
brams in the design. It is more of trial and error. Is there any way
to figure out that limit or ways to avoid that?
It may be that your shared brams are very large, causing the need for
many bridges as you blow through the allocated space per bridge. Please
check that you need the space you are asking for.
I would advise using the snapshot block rather than snap64. The snapshot
block uses a single shared BRAM rather than two, halving the number of
devices on the bus (and you don't have to merge the data from both BRAMs
again later in software).
Also note that the shared BRAM can output (and input) non-32-bit busses
from your design (8, 16, 32, 64 and 128 bit are all possible). So output
a 64 bit bus and split it into two 32 bit busses (for example). This can
be used to reduce the number of shared BRAMs (also reducing address
decoding logic, and possibly actual BRAMs) required for the same
operation.
Please send me your (zipped) .mdl file if you still have problems.
Regards
Andrew
[casper] Problem using shared bram/snap blocks for Roach 2
Hi all, I am trying to compile a design with few snap blocks, specifically snap64 blocks for Roach 2 — ska-sa software library, Xilinx 11.4 tools, Linux, Roach 2, KatADC, 150MHz FPGA clock. The compilation fails with platgen errors. I tried compiling a design with just a snap64 block in it. Please find the log attached to this email that shows these errors. I can confirm that the problem is with the shared bram yellow block. I have used this block previously. It never had any such problems before. Any suggestions? Thanks, Nimish platgen.log Description: Binary data
Re: [casper] Problem using shared bram/snap blocks for Roach 2
Hi Nimish, How are you clocking your design? Mark On Sat, Aug 11, 2012 at 6:48 AM, Nimish Sane nimishs...@gmail.com wrote: Hi all, I am trying to compile a design with few snap blocks, specifically snap64 blocks for Roach 2 — ska-sa software library, Xilinx 11.4 tools, Linux, Roach 2, KatADC, 150MHz FPGA clock. The compilation fails with platgen errors. I tried compiling a design with just a snap64 block in it. Please find the log attached to this email that shows these errors. I can confirm that the problem is with the shared bram yellow block. I have used this block previously. It never had any such problems before. Any suggestions? Thanks, Nimish
Re: [casper] Problem using shared bram/snap blocks for Roach 2
Hi Danny, Yes, I am using as many bits as possible in software registers and slicing individual fields in it. Thanks, Nimish On Sat, Aug 11, 2012 at 5:51 PM, Danny Price danny.pr...@astro.ox.ac.ukwrote: Hi Nimish Are you fully using every bit of the 32-bit registers? If not, you could for example consider using a single 32-bit register as four 8-bit registers: you would just need to slice the upper, middle, and lower bits off the 32-bit register in 8-bit chunks. Equally, one register could house 32 booleans, if you slice each bit individually. Cheers Danny On 11/08/2012 22:34, Nimish Sane wrote: Hi Mark, Using ADC clock. But the error I was mentioning (specifically the log that I sent) has been resolved. However, the problem still remains with my main design. I believe it has to do with number of software registers and shared brams in the design. I am routinely exceeding this limit and the only way I can get things work is by somehow reducing the number of software registers or shared brams in the design. It is more of trial and error. Is there any way to figure out that limit or ways to avoid that? Thanks, Nimish On Sat, Aug 11, 2012 at 4:00 PM, Mark Wagner mwag...@ssl.berkeley.eduwrote: Hi Nimish, How are you clocking your design? Mark On Sat, Aug 11, 2012 at 6:48 AM, Nimish Sane nimishs...@gmail.comwrote: Hi all, I am trying to compile a design with few snap blocks, specifically snap64 blocks for Roach 2 — ska-sa software library, Xilinx 11.4 tools, Linux, Roach 2, KatADC, 150MHz FPGA clock. The compilation fails with platgen errors. I tried compiling a design with just a snap64 block in it. Please find the log attached to this email that shows these errors. I can confirm that the problem is with the shared bram yellow block. I have used this block previously. It never had any such problems before. Any suggestions? Thanks, Nimish
Re: [casper] Problem using shared bram/snap blocks for Roach 2
There was a recent fix to the libraries to enable hundreds of registers. Which library are you using? Jason On 11 Aug 2012, at 14:53, Nimish Sane wrote: Hi Danny, Yes, I am using as many bits as possible in software registers and slicing individual fields in it. Thanks, Nimish On Sat, Aug 11, 2012 at 5:51 PM, Danny Price danny.pr...@astro.ox.ac.uk wrote: Hi Nimish Are you fully using every bit of the 32-bit registers? If not, you could for example consider using a single 32-bit register as four 8-bit registers: you would just need to slice the upper, middle, and lower bits off the 32-bit register in 8-bit chunks. Equally, one register could house 32 booleans, if you slice each bit individually. Cheers Danny On 11/08/2012 22:34, Nimish Sane wrote: Hi Mark, Using ADC clock. But the error I was mentioning (specifically the log that I sent) has been resolved. However, the problem still remains with my main design. I believe it has to do with number of software registers and shared brams in the design. I am routinely exceeding this limit and the only way I can get things work is by somehow reducing the number of software registers or shared brams in the design. It is more of trial and error. Is there any way to figure out that limit or ways to avoid that? Thanks, Nimish On Sat, Aug 11, 2012 at 4:00 PM, Mark Wagner mwag...@ssl.berkeley.edu wrote: Hi Nimish, How are you clocking your design? Mark On Sat, Aug 11, 2012 at 6:48 AM, Nimish Sane nimishs...@gmail.com wrote: Hi all, I am trying to compile a design with few snap blocks, specifically snap64 blocks for Roach 2 — ska-sa software library, Xilinx 11.4 tools, Linux, Roach 2, KatADC, 150MHz FPGA clock. The compilation fails with platgen errors. I tried compiling a design with just a snap64 block in it. Please find the log attached to this email that shows these errors. I can confirm that the problem is with the shared bram yellow block. I have used this block previously. It never had any such problems before. Any suggestions? Thanks, Nimish
Re: [casper] Problem using shared bram/snap blocks for Roach 2
Hi Jason, I have been able to compile with reduced number of software registers and shared brams. I will try adding back those registers and compiling with the latest versions later. Thanks, Nimish On Sun, Aug 12, 2012 at 12:36 AM, Nimish Sane nimishs...@gmail.com wrote: I am using the ska-sa github. I had not updated it for few weeks, but I just updated it yesterday and I am now trying with the latest versions. Do you know how recent was this fix? Thanks, Nimish On Sun, Aug 12, 2012 at 12:32 AM, Jason Manley jman...@ska.ac.za wrote: There was a recent fix to the libraries to enable hundreds of registers. Which library are you using? Jason On 11 Aug 2012, at 14:53, Nimish Sane wrote: Hi Danny, Yes, I am using as many bits as possible in software registers and slicing individual fields in it. Thanks, Nimish On Sat, Aug 11, 2012 at 5:51 PM, Danny Price danny.pr...@astro.ox.ac.uk wrote: Hi Nimish Are you fully using every bit of the 32-bit registers? If not, you could for example consider using a single 32-bit register as four 8-bit registers: you would just need to slice the upper, middle, and lower bits off the 32-bit register in 8-bit chunks. Equally, one register could house 32 booleans, if you slice each bit individually. Cheers Danny On 11/08/2012 22:34, Nimish Sane wrote: Hi Mark, Using ADC clock. But the error I was mentioning (specifically the log that I sent) has been resolved. However, the problem still remains with my main design. I believe it has to do with number of software registers and shared brams in the design. I am routinely exceeding this limit and the only way I can get things work is by somehow reducing the number of software registers or shared brams in the design. It is more of trial and error. Is there any way to figure out that limit or ways to avoid that? Thanks, Nimish On Sat, Aug 11, 2012 at 4:00 PM, Mark Wagner mwag...@ssl.berkeley.edu wrote: Hi Nimish, How are you clocking your design? Mark On Sat, Aug 11, 2012 at 6:48 AM, Nimish Sane nimishs...@gmail.com wrote: Hi all, I am trying to compile a design with few snap blocks, specifically snap64 blocks for Roach 2 — ska-sa software library, Xilinx 11.4 tools, Linux, Roach 2, KatADC, 150MHz FPGA clock. The compilation fails with platgen errors. I tried compiling a design with just a snap64 block in it. Please find the log attached to this email that shows these errors. I can confirm that the problem is with the shared bram yellow block. I have used this block previously. It never had any such problems before. Any suggestions? Thanks, Nimish
