SDR left over issues 7th Dec 2011
2011/12/07 Duan

Abstract

Summarized all the problem and things need to be done for SDR up to now 7th Dec, 2011
and Keep a tracking on the problems and progress.

Open list: add problem you see with SDR to it anytime, we will try to solve it.

List
1. Reloading the SDR firmware got noise.

Situation: Run the complete the process of loading firmware (initializeIF + loadRoachConfigration) will sometimes results in the data received is just noise, instead of frequency tones we send out. Solution+Todo: the output frequency buffer is ok. So the problem is come from select bin or some sync issue. Need to figure this out.
*********************************************************

short version

I thought the delay from QDR is fixed 12 clock cycle, so I use 12 in my original firmware design. And from the data we get, we find there is 40% chance we are getting data just contain noise. And then I put a register to give us ability to change the selection bin system corresponding to the expected delay in the from 10-14. I find when we are not getting data, I change the expected delay from 12 to 11. The data will show up ok. So I think this suggest the problem is from select bin part. And it is possible due to random delay of QDR.

A short version is: we have limited memory space on FPGA 210, 32 bits. If there are 211 BRAM left, all problem can be solved easily. I am currently trying to test the design that is able to calculate the delay from QDR and adjust the select bin part according to calculated delay.

summary and plans later

Summary: I am working on the solution I talked about in the end of method 1(try to measure the delay from QDR and adjust the selection bin automatically). And if that doesn’t work out good. There are some back up plans as well:

plan1: use 192 individual register to store 192 address; we will need to see if the design can fit on FGPA or not.

plan2: We are using a lot of BRAM (we use four 212 BRAMs)for TCP data packing on FPGA. I can try to reduce BRAM for TCP data buffer to release some BRAM.

Plan3: try part 2 in method 2

long version

To selection 192 resonator out of 214 positions, we can either

Method 1:
Store 214 selection index (index number from 0 to 4:0 mean do not select; 1-4 means select from data stream 1-4). We used to do this and store everything in the QDR. To avoid using QDR, I tried to store everything on BRAM(memory on FPGA chip). And I find the minimum memory space we need to use is 211, each address has 32 bits. (for example. If we store number 0-4, we need 3 bits. Each address will contain 10 number, 214/10 will need 211 address; another way is just store 0 or 1 for each data stream. 32 bits will allow us choose 32/4 =8 clock cycle. 214 position will need 214/8=211 BRAM ). However, design with 211 BRAM can not be compiled due to too many BRAM. It seems the maximum memory we can place on the FPGA for now is 210, 32 bits. 211 will result in overflow the FPGA and can not compile the design.

Another thing also could be a problem is the minimum size the BRAM we can access from external computer is 210 address, with each address 32 bit. We can not sub divide it into smaller amount, or even we divide it into 28 for example, when we compile the FPGA, it still consider it 210.

I also just compile a design based on the idea that: we still use QDR to store 214 address. I will send in QDR a known number and wait for that number shows up and its output. That way I will know for sure what is the delay of QDR is. And then compare that delay with delay 12 and 11. If it is 12, we do not need to change anything, if it is 11, it will automatically switch the select bin part corresponding to delay 11. The design compiled without problem, I am still working on test this design and make sure it work as expected and can solve the problem or not.

Method 2:

Store 192 position number we want, and use counter count the 214 positions from 1-214. This way saves memory. But if simply use 1 memory buffer to store 192 addresses, we will face problem like this: there have to be some delay (usually 3 clock cycle) for us to choose next position of 192 address. (FPGA will first compare if address A is equals to counter number or not, if so, it will tell the memory to move to next address B.) This will make us lose ability to choose near-by positions. And since there are 4 parallel output from FFT, if we can not choose near by bins, we are actually loss large amount of ability to drive resonator accurately.

To avoid miss near-by bins, I think we can either present >=2 address at same time or present 3 clock cycle data at same time. :

1. To present 2 address at same time we can use 2 buffer, buffer A contain 192 address we want to pick; buffer B contain 192 address shifted by 1 position. And for each clock cycle, FPGA will know the current address we want to pick and next address we want to pick. But this way we might have to use multiple buffer, and we actually can only have one 210 buffer. So it might not work.

2. Buffer the data to allow 3 cycle of data to present at same clock cycle at same time. This is easy to do in the FPGA. We can just add delay on the data path:
Incoming data Incoming data + 2 delay

•    When we find address A is what we want, we pick A , select data from
“incoming data” and move to next position in the selection buffer(which takes 3 clock cycle), and select data from “incoming data+2 delay”. The only issue is we need to avoid keep delaying the data. I haven’t work on this direction yet, this could be a future solution if other doesn’t work out.

***********************************end ******************

•    2. Reloading loadRoachConfigration.m without re-initializeIF get reduced RF output signal level. ==

Situation: reloading loadRoachConfigration.m might alter some control register on IF board and change the IF board setting everytime. We need to try resetting IF board switch or attenuation setting.

•    3. KST is not working on Columbo with new data. This has been fixed.
Need to modify the C++ patch for the KST.

•    4. IF board attenuator setting in DAQ
The set IF board attenuation code is giving double the attenuation we asked it for. There is somewhere in code has some inconsistency about total attenuation and attenuation for each attenuator (we have two attenuation on the output path).

•    5. DAQ buffer generation code need to be changed to give swapped buffers I and Q. So we don’t need to swap cable from IF board to ADC board.
The reason for this is totally understood, it is just an issue with DAC-generated tone at A Hz, is it going to end up at (LO + A)Hz or (LO + A – Nyquist_freq) Hz.

•    6. Update netboot for all ROACHes to take into account all the changed we made for the tcp server. Done.

•    7. In the initializeIF code, the roachkill function is hard coded to program cucaracha7 for now, not for any boardID. Fixed.

•    8. we use matlab to call python all the time, when there is error in python, matlab won't able to reflect those error (or transfer those error ) into matlab, so we won't be able to monitor is there is error in when we load the system. The only way to deal with this is to pipe the python output into output files, which can then be checked automatically. This has been implemented in the multiboard routines for initializing the IFs, loading the roach configurations, and setting the LO.

•    9. Roachsync running on Roach's PPC used to sync to internet to get accurate time of day. Now each Roach doesn't have any internet connection (they all internally connect to DAQ computer), will need to modify the roachsync function to get time of day from DAQ PC.

•    10. Sometimes, ROACH's filessystem seems to mount as not executable (or maybe due to filesystem broken). It doesn't happen often, and reboot or chmod will solve the problem. But need to figure out the reason.

11. The netCDF file SDR current outputting is not working with Jack's data analysis pipeline, we will need to change back to the old data format to be able to work with IDL. We have changed back to netCDF classic format, rather than netCDF-4.