Hi Kelvin, I'll be practicing the test procedure here, with working boards, to ensure I know how things should work and then I can visit your lab again to walk you thru it.
Matt On Fri, 8 Apr 2011, Kelvin Digicom wrote:
David, Since Matt was here yesterday and I was just trying to see if he can help me answer the question. He was so kind enough to post the question to the group for me, thanks Matt. We have 2 Roaches in here that failed at the QDR. They have different failures and I'm listing them so you can take a look. First Roach : When running step 10, it reported QDR 0 PHY calibration filure. Second Roach : At step 10, the error message is like this : dram transfer test completed successfully [72 bit device] QDR memory check failed at address: 0x8000 write data: 0:1230 1:1231 2:1232 3:1233 read data: 0:1231 1:1231 2:1232 3:1233 xor'ed: 0:0001 1:0000 2:0000 3:0000 fail mask: 0001 qdr1 transfer test completed successfully it also reported a QDR 0 failure in the end. Since we don't know how to creat the environment you mentioned, the Roach testing machine is what we are using. Can you give us a simplfied procedure that we can follow using our existing equipment? Otherwise, I'll try to replace the QRD parts and retest them. Thank you very much. Kelvin. --- On Fri, 4/8/11, Matt Dexter <[email protected]> wrote: From: Matt Dexter <[email protected]> Subject: Re: [casper] Roach 1: QDR to reference designator mapping To: "David George" <[email protected]> Cc: "casper" <[email protected]>, "Kelvin" <[email protected]> Date: Friday, April 8, 2011, 5:00 PM Thanks David! I'm not sure if it is cablibration that is failing or not. The FPGA self test reports 1 of the QDRs is bad. I'll think I'll be able to try out your software calbration but it will take me a day or two. Certainly won't replace the IC until we first check this out. Thanks again, Matt On Fri, 8 Apr 2011, David George wrote: > Hi Matt. > > I have also checked and I agree with your assessment. > > What is the issue you are seeing? Is calibration failing? > > I have some stuff which performs software calibration of the QDRs. > This may help diagnose the issue before taking action. If you can get > the board connected to an environment where you can run a > tcpborphserver python script you could use this stuff. > > I have attached the bof file which can be used to test soft > calibration and the accompanying python script. > > Running the script will give you something like this for a working board: > > progok > qdr0: > 0: 111111111111111100111111111111111111111111100011111111111111111 > 1: 111111111111111100111111111111111111111111000111111111111111111 > 2: 111111111111111100111111111111111111111111000011111111111111111 > 3: 111111111111111100111111111111111111111111100011111111111111111 > 4: 111111111111111100111111111111111111111111100001111111111111111 > 5: 111111111111111100011111111111111111111111100011111111111111111 > 6: 111111111111111000011111111111111111111111000011111111111111111 > 7: 111111111111111100011111111111111111111111100001111111111111111 > 8: 111111111111111100011111111111111111111111100001111111111111111 > 9: 111111111111111000011111111111111111111111100011111111111111111 > 10:111111111111111100011111111111111111111111000011111111111111111 > 11:111111111111111100011111111111111111111111100001111111111111111 > 12:111111111111111100011111111111111111111111000001111111111111111 > 13:111111111111111100111111111111111111111111000011111111111111111 > 14:111111111111111100011111111111111111111111100001111111111111111 > 15:111111111111111100011111111111111111111111000001111111111111111 > 16:111111111111111100011111111111111111111111110001111111111111111 > 17:111111111111111100011111111111111111111111100001111111111111111 > qdr1: > 0: 011111111111111111111111000011111111111111111111111000011111111 > 1: 111111111111111111111100000111111111111111111111110000111111111 > 2: 111111111111111111111110000111111111111111111111100001111111111 > 3: 011111111111111111111111000111111111111111111111100000111111111 > 4: 111111111111111111111100000111111111111111111111100000111111111 > 5: 111111111111111111111100001111111111111111111111000001111111111 > 6: 111111111111111111111100001111111111111111111111100011111111111 > 7: 111111111111111111111110000111111111111111111111110000011111111 > 8: 111111111111111111111110000011111111111111111111110000011111111 > 9: 111111111111111111111110000111111111111111111111100000011111111 > 10:111111111111111111111110000111111111111111111111100000111111111 > 11:011111111111111111111110000011111111111111111111110000011111111 > 12:011111111111111111111111000011111111111111111111110000001111111 > 13:111111111111111111111100001111111111111111111111100000111111111 > 14:011111111111111111111110000011111111111111111111110000111111111 > 15:001111111111111111111111000001111111111111111111111000011111111 > 16:011111111111111111111111000001111111111111111111111000011111111 > 17:011111111111111111111110000011111111111111111111110000001111111 > > The above graphs represent each data line for each QDR sampled at all > the possible IO delays when outputting continuous alternating 1's and > 0's. In the graph the '1's represent where valid data is sampled and > the '0's where unstable or invalid values are sampled ie the data is > sampled on the edge. > > It might just be easier to remove the offending chip, but running this > stuff may provide a little insight into what is causing the issue. > > Cheers, > David > > > -- > David George > Karoo Array Telescope > Tel: +27 11 442-2434 > Email: [email protected] >
