All,
Randy and I are closing in one completing phase 1 of our pulsar
machine. We have two iBOB samplers streaming samples over XAUI into
the BEE2's FPGA1 and FPGA3, where the pfb fft take place. Then
we're using the inter-chip connections to pass the FFT bin values
over to FPGA2 where the
All,
As some of you may know, Randy I have been working on getting
reliable data transmission across the inter-chip connections on the
BEE2. We managed to get that working reliably and have moved on to
the next problem that has reared its ugly head.
Once we got back to the point of
remember right now).
Perhaps you can solve your problem as simply as not allowing reads from the
XAUI until after say 32 clocks from when the iBOB begins transmitting,
to allow the buffers to fill up a little.
Glenn
On 7/21/08, Jason Ray j...@nrao.edu wrote:
All,
As some of you may know, Randy I
On Fri, 28 Aug 2009, Richard Armstrong wrote:
This week I've been trying to clock the BEE2 off an IBOB-generated clock
with an LVTTL-to-LVPECL clock driver. I changed the BEE2 design and changed
a jumper to select user-clock on the BEE2 board. Unfortunately, this doesn't
seem to help much
At 09:16 PM 9/29/2010, Suraj Gowda wrote:
At 3 Gs/s, the FPGA clock rate is 187.5 MHz. Is this in range of the
DRAM clock?
Maybe you could describe what the output is and/or how it's incorrect?
It's been a while since I attempted to use that interface.
We had a 200 MHz sine wave input to the
Thanks Dan!
Jason
At 11:13 AM 12/17/2010, Dan Werthimer wrote:
hi jason,
i'm forwarding your request to dan burke,
who designed the bee2 enclosure and power supply.
dan b. might have a drawing that shows the bee2 board
mounting holes???
best,
dan
On 12/17/2010 7:52 AM, Jason Ray wrote
the
linear dimension tool. I have a new
machine and don't have Allegro up yet,
but will be glad to walk through it if
Jason has a working setup.
DAN
On Mon, 20 Dec 2010 10:59:01 -0500, Jason Ray j...@nrao.edu wrote:
Thanks Dan!
Jason
At 11:13 AM 12/17/2010, Dan Werthimer wrote:
hi jason,
i'm
All,
I recently tried to use tutorial 2 to do some troubleshooting of
10GbE ports on a couple roaches. I found a few inconsistencies in
the file links that I thought I would point out.
Mainly, there seems to be several combinations of the bof file, py
file, and mdl file that work directly.
, the cause was traced to the +1 volt supply MOSFET switch.
Replacing that mosfet fixed both roaches. Kudos to Jason Ray for finding
the problem originally.
John
batch. Maybe some bad parts or ESD damage?
John
Thanks,
Glenn
On Tue, Jun 19, 2012 at 9:52 AM, Jason Ray j...@nrao.edu wrote:
The first time I was troubleshooting this problem, I did see a fault on
the
1V supply with roach_monitor.py. I didn't check roach_monitor.py on the
second roach
All,
Does anyone have a mechanical drawing of the roach 2 board? Mainly
the board dimensions and mounting hole locations.
I'll also need to know the approximate overall height of the board
assembly with the tallest mezzanine board (CX4 or SFP+?) installed.
Thanks in advance!
Jason
just fits in a 1U case, with about 1mm
to spare above the DRAM DIMM after it's mounted on standoffs.
Jason
On 23 Aug 2012, at 16:37, Jason Ray wrote:
All,
Does anyone have a mechanical drawing of the roach 2
board? Mainly the board dimensions and mounting hole locations.
I'll also need
On Tue, 25 Jun 2013, David Saroff wrote:
Casper fellow-travelers,
When I run casper_xps from the matlab command prompt a lot happens that
produces a .bof file that works. I'm curious about the EDK/ISE reports,
timing in particular. The Casper XPS window with the big Run XPS button,
has a View
All,
Occasionally I've noticed (maybe a handful of times over the past few
months) that progdev will fail with our roach2 boards. After working
fine for long periods, it will fail to program out of nowhere and the
only fix is to reboot the roach2.
I copied/pasted the python error dialog
Hi Rich,
So far we haven't had any trouble with the SFP+ boards (8 total) in
our vegas machine. I guess they've been powered up continuously and
in use for around a year now.
We were concerned about how warm the PHY chips run so I spent a
little time looking into it. The datasheet says:
data and measurements.
were your temperature measurements in the
standard roach2 enclosure?
i think the VEGAS SFP+ PHY's are mounted
differently and have different cooling than the
standard roach2 enclosure.
best wishes,
dan
On Fri, Dec 6, 2013 at 9:53 AM, Jason Ray
mailto:j...@nrao.eduj
All,
I'm currently troubleshooting a bad roach1 board, and I thought I'd ask
for some advice about the problems I'm seeing.
The board seems to be bricked. It doesn't do anything on power up. So,
I attached our wiggler and it appears to successfully run the macro
loadram_rinit_auto.mac.
Hi Alec,
I'm using a windows XP laptop with hyperterminal. This is the same
setup I've used in the past for doing the xmodem transfer.
Maybe I should gather up another machine and try it...?
Thanks,
Jason
On 3/20/2014 11:26 AM, Alec Rust wrote:
Hi Jason, this is a tricky problem! What
Hi Richard,
Do you have the USB cable connected a terminal program running, where
you can watch it boot up?
If so, once you hit any key to interrupt the boot, you type:
setenv bootcmd run netboot
saveenv
That should do it.
Jason
On Fri, 21 Mar 2014, Richard Black wrote:
Hi all,
I'm
All,
We have a student (Devin Cody, who just signed up for the casper list)
working at NRAO-Green Bank this summer and he is working on implementing
the offset/gain/phase, INL, etc calibration routines for the ADC083000.
There's been quite a bit of work on these calibrations for the ADC5G,
Hi Sara,
This sounds like a failure mode with the roach in which the 1V supply is
disabled, due to a failed mosfet (Q13) on the board. We've seen this
problem several times and can repair them in Green Bank. We repaired
this exact problem on one of the mustang 1.5 roaches for Justus about a
All,
We're having an issue with a roach1 in GB where we can't access the xport.
It doesn't seem to respond using a web browser to the default IP of
192.168.20.4. We also had our sys admin add an entry for its MAC address
to our DHCP server and we still cannot communicate with it.
As far as
f I am right if I say I think that the roach might be bricked?
>
> Thanks for all the help
>
> Heystek
>
> On Wed, Mar 22, 2017 at 9:23 PM, Jason Ray <j...@nrao.edu
<mailto:j...@nrao.edu>> wrote:
> Heyst
Hi Glenn,
A while back, I repaired a roach2 problem that had similar symptoms.
Its probably not terribly likely that yours has the same problem, but I
thought I'd share in case...
The short story is that a capacitor (C163) failed and I could measure
~220ohms across it. This particular cap
John,
We use these picoPSU modules exclusively for powering our roach2
systems. They have 120W capacity and are powered from +12VDC.
http://www.mini-box.com/s.nl/it.A/id.417/.f
So far they've been great.
Good luck!
Jason
On 12/8/2017 1:18 PM, John D. Sahr wrote:
I have an application
Hi All,
Does anyone know what the fault led and/or shutdown thresholds are for
the roach2 board?
I found this table for roach1:
https://casper.berkeley.edu/wiki/Roach_monitor_and_management_subsystem
But I can't find anything similar for roach2.
Also, does anyone know if there's a log kept
Hi All,
I have a question about our simulink libraries at GBO. The backstory is
that we installed a version (casper_astro_soak_test for Xilinx 14.7) of
the casper tools many years ago during VEGAS development. It has always
worked fine until sometime in the past year or so, I can't seem to
023, 06:02 Jason Ray wrote:
Hi All,
I have a question about our simulink libraries at GBO. The
backstory is
that we installed a version (casper_astro_soak_test for Xilinx
14.7) of
the casper tools many years ago during VEGAS development. It has
always
worked fine unti
28 matches
Mail list logo
