Hi Glenn,
You probably already fixed up your ibobs XAUI connectors, but if not you
might want to check out
http://casper.berkeley.edu/papers/Science_Safety_001.pdf Although I don¹t
know why a problem caused by this would only manifest itself when OOB data
is sent.
Regards,
Andrew
On 8/19/08
Please do not check the full implementation and BEE_XPS_base
directories into the CASPER SVN for your projects. You should not need
to check in more than the .mdl and .bit or .bof files.
It creates a bloated repository full of unnecessary files that nobody
will use.
If you are concerned a
> (I have re-read a prior thread from early May on this topic involving
> John, Matt, Jouko, and Francois, however the sourcing information was
> from 2005, and the applicability of the information to our situation
> was not entirely clear from the conversation. Also perhaps more has
> been learn
Hello,
I think I am seeing some strange XAUI slippage related to the OOB signal
when sending data from an iBOB to a BEE2. It sounds similar to an effect
that was seen at Green Bank.
My iBOB is set up to send 64 bits of data on both XAUIs every other clock
with the FPGA clocked at 250 MHz, so the da
I checked the permissions, and they seem fine, I can manually copy the file.
Perhaps it has to do with cygwin/xygwin somehow?
On Tue, Aug 19, 2008 at 1:03 PM, John Ford wrote:
> >>
> >> Running generate for OS'es, Drivers and Libraries ...
> >> Running generate for lwIP library ...
> >> Generati
Have you seen the recent writeup @ BWRC ?
http://casper.berkeley.edu/memos/cabletestmemo.pdf
For copper cables we, ATA, use WLGore cables
https://consumer.gore.com/webapp/wcs/stores/servlet/ProductDisplay?catalogId=10401&storeId=10401&productId=10852&langId=-1&parent_category_rn=10101
IBN6800-1,
This is my first question to the general list---please be gentle ;)
We have been doing iBOB<->iBOB and iBOB<->BEE2 fast serial
communications using cables made by Fujitsu. Typically we keep the
cable lengths quite short, a typical Fujitsu part number for a 1 m
cable is FCD-ZZ00016, it's s
>>
>> Running generate for OS'es, Drivers and Libraries ...
>> Running generate for lwIP library ...
>> Generating xemacliteif_g.c ...
>> Generating lwipopts.h file ...
>> ERROR:MDT - lwip () - error copying
>>"./src/contrib/ports/v2pro/netif/xemacliteif_polled.c" to
>>"./src/contrib/ports/
Sorry, I just noticed it is referenced in the mss file which is getting
added by the gen_mss.m function from @xps_lwip. Looking back at version 7.1
I see that this has been the case since then. Is it that the hardware
version is 1.01.a but the driver is version 2.00.a?
Thanks,
Glenn
On Tue, Aug 19
(Replying to the list for the benefit of everyone once the archive is
created.)
I copied the previous version over, and everything went smoothly up until
the CopyFiles part for generating the drivers. It seems to still be copying
the 2.00.a drivers for some reason. I can't find the reference to th
I'm going to remove the reconfigurable blocks from the FFT blocks today.
Glenn
On Tue, Aug 19, 2008 at 9:40 AM, Jason Manley wrote:
> Hey Andrew
>
> Terry, Mark and I were actually chatting about this yesterday.
>
> I think this might be due to the use of the reconfigurable blocks (like
> "delay
Hey Andrew
Terry, Mark and I were actually chatting about this yesterday.
I think this might be due to the use of the reconfigurable blocks
(like "delay"), which lets you select different blocks (between
delay_slr and delay_bram, for example). The problem seems to be when
the mask changes
Hi all
Terry mentioned this problem a while back and it keeps popping up. Not sure
if anyone has any ideas.
Basically, while opening a design or simulating, the following error will
occasionally occur.
Warning: casper_library.mdl, line 18706: Invalid setting in SubSystem
'casper_library/Correlat
13 matches
Mail list logo
