SDR left over issues 7th Dec 2011
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.
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.
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
To selection 192 resonator out of 214 positions, we can either
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
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
• 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.
• 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.