Re: [casper] xilinx glibc issues
It looks like rolling back to the rebuilt glibc 2.5-65 rpms worked. It's too early to tell if I broke anything on our system, but everything, ISE 11 included, appears to be in good working order. What system damage lurks unseen, only time will tell... The rpms for RHEL5 (compiled on a Scientific Linux 5.8 machine) are available over http at 131.215.193.68 (soon to be betacage.caltech.edu once our hostmaster group gets back to me). The src.rpm file is there too, for anyone who wants it; it's easily found elsewhere though by querying google for glibc 2.5-65. All I did to install them is dump them all to the same directory and run rpm -Uvh --oldpackage *.rpm In the event anyone ever actually uses this (what with people moving to ISE 13) they should let me know if I left anything out. Lastly, I gave up on trying to link to compat-glibc. I decided I am far too cowardly and inexperienced a linux user to interfere with the dynamic linker... -Alex On Fri, Aug 10, 2012 at 1:38 PM, John Ford jf...@nrao.edu wrote: I'm not sure how to force a dynamically linked program to use compat-glibc instead of the default glibc...maybe some convoluted chroot trickery? I think that's the purpose of the compat-glibc package. I think you tell it with some environment variable. The wonders of dynamic linking... In the meantime, I found an old source rpm for glibc 2.5-65. As soon as a I finish building and installing it I'll let everyone know how it goes. If it works, I'll post an ftp link to the rebuilt rpm's. Very cool. John -Alex On Fri, Aug 10, 2012 at 9:00 AM, John Ford jf...@nrao.edu wrote: I've been trying to get all the mssge toolflow stuff running on a new SL 5.8 machine. Everything works except that compilation fails at xst synthesis for even the simplest designs with a lot of complaints from glibc. A while back there was a thread describing some very similar issues. I believe it was concluded that ISE 11 doesn't work with newer versions of glibc. The NRAO wiki seems to agree, saying that the latest glibc that works is 2.5-65 (see https://safe.nrao.edu/wiki/bin/view/Ccs/CasperReferenceGuide) The trouble is, the oldest glibc package I can find anywhere is 2.5-81, which I tried to no avail. Does anyone have any advice for getting all the requisite 2.5-65 rpms or building release 65? One of our linux folks wondered if you tried the compat-glibc package? I think it allows you to install multiple glibc versions at once. John Thanks, Alex
[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