seconding glenn, the 1 PPS pulse should be 0 to +3 volts when terminated in 50 ohms. (when connected to the roach board). (that's 0 to 5 or 6 volts when not terminated). the 1 PPS pulse should not go negative.
i suggest a pulse width of 1 uS (not 10 ms). best wishes, dan On Fri, Nov 7, 2014 at 9:12 AM, Richard Black <aeldstes...@gmail.com> wrote: > Dan, > > We aren't using a square wave. It's a pulse function, but that pulse's shape > can be easily described as a very thin square pulse. > > However, you are saying that the pulse is high for only 1 us? That is much > shorter than what we are doing. I'll see if I can twiddle that down. > > Thanks, > > Richard Black > > On Fri, Nov 7, 2014 at 10:09 AM, Dan Werthimer <d...@ssl.berkeley.edu> > wrote: >> >> you mentioned your 1 PPS is a square wave. >> that's different from everyone else's 1 PPS: >> >> standard 1 PPS systems output a pulse that is >> high for about 1 uS. (extremely low duty cycle). >> >> i don't know if a square wave could be a problem - my guess >> is that the correlator design uses an edge detection block, >> so is only sensitive to edges, not levels, but it might >> be worth investigating. >> >> best wishes, >> >> dan >> >> >> On Fri, Nov 7, 2014 at 9:03 AM, Richard Black <aeldstes...@gmail.com> >> wrote: >> > Hi all, >> > >> > Haven't heard anything for a while, so I thought I would add some more >> > detail about our system setup to see if it might shed some light on the >> > problem: >> > >> > 1 PPS Signal >> > ----------------------------------------- >> > Square pulse >> > Frequency: 1 Hz >> > Amplitude: 3 Vpp >> > Offset: 0 V >> > Width: 10 ms >> > Edge Time: 5 ns >> > >> > ADC Clock >> > ----------------------------------------- >> > CW Tone >> > Frequency: 200 MHz >> > Power: -9 dBm >> > >> > For David, are there any red flags with our UBoot version or ROACH CPLD? >> > Here they are again for reference: >> > >> > From serial interface after ROACH reboot >> > ================== >> > U-Boot 2011.06-rc2-00000-g2694c9d-dirty (Dec 04 2013 - 20:58:06) >> > ... >> > CPLD: 2.1 >> > ================== >> > >> > Thanks! >> > >> > >> > Richard Black >> > >> > On Tue, Nov 4, 2014 at 12:05 PM, Richard Black <aeldstes...@gmail.com> >> > wrote: >> >> >> >> Hi David, >> >> >> >> Comments below: >> >> >> >> Richard Black >> >> >> >> On Mon, Nov 3, 2014 at 3:51 PM, David MacMahon >> >> <dav...@astro.berkeley.edu> >> >> wrote: >> >>> >> >>> Hi, Richard, >> >>> >> >>> On Nov 3, 2014, at 11:47 AM, Richard Black wrote: >> >>> >> >>> > So, it's been a little while now, but not much has changed yet. >> >>> > We've >> >>> > gotten Chipscope working, and, so far, there aren't any red flags >> >>> > with the >> >>> > FPGA firmware 10-GbE control signals. >> >>> >> >>> That's good to know, although maybe in some way it would have been >> >>> nice >> >>> if you had found some red flags. >> >>> >> >>> > We also confirmed that the bitstream we are using is in fact >> >>> > roach2_fengine_2013_Oct_14_1756.bof.gz, so that is unfortunately not >> >>> > the >> >>> > problem. >> >>> >> >>> At least you are using a known good BOF file, so that eliminates a >> >>> source >> >>> of potential errors. >> >>> >> >>> > I also took a look at the ROACH2 PPC setup: we pulled from the .git >> >>> > repository on February 12, 2014 (commit number = >> >>> > e14df9016c3b7ccba62cc6d0cae05405f4929c94). There haven't been any >> >>> > changes to >> >>> > that repository since August 2013, so unless the SKA-SA ROACH-2s are >> >>> > using a >> >>> > pull from before then, I don't think that is our issue. >> >>> >> >>> We use our own homegrown NFS root filesystem for the ROACH2s, so I >> >>> can't >> >>> comment on the status of the one you refer to >> >>> (https://github.com/ska-sa/roach2_nfs_uboot.git). I am more >> >>> interested in >> >>> the U-Boot version you have (see >> >>> https://github.com/ska-sa/roach2_uboot.git) >> >>> and which version of the ROACH2 CPLD image you are using (not sure >> >>> where to >> >>> get this). I think these are unlikely to be problematic, but we've >> >>> already >> >>> checked all the likely problems. >> >> >> >> >> >> When I rebooted the ROACH-2, I got the following header for U-Boot: >> >> >> >> U-Boot 2011.06-rc2-00000-g2694c9d-dirty (Dec 04 2013 - 20:58:06) >> >> ... >> >> CPLD: 2.1 >> >> >> >> Hope this is informative. >> >> >> >> >> >>> >> >>> >> >>> > We also tried out Jason Manley's suggestion of delaying the enabling >> >>> > of >> >>> > the 10-GbE cores to ensure that the sync pulse propagated through >> >>> > the entire >> >>> > system before buffering up data, but the problem persisted. >> >>> >> >>> Do you have an external 1 PPS sync pulse connected or have you tried >> >>> the >> >>> latest rb-papergpu software that supports a software-generated "sync"? >> >>> The >> >>> paper_feng_init.rb script already disables the data flow to the 10 GbE >> >>> cores >> >>> until the sync pulse has propagated through and the cores have been >> >>> taken >> >>> out of reset. >> >>> >> >> >> >> We are using an external 1 PPS sync pulse. However, we are certain that >> >> it's set up correctly. Although, this could just be me grasping at >> >> straws >> >> since nothing else seems to solve the problem. How would we go about >> >> setting >> >> up the software-generated pulse? >> >> >> >>> >> >>> Does the latest rb-papergpu code show that the ADC clocks (MMCMs) are >> >>> locked? Does it estimate the clock frequency correctly? Does >> >>> adc16_dump_chans.rb show samples that correspond correctly to the >> >>> analog >> >>> inputs (e.g. a CW tone)? >> >> >> >> >> >> I've attached an image of the output from xtor_up.sh -f 1 with the >> >> latest >> >> rb-papergpu code. Nothing significant to note: the clock reads ~200 >> >> MHz. >> >> >> >> I've also attached an image of the output from adc16_dump_chans.rb, >> >> where >> >> A1 has a CW tone with a 10-MHz 40-V emf signal. You can see the >> >> oscillations >> >> in the first column and noise everywhere else. >> >> >> >>> >> >>> >> >>> > Just to rule it out, I double-checked (or more accurately >> >>> > triple-checked) the U72 part, and, sure enough, it is the correct >> >>> > oscillator, model number EEG-2121. >> >>> >> >>> Does it have the "L" suffix on the "100.000L" frequency part of the >> >>> chip >> >>> markings? >> >>> >> >> >> >> Yes, it does. >> >> >> >>> >> >>> On a related note, as I sent off-list to you and Peter earlier today: >> >>> The fact that the Peter can send small packets at 200 MHz without >> >>> overflow, >> >>> but large packets give overflow is very interesting and puzzling. I >> >>> assume >> >>> that the smaller packets are just fewer channels of the same length >> >>> spectrum >> >>> and that the number of packets per second remains the same (I think we >> >>> discussed this previously). In that case, the small packets reduce >> >>> the data >> >>> rate, which suggests that the 156.25 MHz "xaui_ref_clk" clock is maybe >> >>> not >> >>> really 156.25 MHz but something somewhat slower. This clock is driven >> >>> by >> >>> the oscillator at U56 and the clock splitter at U54 (see attached >> >>> schematic >> >>> snippet). Can you please inspect those parts on your board(s)? I >> >>> will be >> >>> able to inspect a ROACH2 this afternoon and report what I have on a >> >>> known >> >>> working system. >> >>> >> >>> On one of our ROACH2s U56 is labeled like this: >> >>> >> >>> EEG-2121 >> >>> 156.250L >> >>> OGPN1Z5C >> >>> >> >>> Again, note the "L" suffix. I think that signifies "LVDS", which is >> >>> what >> >>> is expected/required for the ROACH2. That's very important. I am not >> >>> 100% >> >>> sure about my transcription of the third line, it could have typos. >> >>> >> >> >> >> U56 is labeled >> >> EEG-2121 >> >> 156.250L >> >> >> >> And, as a precaution, I double checked U72, and it is labeled >> >> EEG-2121 >> >> 100.000L >> >> >> >>> >> >>> > There is another possibility, albeit an unlikely problem: we >> >>> > currently >> >>> > have the ROACH-2 board booting off another PC (i.e. not the same PC >> >>> > that the >> >>> > ruby control scripts are running on). I can't imagine that this is >> >>> > the >> >>> > problem, but I'm planning on trying to consolidate the NFS and ruby >> >>> > scripts >> >>> > onto a single PC to rule it out. >> >>> >> >>> The scripts communicate with the ROACH2 over the network via KATCP. >> >>> There is no requirement that the scripts be running on the same server >> >>> that >> >>> is providing the NFS root filesystem to the ROACH2s. >> >>> >> >> >> >> That's what I figured, but, again, I'm grasping at straws. >> >> >> >>> >> >>> > So I suppose at this point, my questions are: >> >>> > >> >>> > (1) What version of the roach2_nfs_uboot .git repository are SKA-SA >> >>> > using? >> >>> >> >>> I don't know. >> >>> >> >>> > (2) Is SKA-SA using the same PCs for ROACH-2 net boots and file >> >>> > systems >> >>> > as the ruby control scripts? >> >>> >> >>> I doubt SKA-SA is using ruby, but as stated above the ruby scripts can >> >>> be >> >>> run on any system that can reach the ROACH2 via KATCP. >> >>> >> >>> > (3) Are there any additional steps that need to be taken when >> >>> > installing the Quad SFP+ mezzanine cards onto the ROACH-2 board? Are >> >>> > there >> >>> > potentially some drivers or configuration steps that are needed to >> >>> > make sure >> >>> > they function properly? As I recall, when we got the boards, we >> >>> > didn't do >> >>> > anything special with the cards outside of simply plugging them in. >> >>> >> >>> Just plugging them in is all that is necessary. There is a slight >> >>> complication in that the standoffs might not be exactly the right >> >>> height and >> >>> some washers need to be added to keep the mezzanine card parallel to >> >>> the >> >>> main board so that the mezzanine connector mates securely. It's also >> >>> important to make sure the connectors are properly seated vis a vis >> >>> the >> >>> shield which I am told can be a little "flappy". >> >>> >> >>> Hope this helps, >> >>> Dave >> >>> >> >> >> >> Thanks! >> >> Richard >> >> >> > > >
