Re: [casper] Roach-2 crashing fix

[John Ford]

> So I confess to relying on third parties for this information, but isn't
> the board populated with 1Gb RAM after all ? Would the crash be trigged by
> a kernel memory layout of 3Gb+1Gb rather than  2Gb+2Gb ?

Certainly if the kernel thinks the layout of memory isn't what it really
is it could crash.  We'll look into this a bit more.

>
> Have you tried the kernel from 9 months ago at github
> ska-sa/roach2_nfs_uboot ?

No, we haven't, as far as I know.

John

>
> regards
>
> marc
>
>
> On Wed, Jun 24, 2015 at 11:49 PM, John Ford  wrote:
>
>> Hi all.
>>
>> We were having problems with multiple sequentail progdev calls failing
>> on
>> our ROACH-2 systems.  We were testing multiple bof files in a loop, and
>> the roach would fall over and crash completely, and after the kernel
>> panic, it would reboot itself.
>>
>> After a great deal of concentrated debugging effort this afternoon by
>> Jack, David, Justin, Ryan, Arindam, Randy, and me, the cause of the
>> crashing upon multiple progdev calls was found.  It turned out to have
>> nothing to do with programming the chip, rather it was a problem with
>> memory allocation by the operating system.  Jack found that problem
>> could
>> also be caused by allocating a huge array in Python, using lots of
>> memory.
>>
>> The problem was caused by the kernel thinking that the ROACH has 768 MB
>> of
>> memory on board, when in fact it has only 512 MB.  The fix is to pass
>> the
>> real amount of memory to the kernel in the bootargs.  the systems have
>> been mostly working for a long time (Years!), so you may want to check
>> that your systems know in fact how much memory they have.  If you start
>> up
>> top you can see what it thinks, or look in /proc/meminfo.
>>
>> John
>>
>>
>>
>>
>>
>>
>

Re: [casper] ROACH2 one_gbe block losing data on reception

[John Ford]

> Hi Glenn,
>
> Everything seems to be in order, however if there was signal integrity
> issues the MAC (temac) would report bad frames due to CRC failure (the CRC
> is calculated over the entire Ethernet frame).
>
> Just another sanity check would be to send this data to another PC and
> just
> confirm that all the packets are received.

Hi Glenn.  Are you actually not receiving all the data?  I wonder if
there's some kind of error in the statistics gathering, i.e. maybe it
strips off one of the headers before counting bytes, etc...

Just a thought...

Another thing is that the PC may be sending them in a bursty fashion,
which makes it imperative that you handle the packet and stick it in a
buffer right away, even though the average data rate is low.  I'm not sure
how to measure that.

John

>
> HK
>
> On Tue, Jul 28, 2015 at 9:10 AM, G Jones  wrote:
>
>> Hi Henno,
>> Thanks for replying. I meant to mention the simulink clock is 250 MHz
>> and
>> the design meets timing. The ultimate goal is loading waveforms into the
>> DRAM since there isn't a CPU DRAM interface for ROACH2 yet, so any speed
>> better than loading via KATCP would be great. But I've tried delays of
>> up
>> to 10 ms between each packet (i.e. down to about 100 KB/s), and am still
>> seeing this behavior. The data loss fraction doesn't seem to improve
>> substantially with reduced data rate. This leads me to suspect some sort
>> of
>> signal integrity issue, but I'm not sure where.
>>
>> Glenn
>> On Jul 28, 2015 12:50 AM, "Henno Kriel"  wrote:
>>
>>> Hi Glen,
>>>
>>> I assume you are running your fabric > 125MHz? What is the data rate
>>> you
>>> are trying to sustain?
>>>
>>> HK
>>>
>>> On Mon, Jul 27, 2015 at 10:06 PM, G Jones 
>>> wrote:
>>>
 Hi,
 I'm experimenting with the one_gbe block on ROACH2. So far data
 transmission looks flawless, I can capture all the bytes I send.
 However,
 receiving data from a computer seems to result in missing data.
 My design is very simple, I have rx_ack tied high, and then counters
 on
 rx_val and the rising edge of rx_eof and also on rx_overrun and
 rx_badframe.

 If I just send a single packet, all looks good, the rx_val counter
 shows
 the number of bytes I sent, and rx_eof shows one packet received. But
 when
 I try to send a sequence of packets, I end up with the rx_val counter
 showing fewer bytes than I sent, by about ~ 0.5-5% depending on the
 exact
 combination of parameters I use in sending packets. Sometimes all the
 ~1024
 packets arrive, as indicated by the rx_eof counter, but other times it
 seems 1-3 are missing.

  I see consistent results whether the packet payload is 1024 bytes,
 4096
 bytes, or 8192 bytes.

 I never see any counts on the rx_overrun or rx_badframe line.

 I am using sendall to send the packets from the host computer, and it
 reports that all bytes are being sent, so I assume it's not dropping
 them
 on the way outbound (plus it seems like it would be weird for the host
 computer to send partial packets).

 I've tried this test with two different network adapters (both
 directly
 connected to the ROACH2 fabric ethernet port, and with various lengths
 of
 CAT 6 ethernet cables.

 Has anyone used the one_gbe block in this way? Am I missing something?

 Thanks,
 Glenn

>>>
>>>
>>>
>>> --
>>> Kind regards,
>>> Henno Kriel
>>>
>>> Manager: Hardware Engineering
>>> SKA South Africa
>>> (p) +27 (0)21 506 7374 (direct)
>>> (m) +27 (0)84 504 5050
>>> web: www.ska.ac.za
>>>
>>
>
>
> --
> Kind regards,
> Henno Kriel
>
> Manager: Hardware Engineering
> SKA South Africa
> (p) +27 (0)21 506 7374 (direct)
> (m) +27 (0)84 504 5050
> web: www.ska.ac.za
>

[casper] ROACH 1 USB

[John Ford]

Hi all.

Does the USB on ROACH 1 work right?  I noticed there's an issue in the
wiki about it where on power-up it does not work right, but on reboot it
does.  Is that still the case?

Does anyone use the USB port for normal use?

Thanks!

John

[casper] shielded monitors

[John Ford]

Hi all.  Recently (sometime in the last year!) I recall hearing about
someone who had successfully shielded flat panel monitors.  Does anyone
here know about this?

Thanks, and sorry if this is noise...  :)

John

Re: [casper] shielded monitors

[John Ford]

Hi all.

This is likely the effort that I remember hearing about!

Thanks, Dan etal.

I would like to see the PDF of this.

John

> Here at the VLA site We have been working on reducing emissions
> from LCD monitors for almost 5 years now and have tried various
> schemes.  We believe we have a fairly good method now to provide
> the attenuation we need for most areas of the VLA site.  Our
> requirements only attenuate by 30 dB for F<3 GHz.  If someone out
> there needs 60 dB as I note in the email trail, our method wouldn't
> help.
>
> We have several detailed documents on how the conversion is made.
> I can email a .pdf copy to anyone interested.
> -Mert
> # * # * # * # * # * # * # * # * # * # * # * # * # * # * # * # *
> * # * # * # * # * # * # * # * # * # * # * # * # * # * # * # * #
> ~~~
>  From the clear, high deserts of central New Mexico, The Land of
> Enchantment, the VLA, and dark, dark, starry, starry nights;
> ~~~
> * # * # * # * # * # * # * # * # * # * # * # * # * # * # * # * #
> # * # * # * # * # * # * # * # * # * # * # * # * # * # * # * # *
>  >>>> One Spectrum <<<< >>>> One Universe <<<<
> Daniel J. ("Mert") Mertely
> National Radio Astronomy Observatory
> Interference Protection Office Engineer
> P.O. Box o
> Socorro,  NM  87801
> (575) 835-7128
> dmert...@nrao.edu
> nrao-...@nrao.edu
>
>
> On 10/22/2015 9:41 AM, jjackson wrote:
>> John/Jason,
>>
>> Dan Mertely here at NRAO in New Mexico has come up with a method of
>> shielding several models of Dell flat panel monitors.  He has a coop
>> currently modifying many dozens of them for use at the VLA site.  These
>> have been tested in our RFI chamber and many are already in use at the
>> VLA.
>>
>> Dan can be reached at dmert...@nrao.edu  or by phone at (575) 835-7128
>>
>> Cheers,
>> Jim
>>
>> Jim Jackson
>> Project/Lead Hardware Engineer
>> Very Large Array(VLA) / Very Long Baseline Array(VLBA) radio telescopes
>> National Radio Astronomy Observatory
>> 1003 Lopezville Rd.
>> P.O. Box O
>> Socorro, NM 87801
>> (575) 835-7132 (W)
>> (575) 835-0158 (H)
>> jjack...@aoc.nrao.edu
>>
>> On 10/22/2015 3:56 AM, Jason Manley wrote:
>>> I'm certainly interested in hearing about this, too. The scanning
>>> frequencies of LCDs are quite bad.
>>>
>>> But I haven't found shielded glass that does much more than 60dB, so
>>> we just put them in big rabbit cages, which gives about the same RF
>>> performance for a fraction of the cost. If you only need a bit of
>>> shielding in one direction, then a simple L-plate is quite effective.
>>>
>>> Jason
>>>
>>>
>>> On 22 Oct 2015, at 11:08, John Ford  wrote:
>>>
>>>> Hi all.  Recently (sometime in the last year!) I recall hearing about
>>>> someone who had successfully shielded flat panel monitors.  Does
>>>> anyone
>>>> here know about this?
>>>>
>>>> Thanks, and sorry if this is noise...  :)
>>>>
>>>> John
>>>>
>>>>
>>>>
>>>
>>>
>

[casper] Multicast on 10 gbe on ROACH-2?

[John Ford]

Hi all.

Does the current ROACH-2 10 gbe yellow block work for multicast transmit?

Does anyone have an example of use of it, if so?

Thanks!

John

Re: [casper] Multicast on 10 gbe on ROACH-2?

[John Ford]

> Hi, John.
>
> I think multicast transmit is easy (just populate the ARP table
> appropriately).  I think multicast receive is also supported with recent
> versions of the 10GbE yellow block.  You could probably check the
> mlib_devel git commit logs for the yellow block code to find clues.
>
> Of course, all that comes with the caveat that I've never actually used
> multicast with the 10 GbE yellow blocks.

Thanks, Dave.  We'll give it a shot!

John

>
> HTH,
> Dave
>
>
>> On Nov 4, 2015, at 08:57, John Ford  wrote:
>>
>> Hi all.
>>
>> Does the current ROACH-2 10 gbe yellow block work for multicast
>> transmit?
>>
>> Does anyone have an example of use of it, if so?
>>
>> Thanks!
>>
>> John
>>
>>
>>
>

Re: [casper] Multicast on 10 gbe on ROACH-2?

[John Ford]

Thanks, All!

John

> Marc is correct. The ARP table is not involved in multicast. The multicast
> MAC is just mapped from the multicast IP.
>
> Wesley New
> South African SKA Project
> +2721 506 7300
> www.ska.ac.za
>
>
>
> On Thu, Nov 5, 2015 at 12:51 PM, Marc Welz  wrote:
>
>> David MacMhaon wrote:
>>
>> >> I think multicast transmit is easy (just populate the ARP table
>> >> appropriately).  I think multicast receive is also supported with
>> recent
>> >> versions of the 10GbE yellow block.  You could probably check the
>> >> mlib_devel git commit logs for the yellow block code to find clues.
>>
>> Not sure if the arp table is involved in this - the destination mac is
>> (should be)
>> generated algorithmically from the destination multicast IP address,
>> though
>> the above might be a unusual workaround.
>>
>> Sending is reasonably straighforward, as there is no control traffic
>> involved.
>> Reception does require a newer romfs/tcpborphserver where we get the
>> kernel
>> to issue IGMP requests on the 10Gbe interfaces, so that the traffic
>> arrives
>> at the particular port.
>>
>> regards
>>
>> marc
>>
>>
>

Re: [casper] startsg issue (Xilinx?)

[John Ford]

> Hi all,
>
> As part of my attempts to narrow down the cause of the FFT problems I'm
> having (well-documented), I'm trying different versions of ISE. I want to
> try most of the 14.x versions plus some rather older versions.
>
> I've installed the versions I want to try but when I change the
> startsg.local file for any version other than 14.7 I get the error
> displayed at the bottom of this email. A similar issue appears on the mail
> archive but this was apparently solved by reinstalling Xilinx ISE. This
> hasn't worked for me. I have also tried deleting the entire /opt/Xilinx
> folder and reinstalling *only* the older version. This also did not work.
> MATLAB still successfully starts when startsg.local is looking for ISE
> 14.7.
>
> This seems a rather silly error and would seem to be something to do with
> the startup scripts, though I can't immediately see any problems. I'd be
> grateful for any suggestions...

The system is sensitive to matlab-xilinx version matching.  Some play
nicely together, and some don't.

I'd try using an earlier version of matlab.  See the casper web page for
suggested combinations.

John
>
> Cheers
> Michael
>
> Error:
>
>
>
> 
>
>Segmentation violation detected at Sun Nov 15 18:51:19 2015
>
> 
>
>
>
> Configuration:
>
>   Crash Decoding : Disabled
>
>   Current Visual : 0x21 (class 4, depth 24)
>
>   Default Encoding   : UTF-8
>
>   GNU C Library  : 2.12 stable
>
>   MATLAB Architecture: glnxa64
>
>   MATLAB Root: /opt/MATLAB/2013a
>
>   MATLAB Version : 8.1.0.604 (R2013a)
>
>   Operating System   : Linux 2.6.32-573.8.1.el6.x86_64 #1 SMP Fri Sep 25
> 19:24:22 EDT 2015 x86_64
>
>   Processor ID   : x86 Family 6 Model 45 Stepping 7, GenuineIntel
>
>   Virtual Machine: Java 1.6.0_17-b04 with Sun Microsystems Inc. Java
> HotSpot(TM) 64-Bit Server VM mixed mode
>
>   Window System  : The X.Org Foundation (1150), display :1.0
>
>
>
> Fault Count: 1
>
>
>
>
>
> Abnormal termination:
>
> Segmentation violation
>
>
>
> Register State (from fault):
>
>   RAX = 7f404af6a8f0  RBX = 0020
>
>   RCX = 7f3bbc744618  RDX = 7f404af6a8e0
>
>   RSP = 7f4036736430  RBP = 7f3bbc8c5408
>
>   RSI = 7f3bbc744642  RDI = 0020
>
>
>
>R8 =    R9 = d501
>
>   R10 = 0045  R11 = 
>
>   R12 = 7f4036736ec0  R13 = 
>
>   R14 =   R15 = 7f3bbc744642
>
>
>
>   RIP = 7f404bd6f904  EFL = 00010206
>
>
>
>CS = 0033   FS =    GS = 
>
>
>
> Stack Trace (from fault):
>
> [  0] 0x7f404bd6f904
> /opt/MATLAB/2013a/bin/glnxa64/../../sys/os/glnxa64/libstdc++.so.6+00669956
> _ZNSsD1Ev+0004
>
> [  1] 0x7f404acecc68
> /opt/MATLAB/2013a/bin/glnxa64/libboost_log_setup.so.1.49.0+01846376
> _ZN5boost9xpressive13match_resultsIN9__gnu_cxx17__normal_iteratorIPKcSsEEED1Ev+0040
>
> [  2] 0x7f3bb4e992a2
> /opt/Xilinx/14.4/ISE_DS/ISE/sysgen/bin/lin64/../../lib/lin64/libsysgen.so+05595810
> _ZN6Sysgen7Utility25getToolVersionFromFilesetERKSs+1698
>
> [  3] 0x7f3bb4e99d92
> /opt/Xilinx/14.4/ISE_DS/ISE/sysgen/bin/lin64/../../lib/lin64/libsysgen.so+05598610
> _ZN6Sysgen7Utility22getVivadoHLSInstallDirEv+0226
>
> [  4] 0x7f3bb58b5957
> /opt/Xilinx/14.4/ISE_DS/ISE/sysgen/bin/lin64/xlmeta.mexa64+00022871
>
> [  5] 0x7f3bb58b7248
> /opt/Xilinx/14.4/ISE_DS/ISE/sysgen/bin/lin64/xlmeta.mexa64+00029256
> mexFunction+0248
>
> [  6] 0x7f4044a58f8a
> /opt/MATLAB/2013a/bin/glnxa64/libmex.so+00110474 mexRunMexFile+0090
>
> [  7] 0x7f4044a550f9
> /opt/MATLAB/2013a/bin/glnxa64/libmex.so+00094457
>
> [  8] 0x7f4044a55f1c
> /opt/MATLAB/2013a/bin/glnxa64/libmex.so+00098076
>
> [  9] 0x7f404d1a06b2
> /opt/MATLAB/2013a/bin/glnxa64/libmwm_dispatcher.so+00562866
> _ZN8Mfh_file11dispatch_fhEiPP11mxArray_tagiS2_+0594
>
> [ 10] 0x7f404cc2abf6
> /opt/MATLAB/2013a/bin/glnxa64/libmwm_interpreter.so+04262902
>
> [ 11] 0x7f404cc2b37a
> /opt/MATLAB/2013a/bin/glnxa64/libmwm_interpreter.so+04264826
>
> [ 12] 0x7f404cc2beea
> /opt/MATLAB/2013a/bin/glnxa64/libmwm_interpreter.so+04267754
>
> [ 13] 0x7f404ca8ebbd
> /opt/MATLAB/2013a/bin/glnxa64/libmwm_interpreter.so+02575293
>
> [ 14] 0x7f404caba412
> /opt/MATLAB/2013a/bin/glnxa64/libmwm_interpreter.so+02753554
>
> [ 15] 0x7f404caba53f
> /opt/MATLAB/2013a/bin/glnxa64/libmwm_interpreter.so+02753855
>
> [ 16] 0x7f404cbd7500
> /opt/MATLAB/2013a/bin/glnxa64/libmwm_interpreter.so+03921152
>
> [ 17] 0x7f404c9f38ac
> /opt/MATLAB/2013a/bin/glnxa64/libmwm_interpreter.so+01939628
>
> [ 18] 0x7f404c9ef993
> /opt/MATLAB/2013a/bin/glnxa64/libmwm_interpreter.so+01923475
>
> [ 19] 0x7f404c9f0797
> /opt/MATLAB/2013a/bin/glnxa64/libmwm_interpreter.so+01927063
>
> [ 20] 0x7f

[casper] 10 gbe on ROACH-2

[John Ford]

Hi all.  I have another question on ROACH-2 ten gbe interfaces.

We really need to be able to set up 2 10.0.{17,18}.X subnets on our system
with the roaches able to send to  either subnet.  I understand this is
currently not possible.

Is it something that could be undertaken?  Hints as to where to start
would be welcome...

John

Re: [casper] 10 gbe on ROACH-2

[John Ford]

> So it depends on exactly what you want - if you are going though one
> (eg default) gateway to both subnets, then this might be feasible, but
> you will need a very new tcpborphserver. Having multiple routes on a
> single interface will require custom fpga work, however.

All of the machines are connected to a single switch, so I think that will
work OK.

>
> It isn't clear how smart a switch you have - in some cases multicast
> may also be an option

This may be the best option.  I think the switch supports it.

Thanks, Marc!

John

>
> regards
>
> marc
>
>
> On Tue, Dec 1, 2015 at 3:46 PM, John Ford  wrote:
>> Hi all.  I have another question on ROACH-2 ten gbe interfaces.
>>
>> We really need to be able to set up 2 10.0.{17,18}.X subnets on our
>> system
>> with the roaches able to send to  either subnet.  I understand this is
>> currently not possible.
>>
>> Is it something that could be undertaken?  Hints as to where to start
>> would be welcome...
>>
>> John
>>
>>
>>
>>
>

Re: [casper] building 300-receiver channel cross-correlator

[John Ford]

> Anyone help?
>
> I'm working in academia and need to build a 300-receiver channel
> single-bit digitiser / cross-correlator with a single frequency channel
> having a bandwidth of 300 MHz, centre frequency ~3 GHz. The single bit
> digitisers sample I&Q giving a total data rate of 180 Gbps and using XOR
> gates to do the cross-correlations, the total computation rate is 54 T XOR
> operations per second. I need to accumulate cross-correlations typically
> for times ranging from 10 ms to a few seconds. The system would comprise
> an array of single bit digitisers linked via a high speed data bus to FPGA
> boards for the cross-correlation/accumulation. I've no skills in board
> design but could probably learn VHDL. I don't have funding to commission a
> design and build but wondered if anyone in this community could advise how
> I should go about building this system at our university.

Hi Neal.  I think the main problem you face is the I/O.  I'm assuming your
sample rate is 300 ms/s?  Clocking the FPGA at 300 MHz is pushing it, but
not completely insane.  The 180 Gbps is above the capacity of the Roach-2,
but maybe R-3 can do it.  There are other off the shelf hardware platforms
you could look at, like pico computing that might have enough I/O.

Dumping the output at 10 ms shouldn't be a problem, as that's only 3.6
Mbps at a 4 bit width, or ~29 Mbps at 32 bits wide.

Do you already have the digitizers?  That's probably a nice bit of
engineering in itself.  There has been some work on using the Xilinx I/O
block bits as single-bit ADCs.  I don't remember the details.

John

>
> Thank you for any help you can provide.
>
> Neil
> "Before acting on this email or opening any attachments you should read
> the Manchester Metropolitan University email disclaimer available on its
> website http://www.mmu.ac.uk/emaildisclaimer "
>

[casper] GTX-285

[John Ford]

Hi all.

Does anybody out there have a GTX-285 laying around that we could acquire
as a replacement part for GUPPI?  We've had our first GPU failure in about
6 years of 24/7/362.5 operation...


Please let me know if so!

John

[casper] Job Opportunity at NRAO Socorro

[John Ford]

Hi all.  Here's an official link to a job opportunity at NRAO in Socorro,
NM.  It's for an experienced person.

https://cw.na1.hgncloud.com/nrao/loadJobPostingDetails.do?jobPostingID=102420&source=jobList

A rude summary follows for the curious.  Sorry about the formatting...


John


Position Summary

The National Radio Astronomy Observatory (NRAO) is seeking to hire a digital
electronics engineer with a signal processing background who is familiar
with FPGAs,
embedded processors and who is experienced in programming these devices to
operate
in real-time systems.  Experience in working with the Xilinx and Altera FPGA
development platforms is highly desirable.



The NRAO has a long history of developing new technology to enable forefront
research in radio astronomy. This development occurs in a collaborative
environment
with technicians, hardware and software engineers, and scientists. By
joining NRAO,
an employee has a direct contribution to expanding the observatory's
state-of-the-art facilities and equipment used by scientists around the
world.  NRAO
currently has development programs under way in highly integrated receiver
architectures that employ early signal digitization, DSP filtering, data
encoding,
wideband digital signal processors, and photonic signal generation and data
transmission.





The position is based on the campus of New Mexico Institute of Mining and
Technology
(www.nmt.edu) at the Domenici Science Operations
Center in
Socorro, NM.  Socorro is a small, historical town in the Rio Grande
Valley, 75 miles
south of Albuquerque.



Classification and pay will be commensurate with the selected candidate's
qualifications and relevant experience.  In addition to competitive pay,
the NRAO
provides excellent paid time off benefits (vacation and sick leave). 
Medical,
dental and vision plans are effective first day of employment.  Our
retirement
benefit contributes an amount equal to 10 percent of the participant's
base pay. No
contribution is required of the employee; we also offer an optional
supplemental,
tax-deferred plan for employee retirement contributions.



Job Duties Summary

The successful candidate will work both independently and within a dynamic
team
environment to support ongoing developments for both future projects and for
existing telescope electronics hardware. This development involves Radio
Frequency
(RF), digital, and mixed-signal integrated circuits and systems applied to
radio
astronomy instrumentation. Responsibilities will include reviewing,
designing,
programming, testing, and troubleshooting firmware systems used to control
circuit
boards, interface electronics, and to provide signal processing systems
that prepare
receiver radio frequency signals for data correlation.  Functional
responsibilities
for this position include:

  *   Programming embedded processors and/or FPGA's for monitor, control,
and signal
processing functions;
  *   Conducting tests and data recording;
  *   Data analysis for verification of specifications;
  *   Electronic trouble-shooting;
  *   Circuit board design and layout;
  *   Perform other duties as assigned.


Competency Summary

The successful candidate will have skills and demonstrated competencies in
the
following areas:

  *   Strong analytical skills and both verbal and written communication
skills
  *   Ability and willingness to be a self-starter in a technical
environment;
  *   High-speed digital design;
  *   An understanding of mixed-signal integrated circuits, logic
families, A-to-D
and D-to-A converters;
  *   RF concepts in mixed signal design (impedance, reflections, isolation,
crosstalk, shielding, ground plane design);
  *   Field Programmable Gate Arrays and Digital Signal Processors;
  *   Embedded processors/microcontrollers;
  *   Good documentation and communication skills
  *   MATLAB, Simulink, LabVIEW, open-source hardware/firmware tools,
VHDL/Verilog;
  *   Circuit Board design and troubleshooting;
  *   Design for manufacturing;

Re: [casper] yellow block for 2Gsps adc/dac

[John Ford]

Hi all.

>From the work that Matt's done on the IODELAY and such, and the orginal
description of the problem, i.e. a simultaneous switching of several bits
at once, this sounds like a ground bounce problem or decoupling problems
on the ADC/DAC board, and not a firmware or ROACH problem.

John

 > Matt,
>
> No good ones --
>
> Are the bits that fail hardware / boffile specific?
> Are all the timing constraints correctly set up?
> Are all the IODELAY blocks suitably configured with resets, etc?
>
> That's all I got :(
>
> The ADC5g does 1.25Gb/s per ZDOK pair perfectly happily (I have 18 boards
> running them, and I don't remember the last time they failed to link up
> properly), so I don't think there's any fundamental problem from the
> ROACH2
> side.
>
> Jack
>
>
> On Thu, 28 Apr 2016 at 20:46 Matt Strader 
> wrote:
>
>> Thanks, Jack.
>>
>> I added IODELAYs to all my data bits.  I used my ramp input to check for
>> glitches in all the bits for each step in IODELAY value.  Also, I found
>> that having the mmcm in low bandwidth mode is indeed a bad idea, and
>> switched to high bandwidth mode and slightly slower clocks.
>>
>> I find a reasonable eye to calibrate with, except there are 4 bits that
>> glitch no matter what value I use for their IODELAY.  I lowered the
>> clock
>> rates quite a bit more, with the same result.
>>
>> Any more recommendations?
>>
>> Thanks,
>> Matt
>>
>> P.S. Here's what my eyes look like for 475 MHz DDR (1 indicates a bit
>> glitches for the delay value).  Notice that data2 bits 1,5,8, and 9 are
>> ones all the way down the column.
>> dly : data0_bits   data1_bits   data2_bits   data3_bits
>>   0 : 1011  101100100010 110110001000
>>   1 : 0011  101110100010 110010001000
>>   2 : 0011  101110100010 11001000
>>   3 : 00010100 0100 10100010 11001000
>>   4 : 0100 0100 11100010 1100
>>   5 : 01001110 11001100 11101010 11000110
>>   6 : 0100 11101100 1110 110001110010
>>   7 : 0100 1110  110001110111
>>   8 : 01001110 0100  110001110111
>>   9 : 0100 0101 001100100010 111001110111
>>  10 : 0100 1011 101100100010 001110011101
>>  11 : 0100 1010 101100100010 00001000
>>  12 : 1100 0010 101100100010 010110001000
>>  13 : 1011  101100100010 110110001000
>>  14 : 1011  101100100010 110110001000
>>  15 : 0011  101110100010 11001000
>>  16 : 00110100  101110100010 11001000
>>  17 : 00010100 0100 10100010 1100
>>  18 : 01001110 01000100 11100010 1100
>>  19 : 0100 01001100 1010 110001100010
>>  20 : 1100 1100 1110 110001110010
>>  21 : 01001110   110001110111
>>  22 : 0100   110001110111
>>  23 : 10110011 0101 101100100011 111001110111
>>  24 : 0011 1011 101100100010 
>>  25 : 10110011 1010 101100100010 00001000
>>  26 : 10110001 0010 101100100010 110110001000
>>  27 : 1011  101100100010 110110001000
>>  28 : 0011  101110100010 110110001000
>>  29 : 00110100  101110100010 110110001000
>>  30 : 00010100 0100 10100010 1100
>>  31 : 0100 0100 11100010 1100
>>
>>
>>
>> On Tue, Apr 26, 2016 at 4:55 PM, Jack Hickish 
>> wrote:
>>
>>> Hi Matt,
>>>
>>> The usual way to deal with this is IODELAY blocks as you suggest. The
>>> adc5g core has an example of the correct instantiation of the IODELAY
>>> primitive and some controller code to talk to them. IIRC, the delay
>>> goes
>>> straight after the input buffer, prior to the SERDES (or presumably
>>> immediately before the output buffers for the DAC).
>>>
>>> Cheers
>>> Jack
>>>
>>>
>>> On Tue, 26 Apr 2016 at 16:02 Matt Strader 
>>> wrote:
>>>
 Hello again,

 Now that my clocks are working, I've run into the next problem in my
 yellow block.  I have the adc/dac board sending a ramp, which I see on
 the
 roach2 side, but there are periodic glitches (see attached).  ?
  zdok_ctr_ramp2.tiff
 

 The data is coming over four 14-bit buses aligned to a 500 MHz clock
 from the adc/dac board, at DDR.  The glitches happen when the value
 coming
 through is a round number in binary, i.e. whenever several bits flip
 at
 once.  It seems that at each glitch, one or more bits fail to flip
 when
 they should, though they usually arrive at the right value one cycle
 later.

 I saw in the mailing list archive that people have had problems
 

Re: [casper] Fwd: Regarding wide band spectrometer ADC adc5g (ADC 5G V2.0 DMUX1:1) casper design error

[John Ford]

Can you tell us a bit more?  What is your sampling clock frequency?  What
level are you putting into the ADC input?  Can you replot this with
frequency on the X axis?  It would be good to see if the peaks you see are
related to the sampling clock and the input tone in some way, i.e. are they
intermodulation products.

Try turning down the input tone level (quite) a bit to be sure you are not
saturating the ADC.

I agree with Xavier that it's probably not the yellow block, although it's
possible you have a defective ADC.  Try substituting if you have another
one.   Your FFT shift should shift every stage probably fr a tone input.
Every other for noise+ tone.

Xavier's other suggestion to put in some snap blocks at the beginning of
the processing chain so that you can see the raw samples is a good one.  I
think this is something that should always be done in any design.  (and you
need them later to do the calibration properly!).

Hope this helps!

John


On Wed, Aug 23, 2017 at 4:08 AM, Siddharth Savyasachi Malu <
savyasachi.i...@gmail.com> wrote:

> Dear CASPERites,
>
> We are trying tut3(spectrometer) using adc5g(ADC 5G V2.0 DMUX1:1) on
> ROACH2 at 300MHz bandwidth. But the output spectrum shows multiple peak for
> a single tone input.
>
> Could you please tell us whether the issue may be related to the 5gsps ADC
> card or the casper adc5g block?
>
> Please find attached output spectrum for 300MHz bandwidth and 100MHz input
> tone signal.
>
> Many thanks,
> Siddharth Malu
> Bela Dixit
> --
> Centre of Astronomy
> Indian Institute of Technology Indore
> Indore, India
> email: siddha...@iiti.ac.in
>
> --
> You received this message because you are subscribed to the Google Groups "
> casper@lists.berkeley.edu" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to casper+unsubscr...@lists.berkeley.edu.
> To post to this group, send email to casper@lists.berkeley.edu.
>

-- 
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To post to this group, send email to casper@lists.berkeley.edu.

Re: [casper] Re: using two ADC, reg.

[John Ford]

Hi.

I'm not sure exactly what your question is, but on the face of it there are
3 nets that don't meet timing, due to routing problems.  What frequency are
you building the FPGA fabric at?  Have you tried just one ADC to see if it
routes OK?  How full is the FPGA with your design?  You may be able to use
planahead to manually place some parts to allow these nets to meet timing.
I don't know if there's anything in hte yellow block settings that might
help this.   You might want to load this into timing analyzer and see where
the problems lie.

John



On Fri, Sep 1, 2017 at 3:29 AM, Anshu Singh  wrote:

> Hi,
>
> The detailed error report is attached herewith.
>
> On Fri, Sep 1, 2017 at 3:50 PM, Anshu Singh 
> wrote:
>
>> Hi Everyone,
>>
>> I am trying to use 2 quadADC (ADC4*250) with ROACH board simultaneously.
>> While compiling, I am getting a timing error.The screen shot is attached
>> in this mail.
>>
>>
>> Could someone please let me know the issue?
>>
>>
>> Thanks,
>> Anshu
>>
>>
>
>
> --
> --
> Anshu
> Junior Research Fellow
> (Int. M.tech-Ph.D Batch 2013)
> Indian Institute of Astrophysics
> Koromangala II Block
> Bangalore-560034
>
> --
> You received this message because you are subscribed to the Google Groups "
> casper@lists.berkeley.edu" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to casper+unsubscr...@lists.berkeley.edu.
> To post to this group, send email to casper@lists.berkeley.edu.
>

-- 
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To post to this group, send email to casper@lists.berkeley.edu.

Re: [casper] adc5g Compilation Frequencies

[John Ford]

Hi Franco.

No, it does not work if you ignore these warnings.  It sort of works.
Which is worse, IMO...

You should dither your sampling rate until you find something thta works
and design the system to work with that.

John


On Tue, Sep 12, 2017 at 2:09 PM, Franco  wrote:

> Interesting, thanks for the info. Do you know if it is safe to operate the
> ADC outside does assigned constraints, assuming the model meets timing
> closure?
>
> Franco
>
>
> On 12/09/17 17:34, David MacMahon wrote:
>
>> Hi, Franco,
>>
>> I'm not extensively familiar with the inner workings of the AGC5G yellow
>> block, but I suspect the limitation is caused by the somewhat obscure
>> constraints imposed by the MMCM in the Virtex 6.  This limitation also
>> affects the ADC16 yellow block.  More details can be found here:
>>
>> https://casper.berkeley.edu/wiki/ADC16x250-8#ADC16_Sample_Ra
>> te_vs_Virtex-6_MMCM_Limitations
>>
>> Hope this helps,
>> Dave
>>
>> On Sep 12, 2017, at 14:37, Franco  wrote:
>>>
>>> Dear Casperites,
>>>
>>> Recently I've been testing adc5g block for different compilation
>>> frequency, I figured that the block can be compiled at [540, 960] U [1080,
>>> 2500] MHz, for every other frequency it gives you a "An optimum PLL
>>> solution is not available!" error. This restrictions come from the Matlab
>>> script 'xps_adc5g.m' that generates the block. The block does some
>>> computation I don't understand to to set the PLL parameters (or fails to
>>> do). Does someone has information about why this block has that particular
>>> behavior? I want to compile a model at 1000MHz, and I wonder if it is
>>> possible.
>>>
>>> Many Thanks,
>>>
>>> Franco Curotto
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "casper@lists.berkeley.edu" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to casper+unsubscr...@lists.berkeley.edu.
>>> To post to this group, send email to casper@lists.berkeley.edu.
>>>
>>
> --
> You received this message because you are subscribed to the Google Groups "
> casper@lists.berkeley.edu" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to casper+unsubscr...@lists.berkeley.edu.
> To post to this group, send email to casper@lists.berkeley.edu.
>

-- 
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To post to this group, send email to casper@lists.berkeley.edu.

Re: [casper] CASPER ./startsg running was failed and can not trig MATLAB

[John Ford]

Hi.  Did you do the changes at the bottom of the page regarding changing
the default shell under ubuntu?

https://casper.berkeley.edu/wiki/MSSGE_Setup_with_Xilinx_14.x_and_Matlab_2012b

John


On Tue, Jan 23, 2018 at 5:57 AM, zhang laiyu  wrote:

> Hi,there
>
>   I encount a problem in installing and running CASPER software.
>
>   My computer is DELL Optiplex 990 (inter i5 cpu,1TB hard disk,10GB ROM)
>
>   I had installed dual system in my computer(Windows 7 professional SP1,
> Ubuntu12.04 64 bit).Two system can work well.
>
>   I installed the CASPER software according to the CASPER web guide and
> the document in wiki.
>
>   1. Install ubuntu12.04
>
>   2. Install MATLAB R2012b
>
>This was installed successfully,and MATLAB can be run.
>
>   3 Install ISE14.7  (System Edition)
>
>It was seemed to be also successfully and also ISE can also be  run.
>
>   4 Clone the mlib_devel repository . This was operated normally
>
>   5 Create a startsg.local file
>
>specify my Xilinx and Matlab install path
>
>
>
> export MATLAB_PATH=/home/MATLAB/R2012b
> export XILINX_PATH=/home/Xilinx/14.7/ISE_DS
> export XILINX_PLATFORM=lin64
>
> 6. Last I start running startsg "./startsg"
>
>   It display a error message: There is no directory :sysgen/bin. MATLAB
> was not started.
>
> 7. And I checked the directory ../Xilinx/14.7/ISE_DS/SysGen/,I found it
> was empty.
>
>  So I guess that the start scipt can not find commands to start MATLAB.
>
> 8. when I sourced /ISE_DS/setting64.sh,and runing sysgen ,It pop-up error
> message,and sysgen can not be started.I guess that ISE14.7 System Generetor
> was not installed normally.I reinstalled Ubuntu12.04,Matlab R2012b and
> ISE14.7 again,but the problem still exist and pop up same warning message
> when I run startsg.
>
>  Do any people meet this problem before? and how to solve it?
>
>  Please help me,thank you.
>
>
>
>
>
>
>  Cheers!
>
>
>   *ZHANG Laiyu*
>
>
>   *Center for Particle Astrophysics*
>
>
>   *Institute of High Energy Physics, Chinese Academy of Sciences *
>
>
>   *19B Yuquan Road,Shijingshan,District,Beijing,China*
>
> *TEL: +86 010 88236415 <+86%2010%208823%206415>*
>
> * +86 13681385567 <+86%20136%208138%205567> *
>
> * E-mail: zhan...@ihep.ac.cn *
>
> * www: * http://w ww.ihep.ac.cn
>
>  --
> You received this message because you are subscribed to the Google Groups "
> casper@lists.berkeley.edu" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to casper+unsubscr...@lists.berkeley.edu.
> To post to this group, send email to casper@lists.berkeley.edu.
>

-- 
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To post to this group, send email to casper@lists.berkeley.edu.

Re: [casper] sharing CASPER equipment

[John Ford]

Hi Tom.

I think this is reasonably easy to manage.  At Green Bank, the spectrometer
consists of 8 ROACH-2s that are all reprogrammed for different observing
modes.  The modes are personalities stored on disk and loaded on command.
It works fine.  You do have to coordinate to make sure only one computer is
commanding things.  If you're not hitting the wall performace-wise,
rebooting your control computer into different virtual machines is an
interesting way to make sure you don't get wrapped around that particular
axle.  We never attempted to run stuff on a virtual machine because we were
trying to wring all the performance we could out of our 10 gig ports.  It
would be an interesting experiment to see how much running in a VM costs in
performance...

Managing the PFGA personalities is easy, I think.  Managing the software is
probably pretty easy as well if you package things up and have scripts to
start and stop the different experiments.

John


On Mon, Jan 29, 2018 at 12:17 AM, Jason Manley  wrote:

> Hi Tom
>
> We switch firmware around on our boards regularly (~20min observation
> windows) on KAT-7 and MeerKAT. But we maintain control of the various
> bitstreams ourselves, and manage the boards internally.
>
> There is a master controller which handles allocation of processing nodes
> to various projects, and loads the appropriate firmware onto those boards
> for their use. The master controller has a standardised KATCP
> external-facing interface. But we write to the registers on the FPGAs
> ourselves -- ie only this controller has direct, raw access to the FPGAs.
> This "master controller" software process kills and starts separate
> software sub-processes as needed in order to run the various instruments.
> Sometimes they operate simultaneously by sub-dividing the available boards
> into separate resource pools.
>
> We have one special case where two completely independent computers access
> the hardware. We use this for internal testing and verification. But I
> wouldn't use that for a deployed, science-observation system due to risk of
> collisions. You'd have to implement some sort of semaphore/lock/token
> system, which would require co-ordination between the computers. To me,
> that seems like a complicated effort for such a simple task.
>
> Jason Manley
> Functional Manager: DSP
> SKA-SA
>
>
> On 28 Jan 2018, at 21:04, Tom Kuiper  wrote:
>
> > I'm interested in experience people have had using the same equipment
> installed on a telescope for different projects using different firmware
> and software.  Have there been issues with firmware swapping?  Are there
> software issues that cannot be managed by using a different control
> computer or a virtual environment in the same controller?  In addition to
> your experience I'd like a summary opinion: yes, it can be done without
> risking observations, or no, better to have separate hardware.
> >
> > Many thanks and best regards,
> >
> > Tom
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "casper@lists.berkeley.edu" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to casper+unsubscr...@lists.berkeley.edu.
> > To post to this group, send email to casper@lists.berkeley.edu.
>
> --
> You received this message because you are subscribed to the Google Groups "
> casper@lists.berkeley.edu" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to casper+unsubscr...@lists.berkeley.edu.
> To post to this group, send email to casper@lists.berkeley.edu.
>

-- 
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To post to this group, send email to casper@lists.berkeley.edu.

Re: [casper] packets lost of a packetized correlator

[John Ford]

Hi Homin.  I think Danny's suggestion is a good one.  We have had similar
problems with the system working for a while, then packets getting lost.
Making sure that the entries in the ARP table are correct (and the yellow
block MAC addresses are correct) may solve it.  Looking at the switch
traffic with the monitoring built into it might tell you if this is a
problem.

John

On Mon, Mar 12, 2018 at 10:54 PM, David MacMahon 
wrote:

> I think the tx overflow will be OK since the FPGA won't try to send more
> than 10 Gbps.  I think the "rx overrun" flag would be more interesting.
> But probably best to check both of course! :)
>
> Is the X engine clock an exact copy of the F engine clock (i.e. a common
> clock that goes through a massive splitter) or just a clock of the same
> frequency locked to the same reference (but not the exact same clock)?
> Things get more complicated once you run F and X at different rates, so I
> wouldn't recommend that path if you can avoid it.
>
> HTH,
> Dave
>
>
> On Mar 12, 2018, at 22:01, Homin Jiang  wrote:
>
> Hi Dave:
>
> Thanks of prompt response and suggestion.
> The X engine is running the same clock as the F engine, 2.24GHz/8 =
> 280MHz. Perhaps I should increase the clock in X engine ?
> Yes, there is Tx overflow flag in the model, it will be the first thing
> for me to check.
>
> best
> homin
>
>
>
> On Tue, Mar 13, 2018 at 12:42 PM, David MacMahon 
> wrote:
>
>> Hi, Homin,
>>
>> The first thing to do is figure out where packet loss is actually
>> happening.  The fact that you have to reset the 10G yellow blocks to get
>> things going again suggests that the X engines are not keeping up with the
>> data rate (since the F engines will happily churn out 8.96 Gbps data
>> regardless of the receivers' states and the X engines will happily churn
>> out data regardless of the PC's state, it seems that the only way for the
>> 10 GbE blocks to get confused is if the X engines are not keep up with the
>> incoming data rate).  I assume the F engine ROACH2s are being clocked via
>> their ADCs.  How are the X engine ROACH2s being clocked?
>>
>> Assuming the F-to-X packets are going through a switch, you could query
>> the switch to see what it thinks the incoming and outgoing data rates are
>> on the various ports involved.
>>
>> Does your design have any way of capturing the overflow flags of the 10
>> GbE cores?
>>
>> Dave
>>
>> On Mar 12, 2018, at 19:39, Homin Jiang  wrote:
>>
>> Dear Casperite:
>>
>> We have been deployed a 7(actually 8) antenna packetized correlator on
>> Mauna Loa Hawaii. Running at 2.24GHz clock, that means 8.96 G bits per
>> second for each 10G ethernet. The packet size is 2K. There are 8 sets of
>> ROACH2 as F engines, the other 8 sets of ROACH2 as X engines. Data packets
>> from F to X looks fine, the problem of lost packets is the integration data
>> from X engine to the computer. The 10G yellow blocks in X engines handle
>> the incoming data packets from F engine at the data rate of 8.96 Gbps, and
>> output the integration data to PC, the outgoing data rate depends on the
>> integration time, usually it is longer than 0.5 second. The syndrome is
>> that packets lost happened by specific X engines after 10,20 minutes or
>> couple of hours. Once it happened, we reset all the 10G yellow blocks in F
>> and X, then the system revived.
>>
>> I have no idea about the 10G ethernet yellow block. Any comments of
>> suggestions are highly welcome.
>>
>> best
>> homin jiang
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "casper@lists.berkeley.edu" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to casper+unsubscr...@lists.berkeley.edu.
>> To post to this group, send email to casper@lists.berkeley.edu.
>>
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "casper@lists.berkeley.edu" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to casper+unsubscr...@lists.berkeley.edu.
>> To post to this group, send email to casper@lists.berkeley.edu.
>>
>
>
> --
> You received this message because you are subscribed to the Google Groups "
> casper@lists.berkeley.edu" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to casper+unsubscr...@lists.berkeley.edu.
> To post to this group, send email to casper@lists.berkeley.edu.
>
>
> --
> You received this message because you are subscribed to the Google Groups "
> casper@lists.berkeley.edu" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to casper+unsubscr...@lists.berkeley.edu.
> To post to this group, send email to casper@lists.berkeley.edu.
>

-- 
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.

Re: [casper] UltraScale+ 100G Ethernet Configuration

[John Ford]

Hi Arash.

We use raw Ethernet on Linux for some control systems here.  You should be
able to open the Ethernet port and receive raw Ethernet packets.  Here's a
code that's very similar to what we do in our control system:

https://gist.github.com/austinmarton/2862515

Since it's 100 Gb Ethernet, of course you are breaking some new ground!

John



On Tue, Apr 3, 2018 at 8:34 AM, Roshanineshat, Arash <
arash.roshanines...@cfa.harvard.edu> wrote:

> Hi everyone
>
> Thank you all for your suggestions. I would like to update you about the
> progress.
>
> As a quick background and as I had mentioned in last email, despite of
> getting correct simulation results, I wasn't getting the link established
> between VCU118 and destination machines, neither a switch nor a Linux
> Machine. I'm using Si5328 as my clock and I am converting the differential
> clock to single-ended clock using a IBUFDS.
>
> This a an updated procedure:
>
> 1- I adjusted the clock values.
> 2- Implemented near-end PMA loopback and the result is : PASS
> 3- Used a loopback module and the result is: PASS
> 4- Using the loopback module, I learned that I am using wrong GTY
> transmission lanes, so I corrected them.
> 5- The connection to the 100G Switch: PASS
> 6- The direct connection to the linux machine, equipped Mellanox ConnetX-4
> : FAIL
>
> I think the reason that the Linux machine is rejecting the packets is that
> the data I'm sending is not wrapped in an standard way like UDP frames.
> The traffic is flowing to the switch though. I'm writing some Verilog to
> wrap the data in UDP frames. I'll update you once I get the data flow from
> switch to the linux machine.
>
> Thank you all for your help and support. I would appreciate it if you
> could share your opinion and feedback.
>
> Best Regards
> Arash Roshanineshat
>
>
>
> On Tue, Feb 27, 2018 at 3:38 PM, Adam Isaacson 
> wrote:
>
>> Hi Arash,
>>
>> I just spoke with Jack Hickish and it seems Hong Chen, Benjamin Hlope
>> (SARAO have contracted him to develop the 100GbE yellow block, as well as
>> other functionality) and you are all going to or are developing the 100GbE
>> yellow block. I would suggest we try work together and not all develop
>> separate versions of the core. What do you think? Benjamin may also be able
>> to help you with your query below.
>>
>> Food for thought. The time lines may not be possible, but we should try
>> and converge.
>>
>> Kind regards,
>>
>> Adam Isaacson
>> SARAO
>> DBE Hardware Manager
>> Cell: (+27) 825639602 <+27%2082%20563%209602>
>> Tel:  (+27) 215067300 <+27%2021%20506%207300>
>> email: aisaac...@ska.ac.za
>>
>>
>> On Tue, Feb 27, 2018 at 1:34 PM, Adam Isaacson 
>> wrote:
>>
>>> Hi Arash,
>>>
>>> I am afraid I don't have the expertise on this yet or a solution to this
>>> problem. We also have a VCU118 board and will be implementing a 100GbE
>>> yellow block in the months to come, so it would be good to stay in touch
>>> about this - maybe not duplicate work, but help one another if time
>>> pressures allow.
>>>
>>> Kind regards,
>>>
>>> Adam Isaacson
>>> SARAO
>>> DBE Hardware Manager
>>> Cell: (+27) 825639602 <+27%2082%20563%209602>
>>> Tel:  (+27) 215067300 <+27%2021%20506%207300>
>>> email: aisaac...@ska.ac.za
>>>
>>>
>>> On Mon, Feb 26, 2018 at 10:25 PM, Jack Hickish 
>>> wrote:
>>>
 Hi Arash,

 It's awesome that you're doing this.

 I only have experience bringing up the 10GbE core on SNAP, but a few
 things you might try are:
 - Make sure all the (many!) clocks are running at the correct speed --
 easy to misconfigure.
 - Check and double check resets
 - Setting the transceivers into loopback mode, and checking for sanity.
 - Using a QSFP loopback module to similar effect. I believe one is
 supplied with the VCU kit.

 I'm pretty sure I have less expertise in this than you, but they're my
 first thoughts.

 I assume that the infiniband switch is dual-personality, and capable of
 establishing a 100GbE link?

 Anyway, it's great that you're working on this,

 Jack



 On Mon, 26 Feb 2018 at 12:13 Roshanineshat, Arash <
 arash.roshanines...@cfa.harvard.edu> wrote:

> Hi
>
> I'm trying to implement a design using UltraScale+ 100G Ethernet on a
> VCU118 board. I use Vivado 2017.4 and UltraScale+ 100G Ethernet IP
> core subsystem version 2.4.
>
> I'll give you a quick background about what I have done so far, please
> let me know if I took a wrong step at any point.
>
> I want to implement OSI model which consists of following layers:
>
> 7-Application layer
> 6-Presentation layer
> 5-Session Layer
> 4-Transport
> 3-Network Layer
> 2-Data Link Layer
> 1-Physical layer
>
> According to what I learned from Xilinx's forum community, 100G IP
> core will take care of Ethernet protocol (Layers 1 and 2) and I have
> to implement Layers 3 and 4. However, 

Re: [casper] Problem with ROACH2 netboot

[John Ford]

Hi Bela.

The non-working one looks to be set up to boot from flash, not the
network.  I think to get it to boot over the network you will have to set
up the environment to have the correct information to be able to find its
NFS mounted root, and the other networking stuff that is needed.  You can
probably pretty much use the info from the working roach, aside from things
like ethernet address which is different between the 2.

John


On Fri, May 11, 2018 at 3:02 AM, Bela Dixit  wrote:

> Thanks Devid and Marc.
> Working ROACH2 not giving "bad CRC" warning.
> I tried with printenv command to check environment variable there is
> difference between working and non-working board. Please find attached file
> of printenv output of working and non-working board.
>
>
> Thanks & Regards,
> Bela
>
> On Wed, May 9, 2018 at 2:41 PM, Marc Welz  wrote:
>
>> As uboot starts up, interrupt the boot to get the uboot prompt. Then
>> run a printenv command and compare it to the other working roach. If
>> the configuration is bad, you might not have a useful kernel command
>> line or mac address available - the latter is need for the network
>> interface to be initialised.
>>
>> regards
>>
>> marc
>>
>>
>> On Wed, May 9, 2018 at 5:50 AM, Bela Dixit  wrote:
>> > Hi CASPERites,
>> >
>> >  I get a problem when I try to boot ROACH2 via netboot. I tried
>> anther
>> > ROACH2 board with same machine, it successfully booted. The complete log
>> > message dumped on minicom during the boot procedure is reported at the
>> end
>> > of this email.
>> > Kindly help me to fix the problem.
>> >
>> > Thanks & Regards,
>> > Bela
>> >
>> > 
>> *
>> > Welcome to minicom 2.7
>> >
>> > OPTIONS: I18n
>> > Compiled on Jan  1 2014, 17:13:19.
>> > Port /dev/ttyUSB2, 11:07:44
>> >
>> > Press CTRL-A Z for help on special keys
>> >
>> >
>> >
>> > U-Boot 2011.06-rc2-0-gd422dc0-dirty (Nov 08 2012 - 16:04:14)
>> >
>> > CPU:   AMCC PowerPC 440EPx Rev. A at 533.333 MHz (PLB=133 OPB=66 EBC=66)
>> >No Security/Kasumi support
>> >Bootstrap Option C - Boot ROM Location EBC (16 bits)
>> >32 kB I-Cache 32 kB D-Cache
>> > Board: ROACH2
>> > I2C:   ready
>> > DRAM:  512 MiB
>> > Flash: 128 MiB
>> > *** Warning - bad CRC, using default environment
>> >
>> > In:serial
>> > Out:   serial
>> > Err:   serial
>> > CPLD:  2.1
>> > USB:   Host(int phy)
>> > SN:ROACH2.2 batch=D#6#33 software fixups match
>> > WARN:  MAC not set, deriving private MAC from serial number
>> > MAC:   02:44:01:02:06:21
>> > DTT:   1 is 39 C
>> > DTT:   2 is 39 C
>> > Net:   ppc_4xx_eth0
>> > Sensors Config
>> > type run netboot to boot via dhcp+tftp+nfs
>> > type run soloboot to run from flash independent of network
>> >
>> > Hit any key to stop autoboot:  0
>> > =>  run netboot
>> > Waiting for PHY auto negotiation to complete done
>> > ENET Speed is 1000 Mbps - FULL duplex connection (EMAC0)
>> > BOOTP broadcast 1
>> > *** Unhandled DHCP Option in OFFER/ACK: 28
>> > *** Unhandled DHCP Option in OFFER/ACK: 28
>> > DHCP client bound to address 192.168.100.196
>> > Using ppc_4xx_eth0 device
>> > TFTP from server 192.168.100.1; our IP address is 192.168.100.196
>> > Filename 'uImage'.
>> > Load address: 0x400
>> > Loading: 
>> #
>> >  
>> #
>> >  
>> #
>> >  
>> > done
>> > Bytes transferred = 3034268 (2e4c9c hex)
>> > ## Booting kernel from Legacy Image at 0400 ...
>> >Image Name:   Linux-3.16.0-saska-03675-g1c70ff
>> >Image Type:   PowerPC Linux Kernel Image (gzip compressed)
>> >Data Size:3034204 Bytes = 2.9 MiB
>> >Load Address: 0070
>> >Entry Point:  007010c4
>> >Verifying Checksum ... OK
>> >Uncompressing Kernel Image ... OK
>> > CPU clock-frequency <- 0x1fca0550 (533MHz)
>> > CPU timebase-frequency <- 0x1fca0550 (533MHz)
>> > /plb: clock-frequency <- 7f28154 (133MHz)
>> > /plb/opb: clock-frequency <- 3f940aa (67MHz)
>> > /plb/opb/ebc: clock-frequency <- 3f940aa (67MHz)
>> > /plb/opb/serial@ef600300: clock-frequency <- 54c563 (6MHz)
>> > /plb/opb/serial@ef600400: clock-frequency <- 54c563 (6MHz)
>> > /plb/opb/serial@ef600500: clock-frequency <- 54c563 (6MHz)
>> > /plb/opb/serial@ef600600: clock-frequency <- 54c563 (6MHz)
>> > Memory <- <0x0 0x0 0x3000> (1023MB)
>> > ethernet0: local-mac-address <- 00:00:00:00:00:00
>> >
>> > zImage starting: loaded at 0x0070 (sp: 0x1fe22b40)
>> > Allocating 0x6db8a8 bytes for kernel ...
>> > gunzipping (0x <- 0x0070f000:0x00d5f1c8)...done 0x63fa80 bytes
>> >
>> > Linux/PowerPC load: console=ttyS0,115200 root=/dev/nfs
>> > rootpath=192.168.100.1:/srv/roach_boot/etch ip=dhcp
>> > Finalizing device tree... flat tree at 0xd6c160
>> > [0.00] r

[casper] New Wideband Spectrometer Designs

[John Ford]

Hi all.  We're interested in wideband moderate performance spectrometers.
Something that can digitize 2 (or 4) polarizations at at ~ 8 to 10 GS/s,
and provide ~4K channels, full stokes, with a moderate dump rate (1 GB/sec
or less).

We could use 8 ROACH-2/ADC-5GS VEGAS-style spectrometer blades, 2 for each
4 GHz polarization and sideband. (simultaneous upper and lower sidebands
are required)

Or we could move on to newer ADCs and processing boards, and get the full 4
GHz from each polarization in one go.  I think this is preferable, for many
reasons.

The key here, I think, is the ADCs that may have come to market (or to the
casper community) since VEGAS was built.  I know Homin Jiang and Jonathan
Weintroub's groups are working on wideband ADCs and integration with FPGA
boards.

So the questions that I am posing are:  What ADCs and hardware
configuration would you choose for a minimum-effort maximum-effect project
to be built and deployed in the near future?  What projects could we assist
with in getting the next fast ADCs developed and tested?

Is this all fodder for the CASPER workshop discussions?

John

-- 
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To post to this group, send email to casper@lists.berkeley.edu.

Re: [casper] Problem when programming ROACH2

[John Ford]

Hi Raimondo,

We saw this years ago at NRAO.  Marc is right about the solution.

John

On Fri, Aug 10, 2018 at 7:20 AM, Marc Welz  wrote:

> As per previous email: Either start it again, or upgrade it
>
> regards
>
> marc
>
>
> On Fri, Aug 10, 2018 at 12:45 PM, Concu, Raimondo
>  wrote:
> > Hi Mark,
> >
> > Hi everyone,
> >
> > maybe you're right
> >
> > when the problem happens
> >
> > and i restart tcpborphserver3, the problem disappears.
> >
> > and this is the output:
> >
> > root@192:~# ps -ALL | grep tcp
> >   820   820 ?00:00:53 tcpborphserver3
> > root@192:~# kill 820
> > root@192:~#
> > roach VMA close
> > roach release mem called
> > roach VMA close
> > roach release mem called
> > roach VMA close
> > roach release mem called
> > roach VMA close
> > roach release mem called
> > roach VMA close
> > roach release mem called
> > roach VMA close
> > roach release mem called
> > roach VMA close
> > roach release mem called
> > roach VMA close
> > roach release mem called
> > roach VMA close
> > roach release mem called
> > roach VMA close
> > roach release mem called
> > roach VMA close
> > roach release mem called
> > roach VMA close
> > roach release mem called
> > roach VMA close
> > roach release mem called
> > roach VMA close
> > roach release mem called
> > roach VMA close
> > roach release mem called
> > roach VMA close
> > roach release mem called
> > roach VMA close
> > roach release mem called
> > roach VMA close
> > roach release mem called
> > roach VMA close
> > roach release mem called
> > roach VMA close
> > roach release mem called
> > roach VMA close
> > roach release mem called
> > roach VMA close
> > roach release mem called
> > roach VMA close
> > roach release mem called
> > roach VMA close
> > roach release mem called
> > roach VMA close
> > roach release mem called
> > roach VMA close
> > roach release mem called
> > roach VMA close
> > roach release mem called
> > roach VMA close
> > roach release mem called
> > roach VMA close
> > roach release mem called
> > roach VMA close
> > roach release mem called
> > roach VMA close
> > roach release mem called
> > roach VMA close
> > roach release mem called
> > roach VMA close
> > roach release mem called
> > roach VMA close
> > roach release mem called
> > roach VMA close
> > roach release mem called
> > roach VMA close
> > roach release mem called
> > roach VMA close
> > roach release mem called
> > roach VMA close
> > roach release mem called
> > roach VMA close
> > roach release mem called
> > roach VMA close
> > roach release mem called
> > roach VMA close
> > roach release mem called
> > roach VMA close
> > roach release mem called
> > roach VMA close
> > roach release mem called
> > roach VMA close
> > roach release mem called
> > roach VMA close
> > roach release mem called
> > roach VMA close
> > roach release mem called
> > roach VMA close
> > roach release mem called
> > roach VMA close
> > roach release mem called
> > roach VMA close
> > roach release mem called
> > roach VMA close
> > roach release mem called
> > roach VMA close
> > roach release mem called
> > roach VMA close
> > roach release mem called
> > roach VMA close
> > roach release mem called
> > roach VMA close
> > roach release mem called
> > roach VMA close
> > roach release mem called
> > roach VMA close
> > roach release mem called
> > roach VMA close
> > roach release mem called
> > roach VMA close
> > roach release mem called
> > roach VMA close
> > roach release mem called
> >
> >
> >
> > Any suggestions?
> >
> > Thanks in advance
> > Raimondo
> >
> >
> > 2018-08-10 13:46 GMT+02:00 Marc Welz :
> >>
> >> Hello
> >>
> >>
> >> The "raw unable\_to\_map\_file\_/dev/roach/mem:\_Cannot\_allocate\_
> memory"
> >> is the interesting line. I suspect you are running a slightly older
> >> version of the filesystem or romfs which had a bug where it didn't
> >> unmap the previous image, and so suffered address space exhaustion
> >> after a dozen or so programs. The quick way to solve this is to reboot
> >> occasionally, the long term solution is to program a newer version of
> >> the romfs (in particular tcpborphserver)
> >>
> >> regards
> >>
> >> marc
> >>
> >>
> >> On Fri, Aug 10, 2018 at 10:17 AM, Concu, Raimondo
> >>  wrote:
> >> > Hi Everyone,
> >> >
> >> > I have a problem when programming the board after a certain number of
> >> > times
> >> > (30 - 60),
> >> >
> >> > as you can see in the following log:
> >> >
> >> > DEBUG:katcp:Starting thread Thread-1
> >> > 2018-08-10 11:04:15,203--client--DEBUG: Starting thread Thread-1
> >> > DEBUG:katcp:#version alpha-6-g0b8dd54
> >> > 2018-08-10 11:04:15,206--client--DEBUG: #version alpha-6-g0b8dd54
> >> > DEBUG:katcp:#build-state 2012-10-24T10:04:56
> >> > 2018-08-10 11:04:15,206--client--DEBUG: #build-state
> 2012-10-24T10:04:56
> >> > DEBUG:katcp:#version-connect katcp-library alpha-6-g0b8dd54
> >> > 2012-10-24T10:04:56
> >> > 2018-08-10 11:04:15,206--client--DEBUG: #version-connect katcp-library
> >> > alph

Re: [casper] New Wideband Spectrometer Designs

[John Ford]

Hi all.  Thanks for the information.  I'll try and digest it!

John


On Mon, Aug 6, 2018 at 6:48 PM, Homin Jiang 
wrote:

> Dear John:
>
> For the ADCs faster than 10Gsps, i think a bigger FPGA than ROACH2 is
> necessary. The speed of utrascale + FPGA is about 800/900MHz, that
> lead to 32 (10Gsps) or 64(16Gsps) parallel inputs to PFB/FFT.
> According to Rurik's equation, it  needs 4 or 16 times resource of
> FPGA in comparison to 5G adc.
>
> There are many FMC interface ADCs available in the market. Hitech
> Global is making the 10Gsps board using Analog Device 9213
> (http://www.hitechglobal.com/FMCModules/12-bitADC_10Gsps.htm).
> Unfortunately, there is no FMC platform ported to JASPER so far. There
> are couple of groups working independently, Jack/Brian, Arashi and
> myself. So, i am thinking we should form a VCU118 working group to
> expedite the porting work. We can talk about this during the meeting.
>
> best
> homin
>
>
> On Tue, Aug 7, 2018 at 2:45 AM, David MacMahon 
> wrote:
> > Hi, John,
> >
> > I was speaking with Homin last week at the CASPER Hardware Porting
> Workshop
> > hosted in Cape Town.  He mentioned the Analog Devices 10 Gsps 12-bit ADC
> > that I think is the same one Dan referenced. My recollection of our
> > conversation was that the pricing was not so bad, but I could be
> conflating
> > that assessment with a different ADC. In any event, I think future ADC
> > boards will move to FMC (or FMC+) connectors.  This will necessitate new
> > host FPGA boards which is why the next gen CASPER toolflow emphasizes
> ease
> > of porting new boards to the CASPER toolflow. It’s an exciting upgrade in
> > processing capacity, but it’s still early days. Definitely fodder CASPER
> > Workshop discussions! :)
> >
> > Dave
> >
> > On Aug 6, 2018, at 20:25, Dan Werthimer  wrote:
> >
> >
> >
> > hi john,
> >
> > how many bits do you need?
> >
> > here are some possibilities:
> >
> > a)
> > if 4 bits, then homin's 15 Gsps adc board might be a good choice.
> >
> > b)
> > if 12 bits, and you don't mind breaking the band up into 2 GHz chunks,
> > then this $9K RFsoc eval board has eight 12 bit 4Gsps ADC's and a big
> FPGA
> > to channelize and packetize:
> > https://www.xilinx.com/products/boards-and-kits/zcu111.html
> >
> > c)
> > if 12 bits, and you want to digitize the whole band at once,
> > you might consider AD's new 10.25GSps 12-bits ADC with a 6.5GHz
> bandwidth:
> > http://www.analog.com/en/products/analog-to-digital-
> converters/standard-adc/high-speed-ad-10msps/ad9213.html
> > but it's pricy, data sheet is preliminary, and i don't know if anybody
> has
> > an FMC board with this chip yet.
> > http://www.analog.com/en/about-adi/news-room/press-
> releases/2018/5-21-2018-12-bit-10-point-25-gsps-radio-
> frequency-adc-sets-new-performance.html
> >  shows the pricing as $3,652.49 in 1000 piece quantities.
> >
> >
> > best wishes,
> >
> > dan
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On Mon, Aug 6, 2018 at 11:13 AM, John Ford  wrote:
> >>
> >> Hi all.  We're interested in wideband moderate performance
> spectrometers.
> >> Something that can digitize 2 (or 4) polarizations at at ~ 8 to 10
> GS/s, and
> >> provide ~4K channels, full stokes, with a moderate dump rate (1 GB/sec
> or
> >> less).
> >>
> >> We could use 8 ROACH-2/ADC-5GS VEGAS-style spectrometer blades, 2 for
> each
> >> 4 GHz polarization and sideband. (simultaneous upper and lower
> sidebands are
> >> required)
> >>
> >> Or we could move on to newer ADCs and processing boards, and get the
> full
> >> 4 GHz from each polarization in one go.  I think this is preferable, for
> >> many reasons.
> >>
> >> The key here, I think, is the ADCs that may have come to market (or to
> the
> >> casper community) since VEGAS was built.  I know Homin Jiang and
> Jonathan
> >> Weintroub's groups are working on wideband ADCs and integration with
> FPGA
> >> boards.
> >>
> >> So the questions that I am posing are:  What ADCs and hardware
> >> configuration would you choose for a minimum-effort maximum-effect
> project
> >> to be built and deployed in the near future?  What projects could we
> assist
> >> with in getting the next fast ADCs developed and tested?
> >>
> >> Is this all fodder for the CASPER workshop discussio

Re: [casper] Problem when programming ROACH2

[John Ford]

That depends where the image lives.  If it is on an NFS mounted disk
somewhere, you have to install the new kernel and file system there.  If on
the flash, you have to install it on the flash.

THe latest stuff ought to be here (Marc is it so?)
https://casper.berkeley.edu/wiki/LatestVersions


To put it on NFS, here's some info...
https://casper.berkeley.edu/wiki/ROACH_NFS_guide

To put it on flash, try this:
https://casper.berkeley.edu/wiki/ROACH_kernel_uboot_update

It's been a while since I have done this, so...

Good luck!

You should browse the mailing list archive for more on how to do this.

John


On Fri, Aug 10, 2018 at 9:12 AM, Raimondo Concu 
wrote:

> Hi John,
>
> How do I update it?
>
> Thanks
> Raimondo
>
>
> Il Ven 10 Ago 2018, 17:48 John Ford  ha scritto:
>
>> Hi Raimondo,
>>
>> We saw this years ago at NRAO.  Marc is right about the solution.
>>
>> John
>>
>> On Fri, Aug 10, 2018 at 7:20 AM, Marc Welz  wrote:
>>
>>> As per previous email: Either start it again, or upgrade it
>>>
>>> regards
>>>
>>> marc
>>>
>>>
>>> On Fri, Aug 10, 2018 at 12:45 PM, Concu, Raimondo
>>>  wrote:
>>> > Hi Mark,
>>> >
>>> > Hi everyone,
>>> >
>>> > maybe you're right
>>> >
>>> > when the problem happens
>>> >
>>> > and i restart tcpborphserver3, the problem disappears.
>>> >
>>> > and this is the output:
>>> >
>>> > root@192:~# ps -ALL | grep tcp
>>> >   820   820 ?00:00:53 tcpborphserver3
>>> > root@192:~# kill 820
>>> > root@192:~#
>>> > roach VMA close
>>> > roach release mem called
>>> > roach VMA close
>>> > roach release mem called
>>> > roach VMA close
>>> > roach release mem called
>>> > roach VMA close
>>> > roach release mem called
>>> > roach VMA close
>>> > roach release mem called
>>> > roach VMA close
>>> > roach release mem called
>>> > roach VMA close
>>> > roach release mem called
>>> > roach VMA close
>>> > roach release mem called
>>> > roach VMA close
>>> > roach release mem called
>>> > roach VMA close
>>> > roach release mem called
>>> > roach VMA close
>>> > roach release mem called
>>> > roach VMA close
>>> > roach release mem called
>>> > roach VMA close
>>> > roach release mem called
>>> > roach VMA close
>>> > roach release mem called
>>> > roach VMA close
>>> > roach release mem called
>>> > roach VMA close
>>> > roach release mem called
>>> > roach VMA close
>>> > roach release mem called
>>> > roach VMA close
>>> > roach release mem called
>>> > roach VMA close
>>> > roach release mem called
>>> > roach VMA close
>>> > roach release mem called
>>> > roach VMA close
>>> > roach release mem called
>>> > roach VMA close
>>> > roach release mem called
>>> > roach VMA close
>>> > roach release mem called
>>> > roach VMA close
>>> > roach release mem called
>>> > roach VMA close
>>> > roach release mem called
>>> > roach VMA close
>>> > roach release mem called
>>> > roach VMA close
>>> > roach release mem called
>>> > roach VMA close
>>> > roach release mem called
>>> > roach VMA close
>>> > roach release mem called
>>> > roach VMA close
>>> > roach release mem called
>>> > roach VMA close
>>> > roach release mem called
>>> > roach VMA close
>>> > roach release mem called
>>> > roach VMA close
>>> > roach release mem called
>>> > roach VMA close
>>> > roach release mem called
>>> > roach VMA close
>>> > roach release mem called
>>> > roach VMA close
>>> > roach release mem called
>>> > roach VMA close
>>> > roach release mem called
>>> > roach VMA close
>>> > roach release mem called
>>> > roach VMA close
>>> > roach release mem called
>>> > roach VMA close
>>> > roach release mem called
>>> > roach VMA close
>>> > roach release mem called
>>&

Re: [casper] Timestamp in ROACH2 and PTP

[John Ford]

Hi Franco.

We have normally time-stamped the data using a hardware 1 Pulse per Second
digital input as a sync source, which gives us << 1 microsecond timing
precision.  PTP requires hardware support in the LAN hardware, and I don't
recall for sure but I don't think it's in the PHY/MAC on the PPC, so the
direct answer to your question, I think, is no.  But you probably need to
time-stamp the data in the FPGA anyway if you need really precise timing.
You could use an FPGA Ethernet core to handle the PTP chores.  But I don't
think anyone has done that yet.  The Xilinx tri-mode Ethernet core has PTP
support in it, but I don't know what core the 1G yellow block uses.


On Wed, Mar 6, 2019 at 10:41 AM Franco  wrote:

> Dear Casperiites,
>
> I was given the task of timestamping ROACH2 spectral data in a telescope
> that uses PTP (precision time protocol) as a synchronization protocol. I
> understand that ROACH's BORPH come preloaded with NTP (network time
> protocol) libraries/daemos, but PTP is preferred because is already in use
> in the telescope, and it achieves greater time precision.
>
> Does somebody know if it is feasible to compile/install PTP libraries in
> BORPH?
>
> Alternatively, we have though of sending the ROACH the current time
> through a GPIO pin using IRIG-B timecode standard. Has anybody done
> something similar in the past?
>
> Thanks,
>
> Franco
>
> --
> You received this message because you are subscribed to the Google Groups "
> casper@lists.berkeley.edu" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to casper+unsubscr...@lists.berkeley.edu.
> To post to this group, send email to casper@lists.berkeley.edu.
>

-- 
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To post to this group, send email to casper@lists.berkeley.edu.

Re: [EXTERNAL] [casper] seeking high accuracy GPS disciplined time/frequency standards ?

[John Ford]

Hi Dan, all.

How about a combination of these techniques?  You could get an ultra-stable
oscillator, possibly similar to what Bob Jarnot suggested, and then use the
day-old-postprocessed GPS timing results to calibrate the 2 atomic clocks'
time at different places on the earth.  Hopefully (to be borne out by
testing/calculations!) your 2 oscillators would be stable enough that you
could adjust them over time (days?) and get them precisely synced up and
they would stay that way.

John


On Fri, Mar 8, 2019 at 2:55 PM Dan Werthimer  wrote:

>
> hi robert, randall,  dale and casperites,
>
> thanks for your time/freq standard suggestions.
>
> our problem to get accurate 1 PPS wrt UTC is not limited by internal
> oscillator stability.
> the problem is mostly about GPS atmospheric delay corrections.
> i don't thinks one needs an ultra stable oscillator in a GPSDO time/freq
> standard if one is only interested in 1 PPS accuracy wrt UTC.
> there's no need for rubidium, hydrogen, or microsemi's atomic gizmo for 1
> pps accuracy
> --  an OXCO is fine.
>
> the typical GPS disciplined oscillators (eg: srs and  trimble) output 1
> PPS that have 100 ns errors from UTC.
> the best ones we have found so far are made by endrun technologies (<  10
> ns error wrt UTC).
>
> endrun claims to have unique algorithms for GPS atmospheric correction.
> although one can do next day GPS atmospheric correction for atmospheric
> delays
> (the next day, there are correction tables available for the previous day
> that are location/satellite dependent),
> endrun technologies can do some fairly accurate measurements and
> atmospheric delay corrections in near real time.
> we'd prefer not to use next day correction tables in our application.
>
> has anybody used GPSDO time/freq standards that have < 10 ns accuracy wrt
> UTC?
> has anybody used the endrun technologies standards ?
> has anybody used GPSDO products from microsemi?
>
> https://www.microsemi.com/product-directory/clocks-frequency-references/3826-gps-disciplined-oscillators-gpsdo
> the GPSDO's listed at the bottom of that page have 10 ns wrt utc.
>
> best wishes,
>
> dan
>
>
>
> On Thu, Mar 7, 2019 at 8:57 AM Robert F. Jarnot <
> robert.f.jar...@jpl.nasa.gov> wrote:
>
>> Dan,
>>
>> I looked into GPS disciplined oscillators for a project, and ended up
>> using atomic clocks instead, as they are now very small, can be flown, and
>> have remarkably low power consumption. We have 2 of them, $7500 each. See
>> https://www.microsemi.com/product-directory/clocks-frequency-references/3824-chip-scale-atomic-clock-csac
>>
>> I suspect that a good choice of GPS disciplined oscillators would
>> work pretty much as well, and be cheaper.
>>
>> Bob
>> On 3/7/19 8:51 AM, Dan Werthimer wrote:
>>
>>
>>
>> in a somewhat related question.
>>
>> can anybody give us advice about GPS disciplined oscillators time/freq
>> standards that are very accurate wrt UTC?
>> we don't want to buy a hydrogen maser (too pricy).
>> we have been looking at a company called endrun technologies that sell
>> time/freq standards accurate to about +-10 ns wrt UTC.
>> they might be able to match a pair of them that track each other +- 3ns
>> RMS.
>> we need a pair of well matched time/freq standards for coincidence time
>> stamping/correlation between two observatories for our panoseti experiment.
>> (the two optical/IR observatories are 500 km apart, and don't have
>> masers).
>>
>> thanks for any advice on this.
>>
>> btw, we are using white rabbit for time/frequency distribution over 1 Gbe
>> bidi fiber,
>> and we put the white rabbit hardware (VCO and DAC chips) and software on
>> our FPGA boards for this project.
>> (we made our own FPGA boards with white rabbit and kintex7 because we
>> need a few thousand boards)
>> white rabbit does sub-ns accuracy in timing distribution - some white
>> rabbit users have measured 30 ps RMS.
>>
>> best wishes,
>>
>> dan
>>
>>
>> On Thu, Mar 7, 2019 at 12:05 AM Michael Inggs  wrote:
>>
>>> Hi Franco
>>>
>>> Simon Lewis in the RRSG at UCT has White Rabbit hardware and expertise
>>> (PhD incubating). Snag is that it runs on 1GE Fibre. We also have a GPS
>>> version. The former gives sub ns precision, the latter about 4 ns rms. Send
>>> me a message off line and I can link you. We also have a scheme of aligning
>>> a trigger to both a local MHz clock and the 1 pps. This is all open source
>>> hardware and software.
>>>
>>> Regards
>>>
>>> On Thu, 7 Mar 2019 at 08:52, James Smith  wrote:
>>>
 Hello Franco,

 As I understand it, PTP wasn't terribly useful in our application
 (though I wasn't involved with this directly). You can probably sync the
 little Linux instance that runs on the ROACH2, but getting the time
 information onto your FPGA may prove somewhat tricky.

 Are you using an ADC card in the ROACH2? Or is the data digitised
 separately?

 What we've done with ROACH and ROACH2 designs in the past is more or
 less this:
>>>

Re: [EXTERNAL] [casper] seeking high accuracy GPS disciplined time/frequency standards ?

[John Ford]

Hi Dan.  I've been thinking about this a bit over the weekend, and I think
the problem can be solved by dividing the problem.  I think the frequency
standard should not be coupled to GPS, rather a free-running rubidium or
better oscillator could provide sufficient frequency stability and could
also generate a local clock.  The CLOCK, then can be either referenced or
calibrated somehow (postprocessed GPS time + ?) to UTC.  The local clocks
at the N sites then would not be slaved to GPS, but rather to their own
frequency standard, corrected as needed by filtered/corrected GPS time.

Green Bank does this to some extent, without closing the loop.  The
hydrogen maser drives a counter, which provides 1 PPS.  But this one PPS is
NOT slaved to GPS, but rather the GPS signal is used to measure the offset
from GPS.  The offset is then supplied to the users for their
calculations.  The system drifts some microseconds per year.  Eventually
the time gets resynced to GPS, when someone decides it's time, or when
something happens to force it.  Like a power/UPS outage.

I think you could build such a system that would be accurate to << 10 ns
with respect to UTC using GPS and doing corrections to the GPS TIME after
the fact, and feeding forward the errors into your clock.  The corrections
would be a day late, but presumably you are not going to rely on raw GPS,
rather on the time-corrected GPS time.  In the meantime your clock will
freewheel with your oscillator, which will be extremely accurate anyway.

John



On Sat, Mar 9, 2019 at 3:08 PM Dan Werthimer  wrote:

>
> hi david,
>
> i'm not an expert in atmospheric delay correction and gps,  but if you are
> interested,
> i think there are several papers about what corrections gps can do and
> what it can't do.
> some references are listed at the end of:
>
> https://en.wikipedia.org/wiki/Error_analysis_for_the_Global_Positioning_System
>
> the best GPSDO's on the market provide errors of around 10 ns RMS wrt UTC.
> i think most of this error is due to variable atmospheric delays that can
> not be removed
> (eg:  dispersion errors can be measured and removed, but other propogation
> delay errors can not be removed).
>
> best wishes,
>
> dan
>
>
>
> On Fri, Mar 8, 2019 at 11:25 PM Forbes, David C - (dforbes) <
> dfor...@email.arizona.edu> wrote:
>
>> That's an interesting question, Dan. You seek a low cost oscillator that
>> follows GPS without following it too closely.
>> Do you have a plot of a typical day of GPS atmospheric disturbance?
>>
>>
>> On Mar 8, 2019 2:55 PM, Dan Werthimer  wrote:
>>
>> hi robert, randall,  dale and casperites,
>>
>> thanks for your time/freq standard suggestions.
>>
>> our problem to get accurate 1 PPS wrt UTC is not limited by internal
>> oscillator stability.
>> the problem is mostly about GPS atmospheric delay corrections.
>> i don't thinks one needs an ultra stable oscillator in a GPSDO time/freq
>> standard if one is only interested in 1 PPS accuracy wrt UTC.
>> there's no need for rubidium, hydrogen, or microsemi's atomic gizmo for 1
>> pps accuracy
>> --  an OXCO is fine.
>>
>> the typical GPS disciplined oscillators (eg: srs and  trimble) output 1
>> PPS that have 100 ns errors from UTC.
>> the best ones we have found so far are made by endrun technologies (<  10
>> ns error wrt UTC).
>>
>> endrun claims to have unique algorithms for GPS atmospheric correction.
>> although one can do next day GPS atmospheric correction for atmospheric
>> delays
>> (the next day, there are correction tables available for the previous day
>> that are location/satellite dependent),
>> endrun technologies can do some fairly accurate measurements and
>> atmospheric delay corrections in near real time.
>> we'd prefer not to use next day correction tables in our application.
>>
>> has anybody used GPSDO time/freq standards that have < 10 ns accuracy wrt
>> UTC?
>> has anybody used the endrun technologies standards ?
>> has anybody used GPSDO products from microsemi?
>>
>> https://www.microsemi.com/product-directory/clocks-frequency-references/3826-gps-disciplined-oscillators-gpsdo
>> the GPSDO's listed at the bottom of that page have 10 ns wrt utc.
>>
>> best wishes,
>>
>> dan
>>
>>
>>
>> On Thu, Mar 7, 2019 at 8:57 AM Robert F. Jarnot <
>> robert.f.jar...@jpl.nasa.gov> wrote:
>>
>>> Dan,
>>>
>>> I looked into GPS disciplined oscillators for a project, and ended
>>> up using atomic clocks instead, as they are now very small, can be flown,
>>> and have remarkably low power consumption. We have 2 of them, $7500 each.
>>> See
>>> https://www.microsemi.com/product-directory/clocks-frequency-references/3824-chip-scale-atomic-clock-csac
>>>
>>> I suspect that a good choice of GPS disciplined oscillators would
>>> work pretty much as well, and be cheaper.
>>>
>>> Bob
>>> On 3/7/19 8:51 AM, Dan Werthimer wrote:
>>>
>>>
>>>
>>> in a somewhat related question.
>>>
>>> can anybody give us advice about GPS disciplined oscillators time/freq
>>> standards that are v

Re: [casper] Issues with setting up a ROACH2

[John Ford]

The message comes from uboot, so it's worth trying to reload that.
Otherwise you may have a true hardware failure.  :(

John


On Tue, Mar 19, 2019 at 6:59 AM Michael Peel  wrote:

> Hi Heystek,
>
> Thanks for the reply and the link. The memory error appears immediately
> after the roach is turned on, before the option to stop the autoboot
> appears. Sometimes it does continue a bit beyond that before stalling, so
> I’ll look at trying to do a uboot update when it next does that.
>
> The links to the images on the webpage don’t work (the casper svn no
> longer exists?), are the latest versions stored elsewhere now - perhaps
> they the ones on the ska-sa git?
>
> Thanks,
> Mike
>
> On 17 Mar 2019, at 14:40, Heystek Grobler 
> wrote:
>
> Hey Michael
>
> Did you try this procedure?
>
> https://casper.ssl.berkeley.edu/wiki/ROACH_kernel_uboot_update
>
> Did you manage to solve it?
>
> Heystek
>
> On Fri, Mar 15, 2019 at 5:45 PM Michael Peel  wrote:
>
>> Hi all,
>>
>> I’m currently trying to set up a ROACH2 (for the first time), and have
>> run into a number of problems. The bottom line is that I’m currently
>> getting this memory error message:
>>
>> U-Boot 2011.06-rc2-0-g2694c9d-dirty (Dec 04 2013 - 20:58:06)
>> CPU: AMCC PowerPC 440EPx Rev. A at 533.333 MHz (PLB=133 OPB=66 EBC=66)
>>  No Security/Kasumi support
>>  Bootstrap Option C - Boot ROM Location EBC (16 bits)
>>  32 kB I-Cache 32 kB D-Cache
>> Board: ROACH2
>> I2C: ready
>> DRAM: 512 MiB
>> Memory error at , wrote , read 273218ff !
>>
>> This follows from the casperfpga software being able to connect to the
>> ROACH2, but unable to load the .fpg file onto it. That led to me attempting
>> to update the romfs using ‘run tftproot’, but it could not get an IP
>> address from the computer (DHCP/dnsmasq configuration issues on RHEL7 that
>> I still need to figure out), so it did not run the update. However, after
>> that I got a kernel panic on the onboard software, so the roach no longer
>> got to the login stage.
>>
>> I then created a USB boot drive using:
>>
>> https://github.com/ska-sa/roach2_nfs_uboot/blob/master/roach2-debian-fs-snapshot-24-10-2012.tar.gz
>> and tried to boot the roach from that, however it stalled during the boot
>> process, and on reset I got the above error message.
>>
>> Any suggestions?
>>
>> Thanks,
>> Mike
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "casper@lists.berkeley.edu" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to casper+unsubscr...@lists.berkeley.edu.
>> To post to this group, send email to casper@lists.berkeley.edu.
>>
>
> --
> You received this message because you are subscribed to the Google Groups "
> casper@lists.berkeley.edu" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to casper+unsubscr...@lists.berkeley.edu.
> To post to this group, send email to casper@lists.berkeley.edu.
>
>
> --
> You received this message because you are subscribed to the Google Groups "
> casper@lists.berkeley.edu" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to casper+unsubscr...@lists.berkeley.edu.
> To post to this group, send email to casper@lists.berkeley.edu.
>

-- 
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To post to this group, send email to casper@lists.berkeley.edu.

[casper] ML-605 board

[John Ford]

Hi all.  Does anyone have a Xilinx ML605 board that I could borrow for a
couple of months, or one you'd like to sell?   And its companion FMC
breakout board, the XM-105.

We are developing some custom hardware, and one of our ML-605 boards we are
using for debugging another part of the system is not working.  We need one
for a spare, in case we need to it before we finish debugging our new
Artix-7 based system.

Thanks for any leads!
John

-- 
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To post to this group, send email to casper@lists.berkeley.edu.

[casper] Re: ML-605 board

[John Ford]

Hi all.  I got several offers of a board to help us through this tight
spot!  Thanks to all!

John


On Tue, Apr 16, 2019 at 10:12 AM John Ford  wrote:

> Hi all.  Does anyone have a Xilinx ML605 board that I could borrow for a
> couple of months, or one you'd like to sell?   And its companion FMC
> breakout board, the XM-105.
>
> We are developing some custom hardware, and one of our ML-605 boards we
> are using for debugging another part of the system is not working.  We need
> one for a spare, in case we need to it before we finish debugging our new
> Artix-7 based system.
>
> Thanks for any leads!
> John
>

-- 
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To post to this group, send email to casper@lists.berkeley.edu.

[casper] Gigabit Ethernet

[John Ford]

Hi all.

I'm designing an FPGA based instrument control system with a gigabit
Ethernet port.  It should be easy to make this work, but alas, it's giving
me fits.

I have a Xilinx Artix-7 FPGA on the board, driving a TI PHY using the RGMII
interface from the Xilinx tri-mode Ethernet MAC core.  It mostly works, but
not completely reliably.

If I setup the PHY in analog loopback mode, which loops the packets back to
the FPGA, I can run packets at full line rate all day with no errors.  So
I'm somewhat convinced that the RGMII link is good between the FPGA and the
PHY.

If I link the board up to a computer (I've tried a couple different ones,)
I get ~5 to 10% of the packets being received with CRC errors.

Is there anyone on the list that's designed Gigabit Ethernet hardware that
could give me a hand with this?  Any ideas that jump out?  I've run our of
ideas.

Thanks for any advice.  If you are or know a good Gigabit Ethernet guru for
hire, let me know!

John

-- 
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To view this discussion on the web visit 
https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CABmH8B-suUrcdbRYvUpCqF5NuqSE8mboYxFcGj0Mv%3DGMjDoVcQ%40mail.gmail.com.

Re: [casper] Gigabit Ethernet

[John Ford]

On Friday, February 14, 2020 at 12:45:21 AM UTC-7, henno wrote:
>
> Hi John,
>
> I have a few questions / remarks / suggestions:
>
> Do you observer CRC errors in both directions or is it only from FPGA to 
> PC?
>

I think it is in both directions, but I haven't exhaustively tested the PC 
to FPGA path.
 

>
> In RGMII, the TX and RX clocks are not synced, but in loopback mode it is, 
> which might point to a metastability issue when you connect to the PC.
>
>
Thanks.  This is a good clue and one which I had not thought of.  I will 
explore this avenue.  I had thought that since my loopback showed good 
results then that part was OK.
 

> Is the PCB a custom board or a DEV-KIT? The length matching of the traces 
> is important, but the TX clock skew to the PHY is also important, since DDR 
> is used.
>

It's a custom PCB.  We matched the traces to about 10 ps of delay.  The tx 
clock is set to a 2 ns offset in the Xilinx core using a 90 degree phase 
shift on the 125 MHz clock.  I haven't experimented with changing the 
phase, or of the delay on the rx clock to rx data.  The PHY has an 
adjustment for these, but it's quantized in 0.5 ns, and that might not be 
fine enough.

Thanks for the ideas.  Looks like a fun weekend in store for me.  

:)

John
 

>
> Best,
> HK
>
> On Thu, Feb 13, 2020 at 11:50 PM John Ford  > wrote:
>
>> Hi all.
>>
>> I'm designing an FPGA based instrument control system with a gigabit 
>> Ethernet port.  It should be easy to make this work, but alas, it's giving 
>> me fits.  
>>
>> I have a Xilinx Artix-7 FPGA on the board, driving a TI PHY using the 
>> RGMII interface from the Xilinx tri-mode Ethernet MAC core.  It mostly 
>> works, but not completely reliably.
>>
>> If I setup the PHY in analog loopback mode, which loops the packets back 
>> to the FPGA, I can run packets at full line rate all day with no errors.  
>> So I'm somewhat convinced that the RGMII link is good between the FPGA and 
>> the PHY.  
>>
>> If I link the board up to a computer (I've tried a couple different 
>> ones,) I get ~5 to 10% of the packets being received with CRC errors.
>>
>> Is there anyone on the list that's designed Gigabit Ethernet hardware 
>> that could give me a hand with this?  Any ideas that jump out?  I've run 
>> our of ideas.
>>
>> Thanks for any advice.  If you are or know a good Gigabit Ethernet guru 
>> for hire, let me know!
>>
>> John
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "cas...@lists.berkeley.edu " group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to cas...@lists.berkeley.edu .
>> To view this discussion on the web visit 
>> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CABmH8B-suUrcdbRYvUpCqF5NuqSE8mboYxFcGj0Mv%3DGMjDoVcQ%40mail.gmail.com
>>  
>> <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CABmH8B-suUrcdbRYvUpCqF5NuqSE8mboYxFcGj0Mv%3DGMjDoVcQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To view this discussion on the web visit 
https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/32852c07-85b6-4c0f-b1dc-85e4574d2dc5%40lists.berkeley.edu.

Re: [casper] Gigabit Ethernet

[John Ford]

Thanks for all the info.

Well, it turns out that the clock chip was the culprit.  Although it met
the 50 PPM Ethernet frequency stability requirement, it had a LOT of
jitter.  I replaced it with a $1.98 ECS crystal oscillator (as opposed to
the MEMS oscillator, and it Just Worked.  I am amazed and very happy.



On Wed, Feb 19, 2020 at 7:23 AM Ross Martin  wrote:

> Jean,
>
> You're right.  Getting the pinout wrong on the ethernet connectors
> probably leads to false pairing rather than to loss of one wire in the pair.
>
> Regards,
>
> Ross
>
>
> On Wed, Feb 19, 2020, 3:09 AM Borsenberger Jean <
> jean.borsenber...@obspm.fr> wrote:
>
>> Hello
>>
>> Incorrect cabling would lead to force to dowgrade giga to fast, or no
>> connection at all.
>> With that hi level of CRC, I would first address a connector weakness
>> (contact not complete), or a lack of shielding in a perturbated area, and
>> most unlikely false pairing inside the cable ( all pairs are individualy
>> twisted, an if you mix two pairs...)
>> Try a cat 7 cable ( thick shielding of each pair, thick shielding of the
>> whole), and see what happens.
>> Regards
>> Jean
>> Le Mercredi, Février 19, 2020 03:33 CET, Ross Martin <
>> ross.mar...@ieee.org> a écrit:
>>
>>
>> Hi John,
>>
>> I'll throw out a possibility.  Perhaps the cabling isn't correct and
>> you're only getting connectivity on one of the two wires in the
>> differential pair.  This would work *sometimes*, which is about what you're
>> seeing.
>>
>> This might happen if you wired your own cables or connectors and laid
>> them out logically.  Cat5 connectors have an unusual pinout that's not
>> exactly logical. (At least not logical to me.)
>>
>> Regards,
>>
>> Ross
>>
>> On Tue, Feb 18, 2020, 5:47 PM John Ford  wrote:
>>
>>>
>>>
>>> I did some more testing, and I wanted to share the results.  I have done
>>> reverse loopback testing, sending the packets from the host to the PHY,
>>> where it loops back inside the PHY, and is returned to the host.  This
>>> shows packet loss on the order of the total packets being lost.  So this
>>> bit of information leads me back to the analog side of things.  Power
>>> supply?  oscillator?  PCB layout?  Our board house did 100 ohm
>>> differential, and tested it, and it is better than 10%.  The traces in the
>>> pairs are matched to a couple of mils.  Here's a drawing of the testing
>>> that's been done first the digital and analog forwarded loopback, then the
>>> reverse loopback.
>>>
>>>
>>>
>>> On Fri, Feb 14, 2020 at 12:52 AM Henno Kriel  wrote:
>>>
>>>> Hi John,
>>>>
>>>> I have a few questions / remarks / suggestions:
>>>>
>>>> Do you observer CRC errors in both directions or is it only from FPGA
>>>> to PC?
>>>>
>>>> In RGMII, the TX and RX clocks are not synced, but in loopback mode it
>>>> is, which might point to a metastability issue when you connect to the PC.
>>>>
>>>> Is the PCB a custom board or a DEV-KIT? The length matching of the
>>>> traces is important, but the TX clock skew to the PHY is also important,
>>>> since DDR is used.
>>>>
>>>> Best,
>>>> HK
>>>>
>>>> On Thu, Feb 13, 2020 at 11:50 PM John Ford  wrote:
>>>>
>>>>> Hi all.
>>>>>
>>>>> I'm designing an FPGA based instrument control system with a gigabit
>>>>> Ethernet port.  It should be easy to make this work, but alas, it's giving
>>>>> me fits.
>>>>>
>>>>> I have a Xilinx Artix-7 FPGA on the board, driving a TI PHY using the
>>>>> RGMII interface from the Xilinx tri-mode Ethernet MAC core.  It mostly
>>>>> works, but not completely reliably.
>>>>>
>>>>> If I setup the PHY in analog loopback mode, which loops the packets
>>>>> back to the FPGA, I can run packets at full line rate all day with no
>>>>> errors.  So I'm somewhat convinced that the RGMII link is good between the
>>>>> FPGA and the PHY.
>>>>>
>>>>> If I link the board up to a computer (I've tried a couple different
>>>>> ones,) I get ~5 to 10% of the packets being received with CRC errors.
>>>>>
>>>>> Is there anyone on the list that's designed Gi

Re: [casper] Dropped packets during HASHPIPE data acquisition

[John Ford]

Hi Mark.  Since the newer version has a script called
"hashpipe_irqaffinity.sh" I would think that the most expedient thing to do
is to upgrade to the newer version.  It's likely to fix some or all of this.

That said, there are a lot of things that you can check, and not only the
irq affinity, but also make sure that your network tuning is good, that
your network card irqs are attached to processes where the memory is local
to that processor, and that the hashpipe threads are mapped to processor
cores that are also local to that memory.   Sometimes it's
counterproductive to map processes to processor cores by themselves if they
need data that is produced by a different core that's far away, NUMA-wise.
And lock all the memory in core with mlockall() or one of his friends.

Good luck with it!

John




On Tue, Mar 31, 2020 at 12:09 PM Mark Ruzindana  wrote:

> Hi all,
>
> I am fairly new to asking questions on a forum so if I need to provide
> more details, please let me know.
>
> Worth noting that just as I was about to send this out, I checked and I
> don't have the most recent version of HASHPIPE with hashpipe_irqaffinity.sh
> among other additions and modifications. So this might fix my problem, but
> maybe not and someone else has more insight. I will update everyone if it
> does.
>
> I am trying to reduce the number of packets lost/dropped when running
> HASHPIPE on a 32 core RHEL 7 server. I have run enough tests and
> diagnostics to be confident that the problem is not any HASHPIPE thread
> running for too long. Also, the percentage of packets dropped on any given
> scan is between about 0.3 and 0.8%. Approx. 5,000 packets in a 30 second
> scan with a total of 1,650,000 packets. So while it's a small percentage,
> the number of packets lost is still quite large. I have also done enough
> tests with 'top', 'iostat' as well as timing HASHPIPE in between time
> windows where there are no packets dropped to diagnose the issue further. I
> (as well as my colleagues) have come to the conclusion that the kernel is
> allowing processes to interrupt HASHPIPE as it is running.
>
> So I have researched and run tests involving 'niceness' and I am currently
> trying to configure smp affinities and irq balancing, but the changes that
> I make to the smp_affinity files aren't doing anything. My plan was to have
> the interrupts run on the 20 cores that aren't being used by HASHPIPE.
> Also, disabling 'irqbalance' didn't do anything either. I also restarted
> the machine to see whether the changes made are permanent, but the system
> reverts back to what it was.
>
> I might be missing something, or trying the wrong things. Has anyone
> experienced this? And could you point me in the right direction if you have
> any insight?
>
> If you need anymore details, please let me know. I didn't add as much as I
> could because I wanted this to be a reasonably sized message.
>
> Thanks,
>
> Mark Ruzindana
>
> --
> You received this message because you are subscribed to the Google Groups "
> casper@lists.berkeley.edu" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to casper+unsubscr...@lists.berkeley.edu.
> To view this discussion on the web visit
> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CA%2B41hpxcwSQT-EsjuyqXpGmmBzykDeLt6JbfUUg_ZYpkXyat2w%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To view this discussion on the web visit 
https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CABmH8B_4MoNDsO4yZNYH608u6DVtbSPkKz0YBS8%2Bb%3DffqS%3DwaA%40mail.gmail.com.

Re: [casper] Dropped packets during HASHPIPE data acquisition

[John Ford]

Hi Mark.  Spelunking through the hashpipe_pktsock.h  header file I see that

#define PKT_UDP_DATA(p) (PKT_NET(p) + 0x1c)

In your code you posted earlier, you have this:

memcpy(dest_p, payload, PKT_UDP_SIZE(frame) - 16)  // Ignore both UDP (8
bytes) and packet header (8 bytes)

Have you verified that all these magic numbers add up, that is, the 16 and
the 0x1c, and other constants such as these?  It seems clear from your
description that you are trying to read from unallocated memory, but it's
difficult to see where from the snippets of code we have.  Also, make sure
that any pointer arithmetic uses the correct casts before adding the
offsets.



On Mon, Nov 30, 2020 at 3:45 PM Mark Ruzindana  wrote:

> Hi David,
>
> Hope everything is fine. It's okay if you haven't seen it yet or forgot,
> but I'm still struggling with this issue. Would you mind giving me some
> thoughts on it if you have any? Here is the issue again, along with a
> summary of what I did to catch you up, just in case you need it:
>
> I was able to install hashpipe with the suid bit set as you suggested
> previously. So far, I have been able to capture data with the first round
> of frames of the circular buffer i.e. if I have 160 frames, I am able to
> capture packets of frames 0 to 159 at which point right at the memcpy()
> in the process_packet() function of the net thread, I get a segmentation
> fault.
>
> And the suggestions that you provided were very helpful with diagnosis,
> but the problem hasn't been resolved yet.
>
> I'm currently using gdb to debug and it either tells me that I have a
> segmentation fault at the memcpy() in process_packet() or something very
> strange happens where the starting mcnt of a block greatly exceeds the mcnt
> corresponding to the packet being processed and there's no segmentation
> fault because the mcnt distance becomes negative so the memcpy() is
> skipped. Hopefully that wasn't too hard to track. Very strange problem that
> only occurs with gdb and not when I run hashpipe without it. Without gdb, I
> get the same segmentation fault at the end of the circular buffer as
> mentioned above.
>
> I also omitted the "+ input_databuf_idx(...)" to test for buffer overflow,
> and the same result (segmentation fault).
>
> I checked to make sure that the blocks are large enough for the number of
> frames. Right now, I have 480 total frames and 60 blocks so 8 frames per
> block. And my frame size (8192) is a multiple of the kernel page size
> (4096). I've also tried frame sizes 4096, and 16384 with the same results.
>
> I tried using 'hashpipe_dump_databuf -b "block number"' and I see binary
> symbols in stdout regardless of what values I put in memset(). So that part
> wasn't as helpful with diagnosis as I'd hoped.
>
> I should also mention that there is data being received on the same
> interface from other ports, but the code ignores data from them as far as I
> can tell, and only captures/processes data from the user suggested port.
> But maybe somehow it's causing these issues and I'm not able to see how.
>
> As a test, I also tried removing the release_frame() function after
> process_packet() is called and I got the same segmentation fault. So I
> still think there's something about the implementation of the
> release_frame() function that I'm not doing or it's not releasing the
> frame. I'm not sure.
>
> I appreciate any feedback. I'll respond ASAP if you have any questions.
>
> Thanks,
>
> Mark Ruzindana
>
> On Fri, Oct 2, 2020 at 12:23 AM Mark Ruzindana 
> wrote:
>
>> Hi David,
>>
>> Sorry it's been a while, I've been working on other tasks besides the
>> packet socket implementation and I've gotten the opportunity to come back
>> to it. I know you have access to the previous emails, but just to catch you
>> up with a summary of what the issue was in implementing packet sockets:
>>
>> I was able to install hashpipe with the suid bit set as you suggested
>> previously. So far, I have been able to capture data with the first round
>> of frames of the circular buffer i.e. if I have 160 frames, I am able to
>> capture packets of frames 0 to 159 at which point right at the memcpy() in
>> the process_packet() function of the net thread, I get a segmentation fault.
>>
>> And the suggestions that you provided were very helpful with diagnosis,
>> but the problem hasn't been resolved yet.
>>
>> I'm currently using gdb to debug and it either tells me that I have a
>> segmentation fault at the memcpy() in process_packet() or something very
>> strange happens where the starting mcnt of a block greatly exceeds the mcnt
>> corresponding to the packet being processed and there's no segmentation
>> fault because the mcnt distance becomes negative so the memcpy() is
>> skipped. Hopefully that wasn't too hard to track. Very strange problem that
>> only occurs with gdb and not when I run hashpipe without it. Without gdb, I
>> get the same segmentation fault at the end of the circular buffer as
>> mentioned above.
>>
>>

Re: [casper] How to check or modify the network setting on ROACH2 ?

[John Ford]

Hi.  Since you can receive 1500 packets error-free, it seems like your PC
is getting more data than it can handle and starts losing packets.As
Jack says, the PPC doesn't get involved in it at all.

Using small packets like you are using makes for more work on the PC side,
as many more interrupts need to be processed.  You might try making your
packets bigger and using jumbo packets to save on overhead.

Some things to try, besides as you said, optimizing your C++ code:
Lock all memory in place in the PC with mlockall()
If you have a multi-CPU (not multi-core) machine, make sure your processes
access the local memory on that CPU by binding them to the CPU and also the
interrupt handler CPU.  single-processor multicore machines don't have this
problem.
Tune the buffers in the kernel.  There are some mails in this archive with
reasonable values.
Tune the interface card driver.  Some settings like interrupt coalescing
will help.

You may need a buffering scheme like hashpipe or other packet processing
pipeline to smooth out the flow.

John


On Tue, Dec 22, 2020 at 3:41 AM zhang laiyu  wrote:

> Hi,Jack
>
>I realized a firmware that acquire data using ADC_MKID_4X yellow block
> and then pack the data into multi 64bits data to 10Gb yellow block in
> ROACH2.The PC receiver UDP package through 10Gb cable.The ADC_MKID_4x board
> clock is 512MHz,and the ROACH2 worked on 128MHz. I use part of Tutorial 2
> 's design to control the tx_valid port and tx_end_of_frame port of the 10Gb
> yellow block .I set the tx_valid is 1081 and the tx_end_of_frame was set
> to 1441. The UDP package is 8648 bytes less than the max capacity
> (8k+512) of 10Gb yellow block . Now,the firmware worked well. I can get
> about 1500 UDP frames without losing data in the PC server once a time. 
> Because
> every UDP frame has frame counter,so I can judge that the frames is continuous
> or not.The firmware was running continuously,and I can get right data
> from PC during different time. The frame counter is continuous. But when
> I want to receive much more packages,such as 10 packages once a time, I
> found that the fram counter is not continuous, part of the frame was lost.The
> valid data (ADC data)rate is 6.144Gb/s. (512*10^6*12bit/s)
>
>I suspect the reason of losting UDP frams coming from two sources.
> Frist, the PC server's receive program(C++) need to optimize to  realize
> high frequency and large capacity udp data receiving .  Another reason
> may be coming from the network setting of the linux system in PowerPC on
> ROACH2, I am not sure.
>
>My question is how to check and modidy the network setting of the linux
> system in ROACH2？ I want to check the max send buffer (MTU )of the PowerPC.
>  Thank you!
>
>
>
>  Cheers!
>
> >
> ZHANG Laiyu
> Phone(China)   010-88233078
> Cellphone(China)   13681385567
> E-mail:zhan...@ihep.ac.cn
> Address:   19B Yuquan Road,Shijingshan District,Beijing，China
> Department:Center for Particle Astrophysics
> Office:Astrophysics Building 205
>
> Institute of High Energy Physics, CAS
> web: http://www.ihep.cas.cn 
>
> >
>
>
>   
>
>   
>
>   
>
>   
>
>   
>
>   
>
>   
>
>   
>
>
>
>   * *
>
>
>
>
>  --
> You received this message because you are subscribed to the Google Groups "
> casper@lists.berkeley.edu" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to casper+unsubscr...@lists.berkeley.edu.
> To view this discussion on the web visit
> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/7e0e704.f595.1768a09a04f.Coremail.zhangly%40ihep.ac.cn
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To view this discussion on the web visit 
https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CABmH8B-C6nh1HdffxWxq5DLQxFDDJO6Mi1EvS_EvKLL-9-gAyQ%40mail.gmail.com.

Re: [casper] Compilation errors with FFT block

[John Ford]

> Is it still necessary in 11.x/RHEL to load/open the CASPER library
> before opening a model containing library blocks?

Yes, Henry, it is.  We have a startup.m that opens/loads the user's
libraries and starts sysgen.

Here it is.

Yes, Master<1005> more startup.m
addpath('/export/home/tokra/scratch/casper/mlib_devel_10_1/xps_library');
addpath('/export/home/tokra/scratch/casper/mlib_devel_10_1/casper_library');
addpath('/export/home/tokra/scratch/casper/mlib_devel_10_1/gavrt_library');
sysgen_startup
system_dependent('RemoteCWDPolicy','reload')
system_dependent('RemotePathPolicy','reload')
load_system('casper_library');
load_system('gavrt_library');
Yes, Master<1006>

Then of course there are all the environment variable to set.  We also
have a script for that:

Yes, Master<1006> more Startsg.sh
#!/bin/bash
source /export/home/tokra/Xilinx/11.1/settings64.sh
export MATLAB=/opt/matlab
export XILINX=/export/home/tokra/Xilinx/11.1/ISE
export XILINX_EDK=/export/home/tokra/Xilinx/11.1/EDK
export PLATFORM=lin64
export XILINX_DSP=/export/home/tokra/Xilinx/11.1/DSP_Tools/${PLATFORM}
export
BEE2_XPS_LIB_PATH=/export/home/tokra/scratch/casper/mlib_devel_10_1/xps_l
ib
export MLIB_ROOT=/export/home/tokra/scratch/casper/mlib_devel_10_1
export PATH=${XILINX}/bin/${PLATFORM}:${XILINX_EDK}/bin/${PLATFORM}:${PATH}
export
LD_LIBRARY_PATH=${XILINX}/bin/${PLATFORM}:${XILINX}/lib/${PLATFORM}:${XIL
INX_DSP}/sysgen/lib:${LD_LIBRARY_PATH}
export LMC_HOME=${XILINX}/smartmodel/${PLATFORM}/installed_lin
export PATH=${LMC_HOME}/bin:${XILINX_DSP}/common/bin:${PATH}
export INSTALLMLLOC=/opt/matlab
export TEMP=/tmp/
export TMP=/tmp/
$MATLAB/bin/matlab


John


>
> Thanks,
> Henry
>
> On 3/11/2010 11:46 PM, Nevada Sanchez wrote:
>> I've tried deleting and replacing (even creating an entirely new model)
>> with no luck. I managed to fix it be destroying the link of the FFT
>> module back to the Casper library and all is well now. Except that I
>> don't think I should have to do that.
>>
>> Anyway, I've been having another annoyance that may be related to this
>> problem. Every time I open a model, all of the casper and xps blocks
>> have bad links until I drag one of the blocks from their respective
>> libraries into the file. The libraries are in the path and they show up
>> in the library browser. Any ideas on what might be going wrong here?
>>
>> If it helps, we're running Xilinx tools version 11.4, with the latest
>> snapshot of the casper repository on RHEL 5.
>>
>> -Nevada
>>
>> On Mar 4, 2010, at 2:18 AM, Mark Wagner wrote:
>>
>>> Hi Nevada,
>>>
>>> If all your casper libraries are linked and updated, the first thing I
>>> would try is deleting the fft and replacing it with a new one from the
>>> library, then recompiling.
>>>
>>> Or try running the fft mask script from the matlab command line and
>>> see if you get any other telling errors.
>>>
>>> Mark
>>>
>>>
>>> On Wed, Mar 3, 2010 at 11:10 PM, Nevada Sanchez >> > wrote:
>>>
>>> I have a rather simples model that takes a signal stored in ram
>>> and FFT's it. However, I'm having some problems getting it to
>>> compile. I get the following errors whenever I run 'Update
>>> Diagram':
>>>
>>> + Block error: twiddle: Simulink: The LinkStatus can be set only
>>> for a linked block.
>>> + Block error: twiddle: Simulink: Error in
>>> 
>>> 'sysgen_scratch/fft/fft_biplex0/biplex_core/fft_stage_3/butterfly_direct/twiddle':
>>> Initialization commands cannot be evaluated.
>>>
>>> Could somebody help me out with this?
>>>
>>> -Nevada
>>>
>>>
>>
>

Re: [casper] Simulink/Xilinx integration

[John Ford]

I've seen this error if you have the mouse focus in a subsystem in the
model instead of the main model.  Try closing all subsystems/blocks except
for the main drawing.

John


> Hi Steve,
>
> Try opening up the System Generator block and entering in 'd7' in the
> 'clock
> pin location' field.  Then, make sure the highest level in your model file
> is selected and open bee_xps, click 'gcb' and make sure it still
> corresponds
> to your model file name, not a subsystem.  Then try running bee xps.
>
> Also, are you using 'Use explicit sample period' of 1 in your slice block?
>  If not, this might explain the error you're getting with the Slice and
> Counter.
>
> Mark
>
> On Sun, Mar 14, 2010 at 3:02 PM, Steve Maher
> wrote:
>
>> Hi Jason,
>>
>> Thanks for the reply.
>>
>> On Sun, Mar 14, 2010 at 12:10 PM, Jason Manley
>> wrote:
>>
>>> Hi Steve
>>>
>>> Are you preloading the libraries?
>>>
>>
>> I am now =)
>>
>> I get a zillion warnings in the console (mostly about parameterized
>> links)
>>  but I can now run XSG/XPS ... thanks.
>>
>>
>>
>> However, XSG fails when building the following tutorial (my version
>> attached)
>>
>> http://casper.berkeley.edu/wiki/Roach_Tutorial
>>
>> I've included *testborph_sysgen_error.log* below, but the main error
>> seems
>> to be the following:
>>
>> All Xilinx Blocks must be contained in a level of hierarchy with a
>> System Generator Token
>>
>>
>> Obviously I do have a System Generator Token.  Googling for the error
>> produced
>> http://www.xilinx.com/support/answers/24845.htm, but it's not
>> applicable.
>>
>>
>> Hmmm...
>>
>> Steve
>>
>> p.s. If I try running XPS a second time, Matlab/Simulink crashes.
>>
>>
>>
>>
>>
>>
>>
>> - Version Log
>> --
>> Version Path
>> System Generator 11.5.2275
>> C:/Xilinx/11.1/DSP_Tools/nt/sysgen
>> AccelDSP 11.5.2275
>>  C:/Xilinx/11.1/DSP_Tools/nt/AccelDSP
>> Matlab 7.9.0.529 (R2009b)   C:/Program Files/MATLAB/R2009b
>> ISE 11.4.i  C:/Xilinx/11.1/ISE
>>
>> 
>> Summary of Errors:
>> Error 0001: All Xilinx Blocks must be contained in a level of hierarc...
>>  Block: Unspecified
>> Error 0002: A summary of Sysgen errors has been written to C:/roachmo...
>>  Block:
>> Error 0003: A summary of Sysgen errors has been written to C:/roachmo...
>>  Block:
>> Error 0004: A summary of Sysgen errors has been written to C:/roachmo...
>>  Block: 'testborph/Counter'
>> Error 0005: A summary of Sysgen errors has been written to C:/roachmo...
>>  Block: 'testborph/Slice'
>>
>> 
>>
>> Error 0001:
>>
>> Reported by:
>>   Unspecified
>>
>> Details:
>> All Xilinx Blocks must be contained in a level of hierarchy with a
>> System Generator Token
>>
>> 
>>
>> Error 0001:
>>
>> Reported by:
>>
>> Details:
>> A summary of Sysgen errors has been written to
>> C:/roachmodels/testborph_sysgen_error.log
>>
>> 
>>
>> Error 0001:
>>
>> Reported by:
>>
>> Details:
>> A summary of Sysgen errors has been written to
>> C:/roachmodels/testborph_sysgen_error.log
>>
>> 
>>
>> Error 0001:
>>
>> Reported by:
>>   'testborph/Counter'
>>
>> Details:
>> A summary of Sysgen errors has been written to
>> C:/roachmodels/testborph_sysgen_error.log
>>
>> 
>>
>> Error 0001:
>>
>> Reported by:
>>   'testborph/Slice'
>>
>> Details:
>> A summary of Sysgen errors has been written to
>> C:/roachmodels/testborph_sysgen_error.log
>>
>> 
>>
>>
>

Re: [casper] Simulink/Xilinx integration

[John Ford]

> Wow, you're having a really tough time with the toolflow setup! We
> normally insist that you use the recommended versions to avoid these
> troubles, but let's continue down the debuggin' path and see where it
> leads...
>
> First, a little explanation: The "gcs" block stands for "Get Current
> System" and is there so that if by accident you started bee_xps while
> having some subsystem in the foreground (and hence bee_xps thought
> that's what you were trying to compile) that you could correct it by
> selecting the top level window (the one with the SysGen icon) and
> press this button. The text window to the left shows the design you're
> trying to compile. It should show your top-level model name and there
> should be no spaces or slashes and it should not start with a capital
> letter. As far as I can tell from your logs, this is set correctly
> already. So you would not have seen any change when pressing the gcs
> button.

Actually, I think there is a further restriction in the new versions (or
maybe it's that Linux is case sensitive and Windows is not?) that some
stuff is case sensitive throughout, and you have to avoid all upper case
names throughout the model...

>
> It seems you have a problem with sampled values. Everything within the
> sysgen domain should have a sample period set to "1". Any source
> blocks need to have this set explicitly, but subsequent blocks can
> infer the sample period from their input signals. However, this in
> itself should not cause an error, so I'll ignore it for now.

Another error I've had happen with the Linux version is that if you have
any files open in the generated code hierarchy, the build will fail, as it
can't write over/remove the files.  This includes having an editor, timing
analyser, or even a shell in the directory tree.


John


>
> Since your modified bee_xps.m has different line numberings, I can't
> make out where it's failed. Line 337 is near to a callback to copy the
> basesystem. If it's breaking here, then probably either
>   1) xcopy (on windows; linux uses copy command with different
> arguments) is not there or not functional (try typing xcopy on the
> command prompt) or,
>   2) your environment variables are not setup correctly to point to the
> base systems. We usually do this in a batch file that's used to start
> matlab (appended below). Specifically, you will need the following
> Windows environment variables set:
>   • MLIB_ROOT pointing to the directory where the bee_library, and
> xps_library directories are located. (eg MLIB_ROOT=c:\casper_svn
> \mlib_devel_10_1)
>   • BEE2_XPS_LIB_PATH pointing to the xps_lib directory (eg
> BEE2_XPS_LIB_PATH=%MLIB_ROOT%\xps_lib)
> Jason
>
> start_matlab.bat:
>
> set MATLAB=C:\Programs\MATLAB2007b
> set XILINX=C:\Xilinx\ISE10.1\ISE
> set XILINX_EDK=C:\Xilinx\EDK10.1\EDK
> set MLIB_ROOT=C:\casper_svn\mlib_devel_10_1
> set BEE2_XPS_LIB_PATH=%MLIB_ROOT%\xps_lib
> set RCS_BIN="C:\Program Files\TortoiseSVN\bin"
> set PATH=%RCS_BIN%;%PATH%
>
> set PATH=%XILINX%\bin\nt;%XILINX_EDK%\bin\nt;%PATH%;
>
> %MATLAB%\bin\win32\matlab.exe
>
>
>
>
> On 15 Mar 2010, at 06:56, Steve Maher wrote:
>
>> Hi,
>>
>> Further, but still failure.
>>
>> On Sun, Mar 14, 2010 at 6:14 PM, Mark Wagner > > wrote:
>> Hi Steve,
>>
>> Try opening up the System Generator block and entering in 'd7' in
>> the 'clock pin location' field.
>>
>> Okay, did it.
>>
>> I also changed Slice "Specify range as" from Upper to Lower, to be
>> the same as the tutorial
>>
>>  Then, make sure the highest level in your model file is selected
>> and open bee_xps,
>>
>> I'm new to the terminology, but I believe I only have one level in
>> my model, no?  And for John Ford's comments, I also tried
>> 'selecting' System Generator block before running (which is a little
>> askew of his comments, but the best I could do).
>>
>> click 'gcb' and make sure it still corresponds to your model file
>> name, not a subsystem.
>>
>> I have only "gcs" on my BEE XPS 1.1.  When I click it nothing happens.
>>
>>  Then try running bee xps.
>>
>>
>> I get three warnings (which don't look fatal) and then failure
>> (output below).  Looks like the error occurs in xlGenerateButton but
>> I don't know where that code is.
>>
>> Also, are you using 'Use explicit sample period' of 1 in your slice
>> block?  If not, this might explain the error you're getting with the
>> Slice and Counter.
>>
>>
>> This was already set correctly in the Counter block.
>>
>> Steve
>>
>>
>> Mark
>>
>>
>>
>>
>> Detected Unknown Unix-like OS
>> #
>> ##  System Update  ##
>> #
>> SFM DEBUG sys value: testborph
>> Warning: The model 'testborph' does not have continuous states,
>> hence Simulink is using the solver
>> 'VariableStepDiscrete' instead of solver 'ode45'. You can disable
>> this diagnostic by explicitly
>> specifying a discrete solver in the solver tab of the Configuration
>> Parameters dialog, or b

Re: [casper] Simulink/Xilinx integration

[John Ford]

> Billy Mallard wrote:
>>> I'm still investigating the 11.x flow on Linux. It's not ready for
>>> prime-time yet: I sometimes have Matlab disappearing on me, compiles
>>> that sometimes take significantly longer (22hrs), ridiculous memory
>>> usage (over 16GB) etc etc.
>>
>> my experience has been the exact opposite of what Jason is describing.
>
> Fwiw, i've been running the toolflow under Debian.  I think Jason has
> only tested under CentOS.  Neither of these is supported by Xilinx, so
> we're in the process of switching our toolflow servers to Red Hat.
>
> In fact, RHEL5 is what we started officially recommending in February:
>
> http://www.mail-archive.com/casper@lists.berkeley.edu/msg01228.html
>
> I'd strongly recommend trying Red Hat.

FWIW, I found the same thing as Billy, that is, a large design utterly
fails to build on Windows as it runs out of memory.  We run Red Hat here,
and the tools are pretty stable once we got it all figured out (thanks to
all at casper!)  There are a few differences and gotchas between the linux
and windows versions.

One is the the case sensitivity.

Another is that you can't install xilinx tools using a symbolic link. 
This annoyed our sysadmin immensely, as it complicates any upgrade
process.


In fact, our version 10.1 tools are pretty stable on Windows for smaller
designs.

John

>
> Billy
>

Re: [casper] Which error to chase?

[John Ford]

> The 'dac' yellow block _does include a gateway internally.  I believe the
> error is referring to the input data lines, but I haven't figured it out
> yet.  But I may be barking up the wrong tree because I'm trying to control
> the DAC2x1000-16 (TI DAC5681) DAC - included with our ROACH - but the
> (mask)
> description for block 'dac' is "Interface to SiBeam single Atmel
> TS86101G2B
> DAC board".  Will this work with the DAC2x1000-16?
>
> I found the 'dac_mkid' block but am struggling trying to find input
> descriptions, etc.  There's no author info in the code in
> xps_library/@xps_dac_mkid/*.  Is hunting down the authors via SVN checkins
> appropriate - or perhaps I just keep bugging the mailing list?  =}

If you already did what Jason suggested, another thing is that you have to
have some clocked circuit in there as well.  Maybe just a simple counter
driving an LED or something that won't get optimized out.

John

>
> Steve
>
>
>
> On Thu, Mar 25, 2010 at 5:38 PM, Jason Manley 
> wrote:
>
>> The "sim_out" ports on yellow blocks should include this gateway
>> internally, so this gateway block should not be necessary.
>>
>> Your rate errors are probably caused by the fact that you haven't set
>> an explicit sampling rate for the constants. Simulink tries to
>> propagate these sample rates to other blocks down the chain. Since the
>> constants have no inputs, they have nothing from which to infer the
>> sample rate. Just set it to be a sampled constant with a period of "1"
>> on all the constants blocks.
>>
>> Jason
>>
>>
>>
>> On 25 Mar 2010, at 14:24, Nevada Sanchez wrote:
>>
>> > Whenever you connect an FPGA block (something that becomes
>> > synthesized in hardware) to a simulink block (like a scope) you need
>> > to use the Gateway In/Out blocks in the Xilinx blockset. Try
>> > dropping a Gateway Out in between the DAC and the scope.
>> >
>> > -Nevada
>> >
>> > On Mar 25, 2010, at 17:20 PM, Steve Maher wrote:
>> >
>> >> After some major install/downgrade/upgrade gyrations I was able to
>> >> run the basic roach tutorial - yes! - thanks for the help.
>> >>
>> >> However, my first solo model produced two errors from different
>> >> "sources" (console vs. dialog).  See highlights in attached image.
>> >>
>> >> Since this is the first time I've ever written any FGPAish type
>> >> thingy (I'm usually coding Java), I've certainly done something
>> >> stupid.  But my usual debugging skills are diminished when
>> >> presented with two different errors.  Are they just two separate
>> >> errors?  Which one should I address first?  Any great location to
>> >> explain the errors in more detail?
>> >>
>> >> Thanks for any advice,
>> >> Steve
>> >>
>> >> p.s., the converters are outputting 9_8, which I believe is what is
>> >> needed by dac inputs
>> >>
>> >> On Mon, Mar 15, 2010 at 12:38 PM, Jason Manley
>> >>  wrote:
>> >> Actually, the most stable flow right now (at least I've found) is
>> >> Windows XP 32-bit with 10.1.3.1386 and Matlab R2007b. This is what I
>> >> would recommend.
>> >>
>> >> I'm still investigating the 11.x flow on Linux. It's not ready for
>> >> prime-time yet: I sometimes have Matlab disappearing on me, compiles
>> >> that sometimes take significantly longer (22hrs), ridiculous memory
>> >> usage (over 16GB) etc etc.
>> >>
>> >> Jason
>> >>
>> >> On 15 Mar 2010, at 09:29, Steve Maher wrote:
>> >>
>> >> >
>> >> >
>> >> > On Mon, Mar 15, 2010 at 11:55 AM, Jason Manley
>> >> >  wrote:
>> >> > Wow, you're having a really tough time with the toolflow setup! We
>> >> > normally insist that you use the recommended versions
>> >> >
>> >> > Actually, we're trying to get a quick proof of concept, so what are
>> >> > the recommended versions?
>> >> >
>> >> > FYI, this
>> >> > http://casper.berkeley.edu/wiki/Xilinx_ISE_11.4_Setup
>> >> > uses XIlinx 11.4 and I've have had a tough time finding at
>> >> > xilinx.com.  Latest download is 11.1 and then upgrade is to 11.5.
>> >> >
>> >> > I guess I should back down to 10.1, per the following
>> >> > http://casper.berkeley.edu/wiki/MSSGE_Toolflow_Setup
>> >> >
>> >> > I'm guessing you would recommend Linux over Windows, right?
>> >> >
>> >> > Thanks,
>> >> > Steve
>> >> >
>> >> >
>> >> > to avoid these
>> >> > troubles, but let's continue down the debuggin' path and see
>> >> where it
>> >> > leads...
>> >> >
>> >> > First, a little explanation: The "gcs" block stands for "Get
>> >> Current
>> >> > System" and is there so that if by accident you started bee_xps
>> >> while
>> >> > having some subsystem in the foreground (and hence bee_xps thought
>> >> > that's what you were trying to compile) that you could correct it
>> >> by
>> >> > selecting the top level window (the one with the SysGen icon) and
>> >> > press this button. The text window to the left shows the design
>> >> you're
>> >> > trying to compile. It should show your top-level model name and
>> >> there
>> >> > should be no spaces or slashes and it should not start with a
>> >> capital
>> >> 

Re: [casper] Which error to chase?

[John Ford]

>> The 'dac' yellow block _does include a gateway internally.  I believe
>> the
>> error is referring to the input data lines, but I haven't figured it out
>> yet.  But I may be barking up the wrong tree because I'm trying to
>> control
>> the DAC2x1000-16 (TI DAC5681) DAC - included with our ROACH - but the
>> (mask)
>> description for block 'dac' is "Interface to SiBeam single Atmel
>> TS86101G2B
>> DAC board".  Will this work with the DAC2x1000-16?
>>
>> I found the 'dac_mkid' block but am struggling trying to find input
>> descriptions, etc.  There's no author info in the code in
>> xps_library/@xps_dac_mkid/*.  Is hunting down the authors via SVN
>> checkins
>> appropriate - or perhaps I just keep bugging the mailing list?  =}

If the atmel 86101G2B chip isn't the same as the TI DAC5681 chip, then
it's doubtful.  mkid sounds like kinetic inductance detector stuff.  Maybe
a clue there as to the originator of the code.

John



>
> If you already did what Jason suggested, another thing is that you have to
> have some clocked circuit in there as well.  Maybe just a simple counter
> driving an LED or something that won't get optimized out.
>
> John
>
>>
>> Steve
>>
>>
>>
>> On Thu, Mar 25, 2010 at 5:38 PM, Jason Manley 
>> wrote:
>>
>>> The "sim_out" ports on yellow blocks should include this gateway
>>> internally, so this gateway block should not be necessary.
>>>
>>> Your rate errors are probably caused by the fact that you haven't set
>>> an explicit sampling rate for the constants. Simulink tries to
>>> propagate these sample rates to other blocks down the chain. Since the
>>> constants have no inputs, they have nothing from which to infer the
>>> sample rate. Just set it to be a sampled constant with a period of "1"
>>> on all the constants blocks.
>>>
>>> Jason
>>>
>>>
>>>
>>> On 25 Mar 2010, at 14:24, Nevada Sanchez wrote:
>>>
>>> > Whenever you connect an FPGA block (something that becomes
>>> > synthesized in hardware) to a simulink block (like a scope) you need
>>> > to use the Gateway In/Out blocks in the Xilinx blockset. Try
>>> > dropping a Gateway Out in between the DAC and the scope.
>>> >
>>> > -Nevada
>>> >
>>> > On Mar 25, 2010, at 17:20 PM, Steve Maher wrote:
>>> >
>>> >> After some major install/downgrade/upgrade gyrations I was able to
>>> >> run the basic roach tutorial - yes! - thanks for the help.
>>> >>
>>> >> However, my first solo model produced two errors from different
>>> >> "sources" (console vs. dialog).  See highlights in attached image.
>>> >>
>>> >> Since this is the first time I've ever written any FGPAish type
>>> >> thingy (I'm usually coding Java), I've certainly done something
>>> >> stupid.  But my usual debugging skills are diminished when
>>> >> presented with two different errors.  Are they just two separate
>>> >> errors?  Which one should I address first?  Any great location to
>>> >> explain the errors in more detail?
>>> >>
>>> >> Thanks for any advice,
>>> >> Steve
>>> >>
>>> >> p.s., the converters are outputting 9_8, which I believe is what is
>>> >> needed by dac inputs
>>> >>
>>> >> On Mon, Mar 15, 2010 at 12:38 PM, Jason Manley
>>> >>  wrote:
>>> >> Actually, the most stable flow right now (at least I've found) is
>>> >> Windows XP 32-bit with 10.1.3.1386 and Matlab R2007b. This is what I
>>> >> would recommend.
>>> >>
>>> >> I'm still investigating the 11.x flow on Linux. It's not ready for
>>> >> prime-time yet: I sometimes have Matlab disappearing on me, compiles
>>> >> that sometimes take significantly longer (22hrs), ridiculous memory
>>> >> usage (over 16GB) etc etc.
>>> >>
>>> >> Jason
>>> >>
>>> >> On 15 Mar 2010, at 09:29, Steve Maher wrote:
>>> >>
>>> >> >
>>> >> >
>>> >> > On Mon, Mar 15, 2010 at 11:55 AM, Jason Manley
>>> >> >  wrote:
>>> >> > Wow, you're having a really tough time with the toolflow setup! We
>>> >> > normally insist that you use the recommended versions
>>> >> >
>>> >> > Actually, we're trying to get a quick proof of concept, so what
>>> are
>>> >> > the recommended versions?
>>> >> >
>>> >> > FYI, this
>>> >> > http://casper.berkeley.edu/wiki/Xilinx_ISE_11.4_Setup
>>> >> > uses XIlinx 11.4 and I've have had a tough time finding at
>>> >> > xilinx.com.  Latest download is 11.1 and then upgrade is to 11.5.
>>> >> >
>>> >> > I guess I should back down to 10.1, per the following
>>> >> > http://casper.berkeley.edu/wiki/MSSGE_Toolflow_Setup
>>> >> >
>>> >> > I'm guessing you would recommend Linux over Windows, right?
>>> >> >
>>> >> > Thanks,
>>> >> > Steve
>>> >> >
>>> >> >
>>> >> > to avoid these
>>> >> > troubles, but let's continue down the debuggin' path and see
>>> >> where it
>>> >> > leads...
>>> >> >
>>> >> > First, a little explanation: The "gcs" block stands for "Get
>>> >> Current
>>> >> > System" and is there so that if by accident you started bee_xps
>>> >> while
>>> >> > having some subsystem in the foreground (and hence bee_xps thought
>>> >> > that's what you were trying to compile) that you could correct it

[casper] Troubles setting up 10 GbE on Roach

[John Ford]

HI all.  We've been working with some code taken from the workshop
tutorials, tutorial #2.  We're trying to configure the 10 gbe block using
the tut2.py example, but it doesn't actually configure anything.  Once we
run the configure script, the MAC address and IP address are the defaults
that are put in during the FPGA build.

Does anyone have an idea why this doesn't work?  Here's the script attached.

It seems to do the Right Things.

John


Parks.py
Description: Binary data

Re: [casper] Troubles setting up 10 GbE on Roach

[John Ford]

> It seems there is a limit to the length of the 10GbE core name (ie
> simulink name) of ~8 characters, which you might be exceeding (Terry
> discovered this yesterday). I keep short names (4 chars) and hadn't
> noticed this.

We'll try this.  But it doesn't even work for the tutorial, which has gbe0
and gbe3 as the names.  If you run tut2.py, it loads up and runs fine, but
the MAC addresses and IP's never get properly configured, but it works
because the defaults are legal, if bogus, i.e. mac address '123456'

>
> To help debug, try'n ssh into the roach board and do a ps aux to see
> if the tgtap process is running. If not, try'n start it manually from
> a roach ssh session:
>
> tgtap -b /proc/313/hw/ioreg/ten_Gbe_v2 -a 192.168.3.14 -t gbe0 -m
> 02:02:0A:00:00:82 -p 1

Good idea.

I need a remedial course on the innards of the katcp system...

John

>
>
> Jason
>
> On 01 Apr 2010, at 12:50, John Ford wrote:
>
>> HI all.  We've been working with some code taken from the workshop
>> tutorials, tutorial #2.  We're trying to configure the 10 gbe block
>> using
>> the tut2.py example, but it doesn't actually configure anything.
>> Once we
>> run the configure script, the MAC address and IP address are the
>> defaults
>> that are put in during the FPGA build.
>>
>> Does anyone have an idea why this doesn't work?  Here's the script
>> attached.
>>
>> It seems to do the Right Things.
>>
>> John
>> 
>

Re: [casper] Troubles setting up 10 GbE on Roach

[John Ford]

> Hi John,
>
> I had the same problem, but it was fixed after I updated my ROACH
> according to Jason's recommendations:
> http://www.mail-archive.com/casper@lists.berkeley.edu/msg01370.html

We did check this, but maybe we missed something.  We'll have another look.

>
> Also, if you just want to run the 10gbe tutorial, you can set the mac and
> ip addresses in the yellow block when you compile the design.

No, we just were dropping back to something that should have worked.  We
have our own app that we're trying to make work.

Thanks!

John

>
>
> Sean
>
>> HI all.  We've been working with some code taken from the workshop
>> tutorials, tutorial #2.  We're trying to configure the 10 gbe block
>> using
>> the tut2.py example, but it doesn't actually configure anything.  Once
>> we
>> run the configure script, the MAC address and IP address are the
>> defaults
>> that are put in during the FPGA build.
>>
>> Does anyone have an idea why this doesn't work?  Here's the script
>> attached.
>>
>> It seems to do the Right Things.
>>
>> John
>>
>
>

[casper] 6 GS/s Spectrometer

[John Ford]

Hi all.

Has anyone done a 6 GS/s spectrometer using 2 interleaved 3 GS/s ADC
boards on a ROACH?  I seem to recall someone doing something of the sort,
but I don't recall any details.

Thanks for any info!

John

Re: [casper] 6 GS/s Spectrometer

[John Ford]

Thanks for the info, all.

As you might expect, this was not an idle question.  I have a need for
this right now.  The machine I need to build is:

3 GHz bandwidth (6 GS/s)
1024 channels in the spectrometer
1 polarization
50 millisecond or less accumulations.
1 ROACH board
How should we proceed without duplicating effort already underway?  How
can we best help bring this to fruition?

John

> Yes, I think a parameter is a good idea. Maybe just a radio-box or a
> drop-down-selection in the mask. Multiple cores will confuse users
> (like everyone gets confused by the multiple FFT blocks) and will
> probably become an admin nightmare down the road.
>
> Jason
>
> On 23 Apr 2010, at 07:40, Dan Werthimer wrote:
>
>>
>>
>> hi jason,
>>
>> perhaps we can have different yellow block cores,
>> one hardened for people that need high speed input,
>> one not hardened,
>>
>> or better yet - a parameter that selects whether the
>> routing is hardened or not?
>>
>> dan
>>
>>
>>
>> On 4/22/2010 10:32 PM, Jason Manley wrote:
>>>> suraj is planning on hardening the yellow block cores
>>>> so that their routing/timing is locked down, independent
>>>> of what else is running in the fpga.
>>>
>>> Please don't make this the default behaviour. On designs that are
>>> nearly fully packed (99%), you need to be able to twiddle every
>>> part of the design to make it fit, and sometimes that means re-
>>> arranging the yellow blocks' innards. Part of the BEE2 DRAM
>>> controller was hard-routed and it caused complications when the
>>> chip got full.
>>>
>>> Jason
>>>
>>>> On 4/22/2010 2:57 PM, Mark Wagner wrote:
>>>>> Hi John,
>>>>>
>>>>> I don't think anyone has been able to get a spectrometer working
>>>>> at the full 3GS/s interleaved yet.  The best Suraj and I have
>>>>> been able to do is about 2.4Gs/s before we start running into
>>>>> serious timing issues.  We do have plans to meet soon with a
>>>>> Xilinx timing expert in the hopes of resolving our issues.
>>>>>
>>>>> Mark
>>>>>
>>>>>
>>>>> On Thu, Apr 22, 2010 at 2:12 PM, John Ford  wrote:
>>>>> Hi all.
>>>>>
>>>>> Has anyone done a 6 GS/s spectrometer using 2 interleaved 3 GS/s
>>>>> ADC
>>>>> boards on a ROACH?  I seem to recall someone doing something of
>>>>> the sort,
>>>>> but I don't recall any details.
>>>>>
>>>>> Thanks for any info!
>>>>>
>>>>> John
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
>

Re: [casper] 6 GS/s Spectrometer

[John Ford]

> Tough one with existing hardware.  I suspect two 3gsps ADC's would have to
> be
> thermally controlled to get the timing problems down.

Maybe so.  We may try to experiment with this some over the summer.

> National sell an
> "up-tested" 4gsps version of the 3gsps part - it may improve matters a
> bit, but
> the ENOB figures for the part are only shown on a graph up to 2GHz and
> even then
> it's below 6 bits and heading south.
>
> Does it have to be 8 bit?

No, we could get away with 4 or 5 bits.

Maybe that's a way to save some FPGA resources: throw away the bogus bits
and use only 4 bits out of the samples.

John

>
> -Francois
>
> John Ford wrote:
>> Thanks for the info, all.
>>
>> As you might expect, this was not an idle question.  I have a need for
>> this right now.  The machine I need to build is:
>>
>> 3 GHz bandwidth (6 GS/s)
>> 1024 channels in the spectrometer
>> 1 polarization
>> 50 millisecond or less accumulations.
>> 1 ROACH board
>> How should we proceed without duplicating effort already underway?  How
>> can we best help bring this to fruition?
>>
>> John
>>
>>> Yes, I think a parameter is a good idea. Maybe just a radio-box or a
>>> drop-down-selection in the mask. Multiple cores will confuse users
>>> (like everyone gets confused by the multiple FFT blocks) and will
>>> probably become an admin nightmare down the road.
>>>
>>> Jason
>>>
>>> On 23 Apr 2010, at 07:40, Dan Werthimer wrote:
>>>
>>>>
>>>> hi jason,
>>>>
>>>> perhaps we can have different yellow block cores,
>>>> one hardened for people that need high speed input,
>>>> one not hardened,
>>>>
>>>> or better yet - a parameter that selects whether the
>>>> routing is hardened or not?
>>>>
>>>> dan
>>>>
>>>>
>>>>
>>>> On 4/22/2010 10:32 PM, Jason Manley wrote:
>>>>>> suraj is planning on hardening the yellow block cores
>>>>>> so that their routing/timing is locked down, independent
>>>>>> of what else is running in the fpga.
>>>>> Please don't make this the default behaviour. On designs that are
>>>>> nearly fully packed (99%), you need to be able to twiddle every
>>>>> part of the design to make it fit, and sometimes that means re-
>>>>> arranging the yellow blocks' innards. Part of the BEE2 DRAM
>>>>> controller was hard-routed and it caused complications when the
>>>>> chip got full.
>>>>>
>>>>> Jason
>>>>>
>>>>>> On 4/22/2010 2:57 PM, Mark Wagner wrote:
>>>>>>> Hi John,
>>>>>>>
>>>>>>> I don't think anyone has been able to get a spectrometer working
>>>>>>> at the full 3GS/s interleaved yet.  The best Suraj and I have
>>>>>>> been able to do is about 2.4Gs/s before we start running into
>>>>>>> serious timing issues.  We do have plans to meet soon with a
>>>>>>> Xilinx timing expert in the hopes of resolving our issues.
>>>>>>>
>>>>>>> Mark
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Apr 22, 2010 at 2:12 PM, John Ford  wrote:
>>>>>>> Hi all.
>>>>>>>
>>>>>>> Has anyone done a 6 GS/s spectrometer using 2 interleaved 3 GS/s
>>>>>>> ADC
>>>>>>> boards on a ROACH?  I seem to recall someone doing something of
>>>>>>> the sort,
>>>>>>> but I don't recall any details.
>>>>>>>
>>>>>>> Thanks for any info!
>>>>>>>
>>>>>>> John
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>
>>
>>
>>
>>
>

Re: [casper] mlib_devel_10_1 and simulink 7.4

[John Ford]

> Hi Dave
>
> It may be time to copy our libraries to an mlib_devel_11_1 revision and
> continue from there. ROACH2 uses Virtex6 and the 10.x and earlier tools do
> not support it. Disadvantages are that a lot of library maintainers will
> be
> working in mlib_devel_11_1 and bug fixes, changes etc may not make it back
> into mlib_devel_10_1. It worked reasonably well with the move from
> mlib_devel_7_1 to mlib_devel_10_1 though so it probably wouldn't be a
> problem.

Hi all.

This is a serious problem, in that CASPER can't abandon earlier users and
maintain any sort of following.  We have an installed base of hardware
that will remain Virtex-II Pro for some time to come.  (As does David, of
course!)

IMO, there has to be a conscious effort to maintain tools for each
generation of hardware, at least to some point.  I think that since 10.1
is the last version to support the Virtex-II Pro, it should be kept up to
date and usable, at least for some time to come.

John

>
> Regards
> Andrew
>
>
>
> On 18 May 2010 19:58, David MacMahon  wrote:
>
>> It looks like the mlib_devel_10_1/xps_library/xps_library,mdl revision
>> committed in r3025 was saved using simulink 7,4, which seems to have
>> introduced a "SID" parameter to all the SubSystem blocks.  This causes
>> loads
>> of "does not have a parameter named 'SID'" warnings when opening up the
>> "BEE_XPS System Blockset" (and models that use it) when using the "10.1
>> -
>> Stable/Production" toolflow versions recommended at...
>>
>> http://casper.berkeley.edu/wiki/MSSGE_Toolflow_Setup
>>
>> My understanding is that 10.1 is the last System Generator version to
>> support the v2pro used on the bee2 and ibob.  It would be unfortunate if
>> some new simulink feature inadvertently rendered the 10.1 libraries
>> incompatible with the 10.1 system generator.
>>
>> Should we not agree/mandate that commits to mlib_devel_10_1 libraries
>> only
>> be made with files saved by the "10.1 - Stable/Production" toolflow
>> versions
>> that are specified on the MSSGE_Toolflow_Setup wiki page?
>>
>> Thanks,
>> Dave
>>
>>
>>
>

Re: [casper] Issue with Fujitsu FPD-010R008-0E + FOC-CCxxxx

[John Ford]

>
>
> hi shilpa,
>
> the early CX4 10Gbe spec didn't supply optional power
> through the connector, and the first revision bee2's and
> ibob's we built didn't have powered connectors.
>
> but the spec changed several years ago,  so i would have
> guessed that any modern NIC board would have powered
> connectors.   do you have a really old NIC?

No, these are pcie Myricom NIC's, some of them just purchased in September.

Shilpa told me the optical converters don't work with the Fujitsu xg-700
either.  Just with the Bee2.  Odd.

John

>
> best wishes,
>
> dan
>
>
> On 5/19/2010 1:19 PM, Shilpa Bollineni wrote:
>> Hi All,
>>
>> I'm trying to use a optical transceiver to adapt CX4 to optical fiber:
>> Fujitsu FPD-010R008-0E + FOC-CC. I'm using it for a short distance
>> of
>> 10m.  I did the loop back test on BEE2 and it works fine. So  I'm sure
>> that the cable and the module is working fine. But when I have one end
>> of
>> the cable connected to the 10Gbe NIC card on the system I don't see the
>> module getting any power from the NIC card. Does anyone know any
>> specific
>> 10Gbe NIC card that would work with these modules?
>>
>> Any suggestions?
>>
>>
>> Thanks
>>
>> Shilpa Bollineni
>>
>>
>>
>>
>>
>
>

Re: [casper] 64-bit toolflow computer?

[John Ford]

> Hi Bay,
>
> We had to move to RHEL5 (64-bit ok) to get versions above 11.3 working.
>  I've heard that CentOS works too.

And you really need 64 bit...

John


>
> Mark
>
>
> On Thu, May 20, 2010 at 3:49 PM, Bay E. Grabowski
> wrote:
>
>> We're setting up a new toolflow computer after Ubuntu stopped working.
>> Should we be installing RHEL 64-bit install or 32-bit? The wiki mentions
>> 64-bit in passing, but I remember there being some problems with 64-bit
>> earlier...
>>
>> --
>> Bay Grabowski
>> b...@umail.ucsb.edu
>>
>>
>>
>

Re: [casper] 64-bit toolflow computer?

[John Ford]

> On Thu, May 20, 2010 at 9:34 PM, John Ford  wrote:
>>> Hi Bay,
>>>
>>> We had to move to RHEL5 (64-bit ok) to get versions above 11.3 working.
>>>  I've heard that CentOS works too.
>>
>> And you really need 64 bit...
>
> We're in the process of setting up a Fedora 13 system, since it's
> annoying to have packages as old as RHEL's.  Has anyone had any
> trouble with that?

We use RHEL 5:

Yes, Master<1002> uname -a
Linux tokra 2.6.18-194.el5 #1 SMP Tue Mar 16 21:52:39 EDT 2010 x86_64
x86_64 x86_64 GNU/Linux

If you look at the list archives, you'll see a stretch where people tried
different OS's, and I think the only ones that work without problems are
RHEL and centos.  It would be a service to all if you can figure out how
to make it all work on some other OS.  But xilinx won't be able to help
you...

John

Re: [casper] 64-bit toolflow computer?

[John Ford]

Obligatory car analogy!

I have a race car that's highly modified and hand-built and tuned.  I race
it on Friday nights.  It's fun to play with, drive, and work on.

But I drive my old subaru station wagon to work most days (unless we take
my  wife's Legacy GT turbo...), because I just want to get to work, not
play with the car.

Now, you young whippersnappers stay off my lawn while you play with your
newfangled OS and other toys...

:)

John


> I too find RHEL a very frustrating OS to use on a day-to-day basis.
> But it seems the Xilinx tools rely on some of those ancient libraries
> that RedHat packages. We've had some success with installing newwer
> Debian-based distros, and then manually adding the older libraries
> (perl is the big annoyance). But this is far from reliable and not
> recommended. As Dan says, we've found some quirky behaviour where some
> designs compile and others do not.
>
> If you insist on running something other than RHEL (as I do), then I
> can suggest you get yourself a copy of the full RHEL5 root filesystem
> and do a chroot before starting matlab/xilinx tools. It works
> reliably, but is painful to setup (not to mention that it consumes
> ~20GB of diskspace). This is not something a Linux newbie should try
> and is not recommended for those who are not familiar with these tools
> and concepts. You can also do things like faking the hostname (using
> chname) and the ethernet adaptor's MAC (must be eth0; set up a null
> tap device) to ease licensing troubles when upgrading or moving your
> compile environment to a different hardware platform. In this way, as
> far as the toolflow is concerned, the system is RedHat (apart from the
> kernel, which is mostly the same).
>
> I mention this to illustrate that there are other toolflow
> possibilities. But please note that this is not a CASPER recommended
> configuration and we can not (and will not) offer support for anything
> other than a vanilla RHEL5 install.
>
> Jason
>
> On 21 May 2010 05:54, Dan Werthimer  wrote:
>>
>> hi bay, andy,
>>
>> i strongly recommend using Xilinx supported operating systems
>> (eg: RHEL5).
>>
>> we've encountered some very strange bugs with other
>> linux variants - these bugs don't appear like they might be operating
>> system
>> related, but when we switched over to RHEL5, the bugs vanished.
>>
>> also, xilinx will refuse to answer questions if you aren't using one of
>> the
>> operating systems they support.
>>
>> i'm hoping the bulk of the casper community will use RHEL5 or another
>> xilinx supported system so we can all help each other.
>>
>> our group has switched to RHEL5 and i recommend it to other groups.
>>
>> dan
>>
>>
>>
>>
>>
>> On 5/20/2010 6:39 PM, Andrew Lutomirski wrote:
>>>
>>> On Thu, May 20, 2010 at 9:34 PM, John Ford  wrote:
>>>
>>>>>
>>>>> Hi Bay,
>>>>>
>>>>> We had to move to RHEL5 (64-bit ok) to get versions above 11.3
>>>>> working.
>>>>>  I've heard that CentOS works too.
>>>>>
>>>>
>>>> And you really need 64 bit...
>>>>
>>>
>>> We're in the process of setting up a Fedora 13 system, since it's
>>> annoying to have packages as old as RHEL's.  Has anyone had any
>>> trouble with that?
>>>
>>> (There's also RHEL6 Beta, but I haven't gotten that to install without
>>> crashing, so I don't think it's quite ready for prime time.)
>>>
>>> --Andy
>>>
>>>
>>>>
>>>> John
>>>>
>>>>
>>>>
>>>>>
>>>>> Mark
>>>>>
>>>>>
>>>>> On Thu, May 20, 2010 at 3:49 PM, Bay E. Grabowski
>>>>> wrote:
>>>>>
>>>>>
>>>>>>
>>>>>> We're setting up a new toolflow computer after Ubuntu stopped
>>>>>> working.
>>>>>> Should we be installing RHEL 64-bit install or 32-bit? The wiki
>>>>>> mentions
>>>>>> 64-bit in passing, but I remember there being some problems with
>>>>>> 64-bit
>>>>>> earlier...
>>>>>>
>>>>>> --
>>>>>> Bay Grabowski
>>>>>> b...@umail.ucsb.edu
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>
>

Re: [casper] 64-bit toolflow computer?

[John Ford]

> Hi Mandana
>
> Yes, things have definitely improved since the early Linux versions. I
> am now running Matlab R2008b and Xilinx 11.5 on RHEL5 Linux and am
> reasonably happy with it. Matlab still segfaults from time-to-time,
> but it's manageable.  There are still a few quirks (eg Simulink
> doesn't have a taskbar under Linux, dragging blocks sometimes
> dissapear etc) but they're all minor.
>
> 10.1 under Windows is stable, but will not be used moving forward
> (ROACH-II will require a lot of memory for larger designs, more than
> any 32-bit windows can handle). CASPER is now recommending RHEL5 as
> the OS of choice for the 11.x toolflow, and will likely be the case
> for 12.x and onwards. For this reason, I recommend you switch to
> Linux.

A full or nearly full ROACH-1 chip (sx-95) will also exceed the memory
limit imposed by Windows.  We also have a Linux install and it is better. 
It's faster, and allows bigger designs.

Same setup as Jason described above.

John

>
> Also, if possible, I strongly recommend you try to install things with
> their defaults (standard locations, no symlinks or network drives
> etc). This makes it much easier to support and we can more easily help
> you track down any problems you might have.
>
> Jason
>
> On 22 May 2010 01:52, Mandana Amiri  wrote:
>> Hi,
>>
>> We are going to use the Roach board (arriving soon!) for a
>> proof-of-concept
>> design. I am in the process of setting up the toolflow and I need to
>> decide
>> between windows versus RHEL. I read the following thread dated
>> mid-March:
>>
>> http://www.mail-archive.com/casper@lists.berkeley.edu/msg01328.html
>>
>> Has this recommendation changed since?
>>
>> Thanks,
>> Mandana
>>
>>
>> Jason Manley wrote:
>>>
>>> I too find RHEL a very frustrating OS to use on a day-to-day basis.
>>> But it seems the Xilinx tools rely on some of those ancient libraries
>>> that RedHat packages. We've had some success with installing newwer
>>> Debian-based distros, and then manually adding the older libraries
>>> (perl is the big annoyance). But this is far from reliable and not
>>> recommended. As Dan says, we've found some quirky behaviour where some
>>> designs compile and others do not.
>>>
>>> If you insist on running something other than RHEL (as I do), then I
>>> can suggest you get yourself a copy of the full RHEL5 root filesystem
>>> and do a chroot before starting matlab/xilinx tools. It works
>>> reliably, but is painful to setup (not to mention that it consumes
>>> ~20GB of diskspace). This is not something a Linux newbie should try
>>> and is not recommended for those who are not familiar with these tools
>>> and concepts. You can also do things like faking the hostname (using
>>> chname) and the ethernet adaptor's MAC (must be eth0; set up a null
>>> tap device) to ease licensing troubles when upgrading or moving your
>>> compile environment to a different hardware platform. In this way, as
>>> far as the toolflow is concerned, the system is RedHat (apart from the
>>> kernel, which is mostly the same).
>>>
>>> I mention this to illustrate that there are other toolflow
>>> possibilities. But please note that this is not a CASPER recommended
>>> configuration and we can not (and will not) offer support for anything
>>> other than a vanilla RHEL5 install.
>>>
>>> Jason
>>>
>>> On 21 May 2010 05:54, Dan Werthimer  wrote:
>>>
>>>>
>>>> hi bay, andy,
>>>>
>>>> i strongly recommend using Xilinx supported operating systems
>>>> (eg: RHEL5).
>>>>
>>>> we've encountered some very strange bugs with other
>>>> linux variants - these bugs don't appear like they might be operating
>>>> system
>>>> related, but when we switched over to RHEL5, the bugs vanished.
>>>>
>>>> also, xilinx will refuse to answer questions if you aren't using one
>>>> of
>>>> the
>>>> operating systems they support.
>>>>
>>>> i'm hoping the bulk of the casper community will use RHEL5 or another
>>>> xilinx supported system so we can all help each other.
>>>>
>>>> our group has switched to RHEL5 and i recommend it to other groups.
>>>>
>>>> dan
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 5/20/2010 6:39 PM, Andrew Lutomi

[casper] "dual-boot" ibob?

[John Ford]

Hi all.

Is it possible to put 2 personalities in an ibob, so that you can select
the personality with a jumper or switch?

John

Re: [casper] "dual-boot" ibob?

[John Ford]

> Hi John,
>
> If I remember correctly, it should have been possible, but alas is not.
>
> The ability is actually built into the Platform Flash PROM chip, and
> the selection jumpers are on the board (one of the set of 3x2 headers
> by the PROM). Unfortunately, the 32Mb PROM isn't capable of storing
> more than 1 2VP50 bitstream, each of which is just a hair over 19Mb.
>
> I think we explored this a while back, when ATA was starting to
> build up large racks of IBOBs and wanted to switch between test and
> observation modes. We found that the PROM chip actually is capable
> of handling compression, but there was something with the way the
> configuration clocks are cascaded that makes the feature unsupported.
>
> So bottom line is: parts of the ability are there, but there are some
> missing pieces that might be a very large pain to hack in.

Thanks, Henry.  I thought as much.

We'll just reflash them for our purposes.  It's not too big a deal.  I
guess we need to move on to roach boards...

John

>
>
> Thanks,
> Henry
>
> On 5/24/2010 11:39 AM, John Ford wrote:
>> Hi all.
>>
>> Is it possible to put 2 personalities in an ibob, so that you can select
>> the personality with a jumper or switch?
>>
>> John
>>
>>
>>
>>
>>
>

Re: [casper] ibob lwip on 10.1

[John Ford]

> Thanks, Glenn,
>
> I have not added any PPC code and I am using the 10.1 tools installed
> at BWRC, so I assumed those were not the problem, but I just now
> built a simple test design with LWIP using the 10.1 tools and it worked!
>
> My guess is that sw registers and such cause the code to grow and
> once you exceed a certain point - ka-boom!  At least now I think I
> know where to look...

There's an compiler optimization option that can help.  It optimizes for
size instead of speed.  I can't remember the specifics but I can look
tomorrow...

John

>
> Thanks again,
> Dave
>
> On May 25, 2010, at 16:17 , G Jones wrote:
>
>> These messages mean that your PowerPC code is too large. This a
>> common occurrence when using LWIP. You need to reduce your code
>> size some how. One way I've done this is by removing verbose error
>> messages from the .c files in the drivers directory.
>>
>> If you haven't added any PowerPC code, make sure all of your ISE/
>> EDK are patched to the correct version. For 7.1, there was an EDK
>> patch that was necessary to avoid this problem.
>>
>> Glenn
>>
>> On Tue, May 25, 2010 at 4:13 PM, David MacMahon
>>  wrote:
>> I'm trying to build an ibob design with LWIP on 10.1, but I get
>> this error at link time...
>>
>> /vol/hitz/tools/commercial/xilinx/10.1/EDK/gnu/powerpc-eabi/lin64/
>> bin/../lib/gcc/powerpc-eabi/4.1.1/../../../../powerpc-eabi/bin/ld:
>> region plb_bram_if_cntlr_1 is full (Software/executable.elf
>> section .data)
>>
>> ... followed by a bunch of "section XXX overlaps section .text" and
>> a bunch of "section XXX oerlaps previous sections" messages.
>>
>> Does the "IBOB LWIP" block work under 10.1?
>>
>> Thanks,
>> Dave
>>
>>
>>
>
>

[casper] GPU Spectrometer

[John Ford]

Hi all.

I know folks are working on a hybrid spectrometer using roach/ibob and
GPU's.  I am in need of a 1M channel, 2 pol, 400 MHz spectrometer.  Anyone
offer up their design as a possibility?  I think GUPPI maybe could do it,
but I wonder if anyone else has gotten anything going.  Or could you build
such beast with just a roach or 2?

John

Re: [casper] GPU Spectrometer

[John Ford]

> Hi John.
>
>>
>>
>> I know folks are working on a hybrid spectrometer using roach/ibob and
>> GPU's.  I am in need of a 1M channel, 2 pol, 400 MHz spectrometer.
>> Anyone
>> offer up their design as a possibility?  I think GUPPI maybe could do
>> it,
>> but I wonder if anyone else has gotten anything going.  Or could you
>> build
>> such beast with just a roach or 2?
>>
>>
>>
>>
> A while ago I made a 1M channel, single pol, 500 MHz spectrometer on a
> single ROACH. The project folder is here:
> http://casper.berkeley.edu/svn/trunk/projects/roach_mspec/
>
> Have a look at the block diagram, which should give an idea of the design:
> http://casper.berkeley.edu/svn/trunk/projects/roach_mspec/doc/roach_mspec.pdf
>
> The FPGA utilization was as follows:
> 90% of slices, 21% DSP, 35% BRAM
>
> There was also lot of room for optimisation. For example, the qdr vector
> accumulator + DRAM buffer could have been replaced just a DRAM vector
> accumulator. Also lots of slices could be freed up by using DSPs. The
> other
> bonus is you would clock your FPGA 50 Mhz slower.
>
> I think you could comfortably do dual-pol with 2 ROACHs.

Thanks, David.  We've played with this design a bit, but I forgot its
characteristics.

John

>
> Cheers,
> David
>
>
>
>
> --
> David George
> Karoo Array Telescope
> Tel: +27 21 531-7282
> Email: david.geo...@ska.ac.za
>

Re: [casper] Fedora 13 FTW

[John Ford]

> We have two new lab machines running Fedora 13 64-bit.  They both have
> Xilinx 11.4 (I think).  One has Matlab 2009b and one has 2010a.  Both
> seem to work (they build bof files OK).
>
> What's supposed to break?

The sysgen/EDK stuff that uses perl scripts seems to be the weak(est?) link.

>From the mailing list archive 09 Feb 2010 by Dan Werthimer:

Specific Recommendation
--


For anyone using or planning to install the 11.x SG/ISE/EDK toolflow under
linux, we recommend you install on a Red Hat Enterprise Linux 5 (RHEL5)
distribution

or other Xilinx supported operating system.

There are several reasons we recommend this change:


1. RHEL5 is one of a small number of operating systems supported by Xilinx.

 Others are listed at http://www.xilinx.com/ise/ossupport/index.htm

2.   If you want support from Xilinx,  (eg: ask questions, etc)
  Xilinx will insist you use one of these operation systems.

3.  We've only been able to get the 11.4 toolflow to work on RHEL5.

11.3 has been mostly working under Debian/Ubuntu, but is no longer
available on the Xilinx website. When generating with SG 11.4 under
Debian/Ubuntu, there is a MasterScriptxx.pl error that is unresolved.

4. We've encountered several subtle bugs that at first don't appear
related to choice of operating system,

  but these bugs vanish when we run the tools under RHEL5.

For instance, Terry ran into a problem trying to ROM with 13 address bits
using distributed memory;

  this errors out under Debian/Ubuntu but compiles fine under RHEL5.
  (this ROM is used in the FFT unscrambler for Npoints >=8K)


5. There could be unforeseeable consequences (more subtle bugs) using an
unsupported OS.


John

>
> --Andy
>

Re: [casper] GCC error

[John Ford]

> Hi All,
>
> We're trying to get the version 11 tools running on RHEL5, and we've run
> into a problem.  When we try to simulate designs involving Xilinx blocks
> (without any Casper blocks), we get the following error:
>
> "Program "gcc" returned non-zero status (1).
>
> Error occurred during "Simulation Initialization"."

Can you send the .mdl file?

John


>
> The design consisted of a System Generator block, and a Xilinx sampled
> constant sent through a gateway to a scope.  The error occurred for the
> sampled constant.
>
> We're running:
> RHEL 5.1.19.6
> Matlab 2009b
> Xilinx ISE 11.5
>
>
> Has anybody ran into this issue?  Any suggestions?
>
> Thanks,
> Matthew
> __
> Matthew Stevenson
> Graduate Student of Astrophysics
>
> Ph: (626) 395-4095
> Fax: (626) 568-9352
> E-mail: m...@astro.caltech.edu
>
>
>
>
>
>
>

Re: [casper] GCC error

[John Ford]

> Hi John,
>
> The .mdl file is attached.

Hi Matthew.

This simulated fine for me on my 11.3 system, modulo the warnings about
being created on a newer version...

Of course, bee_xps complains bitterly about the lack of the MSSGE block if
you try to build it.

John


>
> Matthew
>
>
>
>>> Hi All,
>>>
>>> We're trying to get the version 11 tools running on RHEL5, and we've
>>> run
>>> into a problem.  When we try to simulate designs involving Xilinx
>>> blocks
>>> (without any Casper blocks), we get the following error:
>>>
>>> "Program "gcc" returned non-zero status (1).
>>>
>>> Error occurred during "Simulation Initialization"."
>>
>> Can you send the .mdl file?
>>
>> John
>>
>>
>>>
>>> The design consisted of a System Generator block, and a Xilinx sampled
>>> constant sent through a gateway to a scope.  The error occurred for the
>>> sampled constant.
>>>
>>> We're running:
>>> RHEL 5.1.19.6
>>> Matlab 2009b
>>> Xilinx ISE 11.5
>>>
>>>
>>> Has anybody ran into this issue?  Any suggestions?
>>>
>>> Thanks,
>>> Matthew
>>> __
>>> Matthew Stevenson
>>> Graduate Student of Astrophysics
>>>
>>> Ph: (626) 395-4095
>>> Fax: (626) 568-9352
>>> E-mail: m...@astro.caltech.edu
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>

Re: [casper] GCC error

[John Ford]

> Hi Matt,
>
> Did you manage to fix your problem? This design simulates just fine for me
> too under 11.4 and 12.1, but we don't have a 11.5 install.
>
> What version of gcc are you using?  Have you tried contacting xilinx
> support?

I was wondering what gcc has to do with the simulation in the first place.
 But I haven't looked under the hood to see what it's really doing.

John

>
> Mark
>
> On Wed, Jun 2, 2010 at 3:42 PM, John Ford  wrote:
>
>> > Hi John,
>> >
>> > The .mdl file is attached.
>>
>> Hi Matthew.
>>
>> This simulated fine for me on my 11.3 system, modulo the warnings about
>> being created on a newer version...
>>
>> Of course, bee_xps complains bitterly about the lack of the MSSGE block
>> if
>> you try to build it.
>>
>> John
>>
>>
>> >
>> > Matthew
>> >
>> >
>> >
>> >>> Hi All,
>> >>>
>> >>> We're trying to get the version 11 tools running on RHEL5, and we've
>> >>> run
>> >>> into a problem.  When we try to simulate designs involving Xilinx
>> >>> blocks
>> >>> (without any Casper blocks), we get the following error:
>> >>>
>> >>> "Program "gcc" returned non-zero status (1).
>> >>>
>> >>> Error occurred during "Simulation Initialization"."
>> >>
>> >> Can you send the .mdl file?
>> >>
>> >> John
>> >>
>> >>
>> >>>
>> >>> The design consisted of a System Generator block, and a Xilinx
>> sampled
>> >>> constant sent through a gateway to a scope.  The error occurred for
>> the
>> >>> sampled constant.
>> >>>
>> >>> We're running:
>> >>> RHEL 5.1.19.6
>> >>> Matlab 2009b
>> >>> Xilinx ISE 11.5
>> >>>
>> >>>
>> >>> Has anybody ran into this issue?  Any suggestions?
>> >>>
>> >>> Thanks,
>> >>> Matthew
>> >>> __
>> >>> Matthew Stevenson
>> >>> Graduate Student of Astrophysics
>> >>>
>> >>> Ph: (626) 395-4095
>> >>> Fax: (626) 568-9352
>> >>> E-mail: m...@astro.caltech.edu
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>
>> >>
>> >
>>
>>
>>
>>
>

Re: [casper] Hang issue when trying to wr/rd a register

[John Ford]

> Hi, John,
> > Did you ever get any replies to your query from last December?
>

I did not.  And I have not tried to move our stuff to 10.1.

>
> I just built a BEE2 design using 10.1 (and mlib_devel_10_1), but I
> can't get it to work.  No TinySH, and reads/writes to /proc//hw/
> ioreg/* just hang.
>
> Do I have to go back to 7.1 for BEE2 development?

I think so.  It seems bee2 is an orphan platform for newer tools.

John


>
> Thanks,
> Dave
>
> On Dec 22, 2009, at 15:27 , John Ford wrote:
>
>> Hi.  Does anyone know what the status of this is?  Does borph on
>> the bee2
>> work under 10.1?
>>
>> John
>>
>>
>>> Hello,
>>> When I've had odd behavior like this before it turned out to be a
>>> corrupt
>>> bof file. I would try recopying the design to the BEE2, but
>>> admittedly
>>> it's
>>> a bit of a long shot.
>>> Glenn
>>>
>>> On Wed, Dec 16, 2009 at 11:49 PM, Oussama Sekkat 
>>> wrote:
>>>
>>>> Hi All,
>>>>
>>>> I just compiled one of my design and ran it on Bee2.
>>>> I notice 2 things:
>>>>
>>>> 1. When I run the bof file, I don't get the usual Bee2 message:
>>>>
>>>> 
>>>> * TinySH lightweight shell *
>>>> 
>>>> Design name : bee_erg_det_v4p3
>>>> Compiled on : 29-Nov-2009 23:46:31
>>>>
>>>> DON'T PANIC ;-)
>>>>
>>>> Type 'help' for help
>>>> Type '?' for a list of available commands
>>>>
>>>>
>>>> BEE2 %
>>>>
>>>> 2. when I try to read or write a register, it just hangs!
>>>>
>>>> Any ideas what could have gone wrong here?
>>>>
>>>> The funny thing is that I only added a couple blocks to one of my
>>>> previous
>>>> design that worked fine! Now I'm getting this strange issue.
>>>>
>>>> Please let me know if you ran into a similar problem before and
>>>> if you
>>>> know
>>>> how to deal with it.
>>>>
>>>> Any input would be greatly appreciated.
>>>>
>>>> Thanks!
>>>>
>>>> Oussama.
>>>>
>>>
>>
>>
>>
>

Re: [casper] Simulink refuses to simulate/compile

[John Ford]

> So simulink keeps throwing the same error whenever I try to simulate or
> compile something: "All Xilinx blocks must be contained in the same
> hierarchy as a system generator block." Googling gives me solutions that
> don't apply to me; same for the casper archive. The truly mysterious thing
> is that I went back to a design that I made for the roach tutorial 1,
> which
> I have not touched since, and even this now refuses to simulate or
> compile.
> Any hot ideas?

Make sure all the subsystem windows are closed, and you have clicked in
the main window with the sysgen token.

If that doesn't work, then delete the sysgen token and put it back.

Otherwise, ???

John


>

Re: [casper] 10gbe switch

[John Ford]

> No.
>
> Believe it or not I spent a long time looking everywhere but the
> Casper wiki. Should have thought of that because that's where we got
> the Myricom card from.
>
> Those listed are at the higher end of the price range I've seen. Looks
> like ~$10k is the amount I should be prepared to spend.

If you don't need real 10 Gb/s throughput through the switch fabric, you
might get away with a cheaper switch.

>
> Am I right to interpret the XFP ports as something I could convert CX4
> to use with a transceiver?

This is a sticky problem.  Some (Myricom, at least) cards will *not*
power/drive the optical transcievers.  We bought some chelsio cards that
will drive them.  The roaches don't seem to have any problem with it.

If you really can do it with ~10 mb/s, maybe use the ROACH's fast ethernet
port and a $200 24 port fast ethernet switch?

John

>
> Tom
>
> On Thu, Aug 5, 2010 at 3:21 PM, Matt Dexter  wrote:
>> Hi Tom,
>>
>> were you aware of these ?
>> http://casper.berkeley.edu/wiki/Recommended_10_GbE_Hardware
>> http://casper.berkeley.edu/wiki/Equipment_Cables
>> Matt Dexter
>>
>> On Thu, 5 Aug 2010, Tom Downes wrote:
>>
>>> Casper-folks:
>>>
>>> Hoping to short-circuit a fair amount of research here in the hope
>>> that someone has had to do this already. I'll soon be looking to
>>> connect 10-20 ROACH boards by 10 gbe to a data acquisition
>>> computer(s).
>>>
>>> It seems like the smartest way of doing that is getting a 16-port
>>> switch or potentially two 8-port switches. But the 10 Gbe port on the
>>> ROACH seems to be CX4 which I take to be a less popular connector
>>> variety.
>>>
>>> What kind of switches have ROACH users out there used to connect up a
>>> bunch of boards? Are there switches out there to convert CX4 to
>>> something with a reach longer than the 15m Wikipedia quotes as the
>>> limit of CX4. 15m is very borderline for our needs.
>>>
>>> The prices seem to vary widely. We do not need network admin tools or
>>> anything fancy. In fact our data rates could probably go over 10Mb
>>> cabling, but the 10Gbe interface of the ROACH is more convenient from
>>> the firmware perspective. This is more of a multiplexer than a switch.
>>>
>>> Tom
>>>
>>>
>>
>>
>

Re: [casper] 10gbe switch

[John Ford]

And don't forget that the switches that are XFP and SFP+ sometimes
(usually?) don't include the optics for each port in the switch price.

With CX4, all you need is a cable, if you're within a few meters.

> Yes - that list is years old.
> Those Fujitsu and HP switches have been tested with the CASPER hardware
> and found to work as advertised.
>
> There are lots of new products available.  More announced
> all the time.  We are in contact with a number of vendors in
> hopes of getting demo units to try in house with the CASPER
> hardware before listing them as recommended for use.
> Our tests will include running at full line rates all ports continuously
> as that's what our intended applications require.
>
> Less demanding applications will have many more, and
> cheaper, options for suitable switch vendor and model.
>
> I have no prediction for when I will be able to add more switch
> models will to that list.
>
> Matt
>
> On Thu, 5 Aug 2010, Andrew Lutomirski wrote:
>
>> On Thu, Aug 5, 2010 at 3:21 PM, Matt Dexter 
>> wrote:
>>> Hi Tom,
>>>
>>> were you aware of these ?
>>> http://casper.berkeley.edu/wiki/Recommended_10_GbE_Hardware
>>
>> Sadly the list is out of date: some of the switches are no longer in
>> production.  The XG700, for example, is great and cheap but you can't
>> buy one without great difficulty.
>>
>> I'm not sure that manufacturers really care about CX4 anymore now that
>> SFP+ parts are available.
>>
>> --Andy
>>
>>> http://casper.berkeley.edu/wiki/Equipment_Cables
>>> Matt Dexter
>>>
>>> On Thu, 5 Aug 2010, Tom Downes wrote:
>>>
 Casper-folks:

 Hoping to short-circuit a fair amount of research here in the hope
 that someone has had to do this already. I'll soon be looking to
 connect 10-20 ROACH boards by 10 gbe to a data acquisition
 computer(s).

 It seems like the smartest way of doing that is getting a 16-port
 switch or potentially two 8-port switches. But the 10 Gbe port on the
 ROACH seems to be CX4 which I take to be a less popular connector
 variety.

 What kind of switches have ROACH users out there used to connect up a
 bunch of boards? Are there switches out there to convert CX4 to
 something with a reach longer than the 15m Wikipedia quotes as the
 limit of CX4. 15m is very borderline for our needs.

 The prices seem to vary widely. We do not need network admin tools or
 anything fancy. In fact our data rates could probably go over 10Mb
 cabling, but the 10Gbe interface of the ROACH is more convenient from
 the firmware perspective. This is more of a multiplexer than a switch.

 Tom


>>>
>>>
>>
>

[casper] ADC block error

[John Ford]

Hi all.  We are trying to build models on 11.X for the roach, and they are
failing.  Here are the error messages:

Yes, Master<752> cat /tmp/jmf.txt

Undefined function or method 'reuse_line' for input arguments of type 'char'.

Error in 'test_jmf/adc083000x2/adc0_sim': Initialization commands cannot
be evaluated.

Error due to multiple causes: --> Undefined function or method
'reuse_line' for input arguments of type 'char'. --> Error in
'test_jmf/adc083000x2/adc0_sim': Initialization commands cannot be
evaluated.


I've seen this error in the mail archives, but I don't see the solution...

Thanks.

John

Re: [casper] ADC block error

[John Ford]

> Suraj,
>
> So from what I understand, anyone that wants to use the 3gsps adc, now
> needs
> to add line
>
> addpath('/mlib_devel/casper_library/simulink_drawing_fns')
>
> to their startup.m script?

Thanks.

That fixed the problems.

John

>
> Mark
>
>
> On Mon, Aug 9, 2010 at 2:43 PM,  wrote:
>
>> Hi John,
>>
>> The 'reuse_line' function is located in
>> casper_library/simulink_drawing_fns. MATLAB is missing it because the
>> addpath function isn't recursive.
>>
>> -Suraj
>>
>> > Hi all.  We are trying to build models on 11.X for the roach, and they
>> are
>> > failing.  Here are the error messages:
>> >
>> > Yes, Master<752> cat /tmp/jmf.txt
>> >
>> > Undefined function or method 'reuse_line' for input arguments of type
>> > 'char'.
>> >
>> > Error in 'test_jmf/adc083000x2/adc0_sim': Initialization commands
>> cannot
>> > be evaluated.
>> >
>> > Error due to multiple causes: --> Undefined function or method
>> > 'reuse_line' for input arguments of type 'char'. --> Error in
>> > 'test_jmf/adc083000x2/adc0_sim': Initialization commands cannot be
>> > evaluated.
>> >
>> >
>> > I've seen this error in the mail archives, but I don't see the
>> solution...
>> >
>> > Thanks.
>> >
>> > John
>> >
>> >
>> >
>> >
>>
>>
>>
>>
>

Re: [casper] FFT on ROACH

[John Ford]

Hi Andrea.

This looks to me like some kind of mismatch in the libraries to me.  I'm
still using the subversion libraries, and they work fine.  I'm going to
move to GIT later today, and I'll try it there and see what happens.

Do you still have your old subversion library installation you can try?

Are you sure that the environment variables do not point to both
installations somehow?

John

> Hi all and many thaks for your help.
>
> @ Mark:
>
> I have completely started a new project since the migration on GIT.
>
> @ David:
>
> I have checked the matlab pth and it is correct, if I try to call:
>
>>> which fft_biplex_real_2x_init
>
> here what I got:
>
> /usr/local/hdl/casper/mlib_devel/casper_library/fft_biplex_real_2x_init.m
>
> seems to be ok.
>
> @ Dan:
>
> yes I would say that is a good idea to contact them.
>
>
> Anyway the problem is still not solved. Even if I simply add the block to
> a new model, looking under mask, there are no connection at all between
> each sub-blocks, and changing parameters does not have effects. Does
> anybody using those Simulink Casper Blocks whit mlib_devel_10_1 release? I
> got the same behaviour with the block 'fft', while other Casper blocks
> (which find many other applications on several projects) work nominally.
> Do you think could be related to the platform I use (64bit rather than a
> 32bit)?
>
> Cheers,
> Andrea
>
>> Hi Andrea,
>>
>> The first thing I would do is delete the fft and replace it with one
>> from
>> your updated library, using the same parameters of course.  If you're
>> still
>> having the problem, I would try running the mask script from the matlab
>> command prompt to get a more verbose output.  To see how the mask script
>> is
>> called, right click on the block and select 'view mask,' then select the
>> 'initialization' tab.
>>
>> Mark
>>
>>
>> On Mon, Aug 30, 2010 at 4:19 AM, Andrea Mattana
>> wrote:
>>
>>> Hi All,
>>>
>>>  I'm a Medicina Radiotelescopes (Italy) team member, my name is Andrea
>>> Mattana, I'm working here since January to develop a new acquisition
>>> system for SETI based on the CASPER ROACH board.
>>>
>>>  I have started to work using the libraries available on the SVN
>>> repository and in June I have done the migration on GIT following your
>>> instractions and now I'm very up-to-date.
>>>
>>>  I have some problems in using the CASPER FFT libraries, the drawings
>>> seems to do not update after changing parameters. When I try to look
>>> under mask (i.e. on fft_biplex_real_2x) there are no connections at all
>>> between blocks, while many other casper blocks works nominally. I have
>>> seen on the GIT commit log an update done by David MacMahon on those
>>> blocks, I don't know if he is the right person that can help me anyway
>>> I'm very happy to hear any suggestion to fix the problem from you all.
>>>
>>>  The developing system I use it is a Linux Centos release 5.5 64 bit,
>>> Matlab R2009b, Xilinx 11.4.
>>>
>>>  Kind regards,
>>>
>>>Andrea Mattana
>>>
>>>
>>> ---
>>>
>>> Andrea Mattana
>>>
>>> Istituto Nazionale di Astrofisica
>>> Istituto di RadioAstronomia
>>>
>>> Stazione di Medicina
>>> Via Fiorentina 3508/B
>>> I-40059 Medicina (BO)
>>> Tel  +39-051-6965834
>>> Fax +39-051-6965810
>>>
>>>
>>>
>>
>
>
> ---
>
> Andrea Mattana
>
> Istituto Nazionale di Astrofisica
> Istituto di RadioAstronomia
>
> Stazione di Medicina
> Via Fiorentina 3508/B
> I-40059 Medicina (BO)
> Tel  +39-051-6965834
> Fax +39-051-6965810
>
>
>

Re: [casper] FFT on ROACH

[John Ford]

Hi all.

For what it's worth, I just cloned the git tree from berkeley with:

git clone git://casper.berkeley.edu/mlib_devel.git

and it works fine, as far as a quick test.  I instantiated an
fft_biplex_real_2x block, and a fft_wideband_real, and they ran fine, and
are OK under the mask.

My installation matches the signatures that David speaks of below, except
there's an "8" missing off the end of the casper_library.mdl hash.  It
should be 27e1f49f5af8933300b0441c9da6c253e10066f8

At any rate, it works for me.  :)

John


> Hi, Andrea,
>
> On Sep 1, 2010, at 6:10 , Andrea Mattana wrote:
>
>> ??? Error using ==> reuse_block at 42
>> biplex_core block (mask) does not have a parameter named
>> 'conv_latency'.
>
> This is very helpful.  This tells us (at the risk of restating the
> obvious) that the init scripts are trying to set the 'conv_latency'
> mask parameter of the biplex_core block, but the biplex_core block it
> is using does not have this parameter.  I just started a totally new
> model, added an fft_biplex_real_2x block, and it worked fine.  This
> was using the 10.1 tools and the latest mlib_devel.git version
> (eab23d2fcb8e1f89db697edad8d3ec9fba7c8c50).  If you look under the
> mask of the fft_biplex_real_2x block, select the biplex_core block,
> and choose "Edit|Edit Mask..." (or type CTRL-M), you should see the
> conv_latency parameter in the mask parameters (see attached image).
>
> Is it possible that your library browser is picking up an older
> casper_library.mdl file from somewhere else on your system?  You can
> run "which --all casper_library" and you should see only one
> casper_library.mdl listed.  Based on your earlier message, I suspect
> that the casper_library.mdl file that you want to be using is in...
>
> /usr/local/hdl/casper/mlib_devel/casper_library/casper_library.mdl
>
> You can also check this by opening the "CASPER DSP Blockset" (right-
> click on the name in the library browser) and then selecting "File|
> Properties...".  You should be able to find the full path of the
> source file in the displayed dialog.  (This is based on Windows; I am
> not sure if it is the same on Linux.)
>
> If you are using the casper_library.mdl file from a directory that
> you think should be OK, the next step would be to verify that it
> really is what you think it is.  You can try things like...
>
> $ cd /usr/local/hdl/casper/mlib_devel
>
> $ git status
>
> $ git branch -av
>
> $ git log -10 --oneline casper_library/casper_library.mdl
>
> $ git hash-object casper_library/casper_library.mdl
>
> If you are using the latest from mlib_devel.git (i.e.
> eab23d2fcb8e1f89db697edad8d3ec9fba7c8c50), the last two commands will
> give...
>
> $ git log -10 --oneline casper_library/casper_library.mdl
> 6f87da3 Fix Misc/armed_trigger block
> 2d0bf0e Improve fft_biplex_real_2x block
> 05b6b95 Change latency in fft_biplex_real_2x/bi_real_unscr_2x
> ad2e026 Fix WGN source and begin split of casper_library
> fbbe3cb X engine cross-polarisation correction
> d60fff2 mods to xengine block in casper library
> 1967df0 bugfixes to x engine.
> 914d207 X engine mods to support 4antennas (special case).
> 1ab1a14 pfb_fir_real conv_latency parameter added
> a03d785 large fft fix and clean-up
>
> $ git hash-object casper_library/casper_library.mdl
> 27e1f49f5af8933300b0441c9da6c253e10066f
>
> If you still can't resolve the problem, please email the output of
> all the above git commands.  If this does resolve the problem, please
> send the clues you used to figure it out to the list so future users
> can benefit.
>
> Thanks,
> Dave
>
>

Re: [casper] My Problem with bee_xps

[John Ford]

> I found the problem. I started
> putting uppercase letters in file
> names. Uppercase letters cause
> bee_xps to have trouble finding
> files.

Hi all.  Can someone at CASPER put this in big letters on the WIKI
somewhere?  This bites everyone who uses the Linux version at least once.

There maybe even ought to be a check in the bee_xps script to warn the
user that the name cannot contain uppercase letters.  Maybe it should even
die with a fatal error if there are capital letters in the name.

John


>
>> When I run bee_xps on my Simulink
>> models, I get the following error
>> message.
>>
>> Error using ==> gen_xps_create_pcore at 41
>> Cannot find any compiled XSG netlist. Have you run the
>> Xilinx System Generator on your design ?
>>
>> I am running on Linux. After
>> running bee_xps, the
>> sysgen/synth_model directory has
>> the following contents:
>>
>> cntr_11_0_9711f575cf7ce495.ngc
>> firsttutorial_cw.sgp
>> isim_firsttutorial.prj
>> commandLines
>> firsttutorial_cw.syr
>> ngcbuild.results
>> firsttutorial_cw_complete.blc
>> firsttutorial_cw.vhd
>> synopsis
>> firsttutorial_cw_complete.ngc
>> firsttutorial_cw.xise
>> vcom.do
>> firsttutorial_cw.gise
>> firsttutorial.vhd
>> xlpersistentdff.ngc
>> firsttutorial_cw.ise
>> globals
>> xst_firsttutorial.prj
>> firsttutorial_cw.ngc
>> hdlFiles
>> xst_firsttutorial.scr
>>
>>
>> The full run of messages in the
>> Matlab window from bee_xps are
>> below.
>>
>> Detected Linux OS
>> #
>> ##  System Update  ##
>> #
>> Warning: The model 'firstTutorial' does not have continuous
>> states, hence Simulink is
>> using the solver 'VariableStepDiscrete' instead of solver
>> 'ode45'. You can disable this
>> diagnostic by explicitly specifying a discrete solver in
>> the solver tab of the
>> Configuration Parameters dialog, or by setting the
>> 'Automatic solver parameter
>> selection' diagnostic to 'none' in the Diagnostics tab of
>> the Configuration Parameters
>> dialog.
>>> In gen_xps_files at 199
>>   In bee_xps>run_Callback at 150
>>   In bee_xps at 82
>> Warning: Using a default value of 0.2 for maximum step
>> size.  The simulation step size
>> will be equal to or less than this value.  You can disable
>> this diagnostic by setting
>> 'Automatic solver parameter selection' diagnostic to 'none'
>> in the Diagnostics page of
>> the configuration parameters dialog.
>>> In gen_xps_files at 199
>>   In bee_xps>run_Callback at 150
>>   In bee_xps at 82
>> #
>> ## Block objects creation  ##
>> #
>> ##
>> ## Checking objects ##
>> ##
>> Running system generator ...
>> Warning: The model 'firstTutorial' does not have continuous
>> states, hence Simulink is
>> using the solver 'VariableStepDiscrete' instead of solver
>> 'ode45'. You can disable this
>> diagnostic by explicitly specifying a discrete solver in
>> the solver tab of the
>> Configuration Parameters dialog, or by setting the
>> 'Automatic solver parameter
>> selection' diagnostic to 'none' in the Diagnostics tab of
>> the Configuration Parameters
>> dialog.
>>> In
>> /usr/local/hdl/Xilinx/11.1/DSP_Tools/lin64/sysgen/bin/xlCompileGenerateMdl.p>xlCompileGenerateMdl
>> at 180
>>   In
>> /usr/local/hdl/Xilinx/11.1/DSP_Tools/lin64/sysgen/bin/xlGenerateButton.p>xlGenerateButton
>> at 281
>>   In gen_xps_files at 324
>>   In bee_xps>run_Callback at 150
>>   In bee_xps at 82
>> Warning: Using a default value of 0.2 for maximum step
>> size.  The simulation step size
>> will be equal to or less than this value.  You can disable
>> this diagnostic by setting
>> 'Automatic solver parameter selection' diagnostic to 'none'
>> in the Diagnostics page of
>> the configuration parameters dialog.
>>> In
>> /usr/local/hdl/Xilinx/11.1/DSP_Tools/lin64/sysgen/bin/xlCompileGenerateMdl.p>xlCompileGenerateMdl
>> at 180
>>   In
>> /usr/local/hdl/Xilinx/11.1/DSP_Tools/lin64/sysgen/bin/xlGenerateButton.p>xlGenerateButton
>> at 281
>>   In gen_xps_files at 324
>>   In bee_xps>run_Callback at 150
>>   In bee_xps at 82
>> XSG generation complete.
>> #
>> ## Copying base system ##
>> #
>> 
>> ## Copying custom IPs ##
>> 
>> ##
>> ## Creating Simulink IP ##
>> ##
>> Error using ==> gen_xps_create_pcore at 41
>> Cannot find any compiled XSG netlist. Have you run the
>> Xilinx System Generator on your design ?
>>
>>
>>
>>
>>
>
>
>

Re: [casper] Regarding data coming out of DRAM !!

[John Ford]

CC: list...

> Hi Shrikanth,
>
> I haven't worked extensively with the DRAM, so i'm not sure why you would
> be
> getting these constant values. But I don't think half the data stored in
> memory should be a constant.

Hi Srikanth.

I wonder if this is because of DRAM size?  It looks like an addressing
flaw of some sort, which might be explained if our DRAM isn't the same
size as the one used in the design used as a pattern?

John

>
> The DRAM runs off a different clock then the FPGA and the read/write
> schedule is a little tricky if I remember correctly.  Do you need to be
> using DRAM for what you're doing?
> Have you compared your design to a known working one.
>
> Mark
>
>
> On Thu, Sep 23, 2010 at 3:59 PM, bussa srikanth  wrote:
>
>> Hello Mr. Mark,
>>
>> How are you doing?
>>
>> I was able to plot the data from the DRAM. I saved the data in to a bin
>> file and I used matlab to plot it.
>> *
>> Data Stream coming out of the DRAM appears to be like this:*
>>
>> ---First 16 Bytes
>> ---
>> - Second 16 Bytes
>> --  -- Third 16
>> Bytes
>> -
>> '\x00\xfd\xfc\xfb\xfb\xfb\xfc\xfe\x80\x80\x80\x80\x80\x80\x80\x80
>> \x01\x02\x04\x04\x05\x03\x02\x00\x80\x80\x80\x80\x80\x80\x80\x80
>> \xfe\xfc\xfb\xfb\xfb\xfc\xfe\x01\x80\x80\x80\x80\x80\x80\x80\x80  .
>> and
>> so on..
>>
>> For every 16 bytes the lower 8bytes appear to be constant. If I remove
>> the
>> constant data and plot it looks perfectly fine . The period of the sine
>> wave
>> what I am giving as input matches with the plot obtained from the DRAM
>> data
>> when I remove the lower 64 bits of data.
>>
>> I just wanted to know if that is the way the data is written in the
>> DRAM.??
>>
>>
>> Thank you
>>
>> Regards,
>> Srikanth
>>
>>
>>
>

Re: [casper] ROACH basic questions

[John Ford]

Hi Daniel.

I agree with what Dan has said.  Go to
http://casper.berkeley.edu/wiki/Main_Page, look down to the menu on the
left, and find the tutorials entry.

As far as your questions about versions, etc., I think you have to be a
bit careful about making sure the versions match each other.  In Green
Bank, we have not worried about messing around in the katcp or the borph,
or the uboot, we just use what is recommended.  See the
http://casper.berkeley.edu/wiki/ROACH web page, and near the bottom is a
list of documents about ROACH.  They are pretty complete, and I hope up to
date.  Can someone confirm the latest versions of ROACH stuff?

Another recommendation that I have is to learn well your tool to analyse
the output of the system, either matlab or python, whichever you know
best.

Good luck, and please do ask questions on the list so that all new users
can benefit from the answers!

John

>
>
> hi daniel,
>
> i recommend you do some of the roach tutorials to learn
> how to use your system  - i think these tutorials
> include blinking an LED,  adding numbers together,
> (these tutorials teach how to use the operating system,
> simulink tools, borph)
> then building and testing a spectrometer, a correlator,
> (these teach how to use the DSP blocks),
> and using the 10Gbit ethernet interface to send
> high speed data into a computer and GPU.
>
> best wishes,
>
> dan
>
>
>
> On 09/27/2010 04:25 PM, Daniel Esteban Herrera Pena wrote:
>> Dear CASPER team,
>>
>> I'm glad to be subscribed in your mailing list, I hope to receive some
>> advice from you these days.
>>
>> I'm here because I just joined an Astronomy project in University of
>> Concepcion, Chile. I'm the guy who will be in charge of programming the
>> ROACH, so I would like to be in touch with the creators of this awesome
>> board.
>>
>> My experience is related to hardware synthesis/design with boards like
>> Basys, Nexus and Virtex 2 XUP, programming on verilog with Xilinx
>> software
>> (ISE, some entry-level with EDK).
>>
>> The problem here (for me) is that the ROACH system have almost nothing
>> to
>> do with the boards I had programmed before (or at lest what I could see
>> till now). This ROACH have file-system, kernel and a bootloader, it's
>> almost a PC.
>>
>> I saw the ROACH wiki space, and from there I would like to know:
>>
>> 1.- (from Getting started with ROACH): ROACH comes with Busybox
>> filesystem, why adding another (based on Debian Etch)? What advantages
>> have compared with Busybox?
>>
>> 2.- (from ROACH kernel uboot update): Where can I see the improvements
>> of
>> the lastest uboot image? Do you recommend me to update the default
>> version?
>>
>> 3.- (From setting BORPH on ROACH): I don't clearly have the functions of
>> the kernel and the operating system (BORPH) on the ROACH. Are those the
>> same?
>>
>> 4.- (From setting BORPH on ROACH): What are the differences between the
>> minimal root filesystem and the full-featured filesystem?
>>
>> 5.- Do you have any examples of code that I could program the board?
>>
>> 6.- What is the typical step-by-step instructions for doing something on
>> the ROACH making use of the integrated FPGA?
>>
>> I hope you guys give a hand understanding how this system really works,
>> I
>> really appreciate any contributions to my clarification. Thank you in
>> advance!
>>
>> Best,
>>
>> Daniel.
>>
>>
>>
>>
>
> --
>
> Dan Werthimer
> Space Sciences Lab and Berkeley Wireless Research Center
> University of Calfornia, Berkeley
>
>
>

Re: [casper] Tut2 : Unable to transmit and receive Data from 10Gbe

[John Ford]

>   On a related issue, does anybody have any ideas about my "connected at
> 1.4Gbps" message that I get when I plug ROACH 10GbE transmit into my
> Chelsio NIC?  This seems to be a low-level issue, ie, there's no data
> being sent from ROACH, it's just the 10GbE yellow block (version 1)
> sitting there.  When I send packets, they come through (seen in
> Wireshark) but I have to be careful not to exceed about 1Gb/s, else I
> get overruns.

I have never seen this happen.

Is there a feature in the 10 gbe spec to connect at different speeds?  I
wonder if your NIC is doing it?

Have you tried another one?

Another thought is that maybe it connects at 1.4 GBps* with a faulty
message (Note the capital 'B'...), but your host can't swallow more than 1
Gbps without losing packets.

*"connected at 1.6Gb/s" * 8 = 12.8000 gbs, ~= to the 10 GbE bit rate...

John


> Thanks
> Rick
>
> On 9/28/2010 6:11 AM, Jason Manley wrote:
>> The tx_afull signal should not be used to determine when to end your
>> frames. This is there to tell you that the input buffer is almost full
>> and that you need to stop clocking data into the core.
>>
>> You should decide yourself how big to make your packets. I usually aim
>> for 4096 bytes, which is big enough that most computers can swallow high
>> data rates. Note that you need jumbo frames enabled on your network for
>> larger packets like this to work.
>>
>> The 10GbE core only starts to flush contents from the input fifo after
>> you send an EOF pulse. So if you wait for the afull signal before
>> pulsing EOF, then you must wait 'till the buffer empties out a bit
>> before clocking-in any more data.
>>
>> I hope this clarifies things.
>>
>> Jason
>>
>> On 28 Sep 2010, at 15:03, Andrew Lutomirski wrote:
>>
>>> I've found the 10GbE transmit side to be very finnicky.  I can get it
>>> to work reliably if I manually reset it after loading the model and if
>>> I don't rely on the tx_afull signal.  I think what goes wrong is that
>>> I see tx_afull, send end of frame, then start sending the next frame.
>>> The beginning of the next frame overflows the buffer because the first
>>> frame hasn't cleared out of the buffer yet.  So instead I just could
>>> bytes sent and end the frame myself.
>>>
>>> --Andy
>>>
>>> On Tue, Sep 28, 2010 at 8:58 AM, Guy kenfack
>>> wrote:
 Good morning,
 few days ago, Jason helped  us to run tut2.
 Then we tried again this week to go back in depth in the Tut2
 design(10GbE).
 We tried to run the same python script(with the same boffile) and we
 got
 strange results:
 - Specially we were not able to display the RX counter on the
 screen.(we are
 able to display only the TX counter)
 -TX buffer always overflow
 - There is no data send to RX(RX array is always empty)
 - From the screen report it seems that the 10GbE is always disable !!
 the
 10GbE parameters( mac, ip, port) from the 'tut2.py' seems to have
 not
 been taken in acount trough
 the configuration registers !
 - We decided to save the output screen for both case: 'tut2.py roach
 -a' and
 'tut2.py roach -p' . the report are displayed below.

 thanks in advance,


   output screen report:'tut2.py
 roach
 -a'  ==

 Note that for some IP address values, only the lower 8 bits are valid!
 
 GBE0 Configuration...
 My MAC:  12 34 56 78 00 00
 Gateway:0   0   0   1
 This IP:  192 168   5  20
 Gateware Port:  1
 Fabric interface is currently:  Disabled
 XAUI Status:  007E
   lane sync 0: 1
   lane sync 1: 1
   lane sync 2: 1
   lane sync 3: 1
   Channel bond: 1
 XAUI PHY config:
  RX_eq_mix:  4
  RX_eq_pol:  0
  TX_pre-emph:  0
  TX_diff_ctrl:  0
 ARP Table:
 IP: 192.168.  5.  0: MAC: FF FF FF FF FF FF
 IP: 192.168.  5.  1: MAC: FF FF FF FF FF FF
 IP: 192.168.  5.  2: MAC: FF FF FF FF FF FF
 IP: 192.168.  5.  3: MAC: FF FF FF FF FF FF
 .
 .
 .
 .
 .
 IP: 192.168.  5.244: MAC: FF FF FF FF FF FF
 IP: 192.168.  5.245: MAC: FF FF FF FF FF FF
 IP: 192.168.  5.246: MAC: FF FF FF FF FF FF
 IP: 192.168.  5.247: MAC: FF FF FF FF FF FF
 IP: 192.168.  5.248: MAC: FF FF FF FF FF FF
 IP: 192.168.  5.249: MAC: FF FF FF FF FF FF
 IP: 192.168.  5.250: MAC: FF FF FF FF FF FF
 IP: 192.168.  5.251: MAC: FF FF FF FF FF FF
 IP: 192.168.  5.252: MAC: FF FF FF FF FF FF
 IP: 192.168.  5.253: MAC: FF FF FF FF FF FF
 IP: 192.168.  5.254: MAC: FF FF FF FF FF FF
 IP: 192.168.  5.255: MAC: FF FF FF FF FF FF
 
 Sent 25037 packets already.
 Received 0 packets already.
 
 Triggering snap captures... done
 Enabling output... done

[casper] 3 Gs/s adc board demo example

[John Ford]

Hi all.

Does anyone have a working example of using the adc083000 adc board in the
2* demultiplexed mode (16 simultaneous outputs).

If so, what sampling rate?

Thanks!

John

Re: [casper] 3 Gs/s adc board demo example

[John Ford]

> Hi John,
>
> Just to clarify, do you mean 1 board with 16 outputs / cycle at half
> the clock rate?  I implemented this feature but I wouldn't recommend
> using it for serious computation.  For operations like FFT, speed is
> not as much a problem as the number of simultaneous

Yes, that's what I meant.  We're trying to test the board at 3 GS/s by
collecting a long snapshot into DRAM, which doesn't run at 375 MHz, so we
thought we'd just run it at the 2x demux into the dram interface.

We can run the board at 1.5 GS/s with 8 outputs, but when we try the 16
output mode at 3 GS/s it doesn't seem to work right.

So you would run the board at twice the clock rate and demux the output
samples on the FPGA in the simulink model before writing into dram?

Thanks for the info!

John


>
> -Suraj
>
> On Sep 29, 2010, at 5:51 PM, John Ford wrote:
>
>> Hi all.
>>
>> Does anyone have a working example of using the adc083000 adc board
>> in the
>> 2* demultiplexed mode (16 simultaneous outputs).
>>
>> If so, what sampling rate?
>>
>> Thanks!
>>
>> John
>>
>>
>>
>

Re: [casper] tcpborphserver version, ?wordwrite always returns zero

[John Ford]

> The startup scripts execute "tcpborphserver2" by default. There's a bug in
> the scripts and it won't work unless it's in your path though (default is
> /usr/local/sbin, which is in the path, so no problems).  /borph is not a
> standard path entry.
>
> Assuming you're running the default filesystem, You should rename the
> downloaded file "tcpborphserver2-2010-08-27-r3304-signfix" to
> "tcpborphserver2" or otherwise create a symlink with the name
> "tcpborphserver2" to whichever version you're using (the method we prefer,
> that way you always know which version you're running and it's easy to try
> different ones) and place it in /usr/local/sbin. You can do this as
> follows:
>
> cp tcpborphserver2-2010-08-27-r3304-signfix /usr/local/sbin/
> chmod a+x /usr/local/sbin/tcpborphserver2-2010-08-27-r3304-signfix
> ls -s /usr/local/sbin/tcpborphserver2-2010-08-27-r3304-signfix
> /usr/local/sbin/tcpborphserver2

I think this last command should be "ln" instead of "ls"

John


>
> Note also (as Henry pointed out) that tcpborphserver expects boffiles in
> /boffiles.
>
> Hope this helps.
>
> Jason
>
> On 28 Sep 2010, at 20:11, Henry Chen wrote:
>
>> Hi Melissa,
>>
>> I've been playing around a bit with the new -signfix version of
>> tcpborphserver. The patch works for me if I do
>>
>> /etc/init.d/tcpborphserver stop
>>
>> then replace tcpborphserver2 in /usr/local/sbin and reboot. Then
>> the new version of the server comes up properly at boot. Did you
>> have customized startup to point to /borph when you compiled the
>> kernel?
>>
>> Thanks,
>> Henry
>>
>> On 9/28/2010 9:24 AM, Soriano, Melissa (335J) wrote:
>>> Dear Jason,
>>> Thank you for the LatestVersions wiki page.
 The latest binary in SVN is from 2009
 (http://casper.berkeley.edu/svn/trunk/roach/sw/binaries/linux/uImage-
 jiffy-20091110). Did you recompile the kernel yourself?
>>> Yes, I checked out the roach/sw/linux directory and recompiled the
>>> kernel myself.  I needed the kernel source to compile my kernel modules
>>> against.
>>> o...@roach1:~$ uname -a
>>> Linux roach1 2.6.25-svn3327 #2 Tue Sep 28 09:05:39 PDT 2010 ppc
>>> GNU/Linux
> We are using tcpborphserver 0.2110.  Is this the latest version?
 No, latest version is
 http://casper.berkeley.edu/svn/trunk/roach/sw/binaries/tcpborphserver/t
 cpborphserver2-2010-08-27-r3304-signfix
 You could try that one. I don't have any problems using other commands
 or running tut2 (the 10GbE tutorial) using the recommended versions...
>>> I picked up the version above and copied it to the /borph directory,
>>> then rebooted the board.  However, when I look at the process list, I
>>> don't see tcpborphserver..
>>> o...@roach1:~$ ps -ef
>>> UIDPID  PPID  C STIME TTY  TIME CMD
>>> root 1 0  2 16:20 ?00:00:00 init [2]  root
>>> 2 0  0 16:20 ?00:00:00 [kthreadd]
>>> root 3 2  0 16:20 ?00:00:00 [ksoftirqd/0]
>>> root 4 2  0 16:20 ?00:00:00 [events/0]
>>> root 5 2  0 16:20 ?00:00:00 [khelper]
>>> root48 2  0 16:20 ?00:00:00 [kblockd/0]
>>> root58 2  0 16:20 ?00:00:00 [khubd]
>>> root65 2  0 16:20 ?00:00:00 [kmmcd]
>>> root85 2  0 16:20 ?00:00:00 [bkexecd]
>>> root86 2  0 16:20 ?00:00:00 [pdflush]
>>> root87 2  0 16:20 ?00:00:00 [pdflush]
>>> root88 2  0 16:20 ?00:00:00 [kswapd0]
>>> root89 2  0 16:20 ?00:00:00 [aio/0]
>>> root   123 2  0 16:20 ?00:00:00 [mtdblockd]
>>> root   161 2  0 16:20 ?00:00:00 [krmond]
>>> root   167 2  0 16:20 ?00:00:00 [rpciod/0]
>>> daemon 387 1  0 16:21 ?00:00:00 /sbin/portmap
>>> statd  394 1  0 16:21 ?00:00:00 /sbin/rpc.statd
>>> root   402 2  0 16:21 ?00:00:00 [lockd]
>>> root   496 1  0 16:21 ?00:00:00 /sbin/syslogd
>>> root   505 1  0 16:21 ?00:00:00 /sbin/klogd -x
>>> root   532 1  0 16:21 ?00:00:00 /usr/sbin/inetd
>>> ntp545 1  0 16:21 ?00:00:00 /usr/sbin/ntpd -p
>>> /var/run/ntpd.pid -u 100:102 -g
>>> root   567 1  0 16:21 ?00:00:00 /usr/sbin/cron
>>> root   626 1  0 16:21 ttyS000:00:00 /sbin/getty -L ttyS0
>>> 115200 vt100
>>> telnetd627   532  1 16:21 ?00:00:00 in.telnetd: psdg5.lab
>>> root   629   627  2 16:21 pts/000:00:00 login -h psdg5.lab -p
>>> ops630   629  1 16:21 pts/000:00:00 -sh
>>> ops634   630  0 16:21 pts/000:00:00 ps -ef
>>> o...@roach1:~$ ls -lart /borph
>>> total 1108
>>> -rwxr-xr-x  1 root root 33 Jul 16  2009 rc
>>> -rwxr-xr-x  1 root root 577036 Jul 17  2009 tcpborphserver.orig
>>> drwxr-xr-x 29 root root   4096 Aug  3 04:12 ..
>>> -rwxr--r--  1 root root 266102 Sep 28 16:19
>>> tcpborphserver2-2010-08-27-r3304-signfix
>

Re: [casper] iBOB freezing

[John Ford]

> Hi everyone,
>
> I'm having a problem with an iBOB-based spectrometer. The design is a
> simple instrument used to measure neutral hydrogen for our
> undergraduate radio lab course. The spectra are transmitted over the
> 10/100 Mb ethernet using a modified main.c file where I read the
> channels out of a shared BRAM, packetize them, and send the using UDP.
> They are then grabbed using the software "gulp", which is similar to
> tcpdump.
> The problem is occasionally the iBOB seizes up. The "sanity LEDs" go
> dark and no data is transmitted. After some about of time, the iBOB
> comes back to life and things resume as normal.
>
> Does anyone have any idea what could cause the iBOB to "go dark" like
> this?

Maybe it's overheating?  Do you have a little fan right on the FPGA? 
We've found that is necessary, even in a "proper" case.  We cut a hole in
the lid and add a fan right over the chip.

That, or a power supply regulator is overheating and shutting down.  You
might be able to diagnose that with your finger. (carefully, as they run
somewhat hot anyway!)

John

> Thanks,
> Laura
>

Re: [casper] iBOB freezing

[John Ford]

>> Maybe it's overheating?  Do you have a little fan right on the FPGA?
>> We've found that is necessary, even in a "proper" case.  We cut a hole
>> in
>> the lid and add a fan right over the chip.
>
> Interesting idea. I do have a small fan attached to the iBOB heat
> sink. It was running at the time. The iBOB is mounted in a rack with
> plenty of ventilation.
> One other point that just occurred to me... the 8 small LEDs
> accessible from the fabric were off, but the larger LED that indicates
> that the fabric is programmed was ON. Not sure if that helps support a
> diagnosis of the FPGA overheating.
>
>> That, or a power supply regulator is overheating and shutting down.
>> might be able to diagnose that with your finger. (carefully, as they run
>> somewhat hot anyway!)
>
> Hmm... Would a power supply regulator overheating cause the FPGA to
> lose it's programming? When it comes back to life it returns to normal
> with its software registers set correctly and everything.
>

Could be, if the power supply that supplies the I/O is bad, but the other
supplies on the board are OK.  This is a bit of a pathological case! 
Maybe you can add some logic to see if the I/O power stays on and read it
from the CPU.

John


> Laura
>
>
>>
>> John
>>
>>> Thanks,
>>> Laura
>>>
>>
>>
>>
>

[casper] SPEAD examples?

[John Ford]

Hi all.

Do any of you have any xilinx designs that implement SPEAD protocol
packets over 10 GbE?

John

Re: [casper] SPEAD examples?

[John Ford]

e SPEAD
> heaps and stores them to disk in HDF5 format using existing Python
> libraries. It can optionally send realtime signal display data to another
> computer too, mating to an external package, katsdisp, for realtime signal
> visualisation.
>
> FUTURE
> ==
> Until we figure out what do with with the revision control system, I can
> email individuals the lastest ROACH model files or bitstreams if you want
> them. If you have 16 ROACH boards and a 10GbE switch, you can assemble a
> duplicate of our system to play with or scale it up or down to suit your
> needs. This reference 16 FPGA version is mostly empty (about 50% full),
> processing 512 channels over 400MHz bandwidth, full stokes.  So there's
> lots of room to add features and things. It has 10GbE output and can do
> high speed dumps (well below 100ms) or up to about 1min integrations
> before integer overflows. Note that our F engines expect KATADCs. You
> might need to recompile for iADC and update the config file as
> appropriate.
>
> Next year we will be adding beamformers to the X engines.
>
>
> Jason
>
>
>
> On 11/29/2010 8:12 AM, John Ford wrote:
>> Hi all.
>>
>> Do any of you have any xilinx designs that implement SPEAD protocol
>> packets over 10 GbE?
>>
>> John
>>
>>
>>
>
>
>
>

[casper] BEE2 eeprom

[John Ford]

Hi all.  Is there any way to get the eeprom contents while the bee2 is
running linux?  Like the get_eeprom command, only from a borph linux
shell.

John

Re: [casper] Update: Problem with adc083000x2

[John Ford]

Hi Ron.

Can you send your model for us to try?

John


> I ran bee_xps on another model using
> the adc083000x2 block. The first run
> of bee_xps resulted in an error, but
> a later run compiled without errors.
> I didn't change the model. How can a
> run result in an error but repeating
> the run result in no error? I didn't
> have such luck with my singleadc3ghz
> model. It still has the same error.
>
>> When I run bee_xps on a model using an
>> adc083000x2 block set up as a single
>> ADC board rather than two boards, I
>> get the following results and error
>> message. The demux_adc parameter is
>> for the adc083000x2 block, but I
>> don't use this feature. Why does this
>> parameter cause trouble for me?
>>
 bee_xps
>> Detected Linux OS
>> #
>> ##  System Update  ##
>> #
>> Running mask script for adc083000
>> xbsBasic_r4/Up Sample
>> Error using ==> gen_xps_files at 199
>> Error due to multiple causes:
>> --> Xilinx Up Sampler Block block (mask) does not have a
>> parameter named 'demux_adc'.
>> --> Error in 'singleadc3ghz/adc083000x2': Initialization
>> commands cannot be evaluated.

>>
>>
>>
>
>
>

Re: [casper] 10gbe switch

[John Ford]

Can one use the zarlink (or something like it) on the ROACH end, and
connect the fiber to an SFP+ module in the computer or switch?  It seems
like someone ought to make such a beast, considering there are a lot of
cx-4 ports in the field that need to be connected to new CX-4 - only
switches and NICs.

This is, I'm afraid, the downside to throwing in your lot with commercial
products.  You're at the mercy of the markets.

John


> I am avoiding Myricom for the reasons Rick mentioned. It took a long time
> for me to get the sales/technical person to even understand that I wanted
> to
> go from CX4 to fiber.
>
> But Chelsio, as several have mentioned on this list, provides the power
> necessary for transceivers to work. They also have offloading cards (which
> I
> believe is what you're describing) - or at least they did until the
> discontinued their CX4 line. Not sure what the new Chelsio product line
> will
> look like and I am somewhat dubious that they will stay on the 4-6 week
> timeframe. Every vendor that I and a collaborator have called are out of
> Chelsio CX4 stock.
>
> Intel makes 10gbe cards, but the list archives are ambiguous as to whether
> they power the transceivers in the Zarlink cables.
>
> My primary concern is that if companies already see fit to discontinue CX4
> products, then (a) it is hard to connect to the ROACH now and (b) will be
> nearly impossible when something breaks in 6 years.
>
> How far along are the GMRT folks?
>
> Tom
>
> On Fri, Jan 28, 2011 at 6:06 PM, rick raffanti 
> wrote:
>
>>  The Myricom people told me they don't make NICs with active ports- ie,
>> aux
>> power for the fiber translator.  That's why we bought the Chelsio.
>> Anton is
>> getting 6Gb/s throughput with the Chelsio- we haven't tried to push it
>> further.  I wasn't aware of the UDP packet handling stuff, though.
>>
>> Rick
>>
>>
>> On 1/28/2011 5:53 PM, Dan Werthimer wrote:
>>
>>
>> hi tom,
>>
>> one more note:
>>
>> if you use fiber optic CX4 cables,
>> please see the warning at
>>
>> http://casper.berkeley.edu/wiki/Recommended_10_GbE_Hardware
>>
>> not all NIC boards have built in power to support
>> fiber optic cables.   check with myricom.
>> the ibob/bee2/roach boards have built in power.
>>
>> dan
>>
>>
>> On 1/28/2011 2:41 PM, Tom Downes wrote:
>>
>> So Chelsio has end-of-lifed their CX4 line. They say "4-6 weeks" until
>> new
>> cards come out as part of a new product line, but their sales contact
>> said
>> this reflected a larger recognition that CX4 is not how the industry is
>> going.
>>
>>  My thought is that I should be buying an SFP+ card and figuring out a
>> way
>> to convert to CX4, e.g. SFP+->optical, optical->CX4. Our cable lengths
>> that
>> we will (eventually) need are all greater than 15m, so outside of the
>> CX4
>> spec, much less what the ROACH boards are apparently cable of driving.
>>
>>  Is such a transceiver scheme plausible? I am having trouble finding the
>> appropriate parts.
>>
>>  Tom
>>
>> On Mon, Aug 9, 2010 at 8:11 AM, Matt Dexter 
>> wrote:
>>
>>> Yes - when pricing switches, or any sort of (sub-)system, a full
>>> BOM must be used to make a meaningful comparison.
>>>
>>> Matt
>>>
>>>
>>> On Mon, 9 Aug 2010, John Ford wrote:
>>>
>>>  And don't forget that the switches that are XFP and SFP+ sometimes
>>>> (usually?) don't include the optics for each port in the switch price.
>>>>
>>>> With CX4, all you need is a cable, if you're within a few meters.
>>>>
>>>>  Yes - that list is years old.
>>>>> Those Fujitsu and HP switches have been tested with the CASPER
>>>>> hardware
>>>>> and found to work as advertised.
>>>>>
>>>>> There are lots of new products available.  More announced
>>>>> all the time.  We are in contact with a number of vendors in
>>>>> hopes of getting demo units to try in house with the CASPER
>>>>> hardware before listing them as recommended for use.
>>>>> Our tests will include running at full line rates all ports
>>>>> continuously
>>>>> as that's what our intended applications require.
>>>>>
>>>>> Less demanding applications will have many more, and
>>>>> cheaper, options for suitable switch vendor and model.

Re: [casper] 10gbe switch

[John Ford]

> Can one use the zarlink (or something like it) on the ROACH end, and
> connect the fiber to an SFP+ module in the computer or switch?  It seems
> like someone ought to make such a beast, considering there are a lot of
> cx-4 ports in the field that need to be connected to new CX-4 - only

Er, make that SFP+ only

> switches and NICs.
>
> This is, I'm afraid, the downside to throwing in your lot with commercial
> products.  You're at the mercy of the markets.
>
> John
>
>
>> I am avoiding Myricom for the reasons Rick mentioned. It took a long
>> time
>> for me to get the sales/technical person to even understand that I
>> wanted
>> to
>> go from CX4 to fiber.
>>
>> But Chelsio, as several have mentioned on this list, provides the power
>> necessary for transceivers to work. They also have offloading cards
>> (which
>> I
>> believe is what you're describing) - or at least they did until the
>> discontinued their CX4 line. Not sure what the new Chelsio product line
>> will
>> look like and I am somewhat dubious that they will stay on the 4-6 week
>> timeframe. Every vendor that I and a collaborator have called are out of
>> Chelsio CX4 stock.
>>
>> Intel makes 10gbe cards, but the list archives are ambiguous as to
>> whether
>> they power the transceivers in the Zarlink cables.
>>
>> My primary concern is that if companies already see fit to discontinue
>> CX4
>> products, then (a) it is hard to connect to the ROACH now and (b) will
>> be
>> nearly impossible when something breaks in 6 years.
>>
>> How far along are the GMRT folks?
>>
>> Tom
>>
>> On Fri, Jan 28, 2011 at 6:06 PM, rick raffanti 
>> wrote:
>>
>>>  The Myricom people told me they don't make NICs with active ports- ie,
>>> aux
>>> power for the fiber translator.  That's why we bought the Chelsio.
>>> Anton is
>>> getting 6Gb/s throughput with the Chelsio- we haven't tried to push it
>>> further.  I wasn't aware of the UDP packet handling stuff, though.
>>>
>>> Rick
>>>
>>>
>>> On 1/28/2011 5:53 PM, Dan Werthimer wrote:
>>>
>>>
>>> hi tom,
>>>
>>> one more note:
>>>
>>> if you use fiber optic CX4 cables,
>>> please see the warning at
>>>
>>> http://casper.berkeley.edu/wiki/Recommended_10_GbE_Hardware
>>>
>>> not all NIC boards have built in power to support
>>> fiber optic cables.   check with myricom.
>>> the ibob/bee2/roach boards have built in power.
>>>
>>> dan
>>>
>>>
>>> On 1/28/2011 2:41 PM, Tom Downes wrote:
>>>
>>> So Chelsio has end-of-lifed their CX4 line. They say "4-6 weeks" until
>>> new
>>> cards come out as part of a new product line, but their sales contact
>>> said
>>> this reflected a larger recognition that CX4 is not how the industry is
>>> going.
>>>
>>>  My thought is that I should be buying an SFP+ card and figuring out a
>>> way
>>> to convert to CX4, e.g. SFP+->optical, optical->CX4. Our cable lengths
>>> that
>>> we will (eventually) need are all greater than 15m, so outside of the
>>> CX4
>>> spec, much less what the ROACH boards are apparently cable of driving.
>>>
>>>  Is such a transceiver scheme plausible? I am having trouble finding
>>> the
>>> appropriate parts.
>>>
>>>  Tom
>>>
>>> On Mon, Aug 9, 2010 at 8:11 AM, Matt Dexter 
>>> wrote:
>>>
>>>> Yes - when pricing switches, or any sort of (sub-)system, a full
>>>> BOM must be used to make a meaningful comparison.
>>>>
>>>> Matt
>>>>
>>>>
>>>> On Mon, 9 Aug 2010, John Ford wrote:
>>>>
>>>>  And don't forget that the switches that are XFP and SFP+ sometimes
>>>>> (usually?) don't include the optics for each port in the switch
>>>>> price.
>>>>>
>>>>> With CX4, all you need is a cable, if you're within a few meters.
>>>>>
>>>>>  Yes - that list is years old.
>>>>>> Those Fujitsu and HP switches have been tested with the CASPER
>>>>>> hardware
>>>>>> and found to work as advertised.
>>>>>>
>>>>>> There are lots of new products available.  More announced
>>>>>> all the 

Re: [casper] 10gbe switch

[John Ford]

> I'm talking with the engineers at Chelsio about just such a beast and
> expect
> a call back on Monday. I imagine I'll go with CX4 on both ends and Zarlink
> for now, but it seems like something the ROACH community needs to think
> about - sound like GMRT is doing something like this.
>
> Every time I've spoken with an engineer at Chelsio or Myricom about
> CX4-SFP+
> (probably with fiber between), the initial reaction is something like Bugs
> Bunny saying "Hansel". It's as if it were something they would never have
> considered doing in a million years. I think the conventional wisdom is
> not
> just that these transceivers can impede speed, but can also impede the
> ability of the link to remain up at all.

I got the same reaction.  It's puzzling.

I guess they weren't around for the original "waterhose" ethernet ->
10base2 -> 10baseT -> 10baseFX -> 100baseT -> 1000baseT progression.

In other words, why the heck would you *not* have a heterogenous bunch of
networks, transcievers, and media once the first working products were out
for a few years?

John

>
> Tom
>
> On Sat, Jan 29, 2011 at 9:57 AM, John Ford  wrote:
>
>> Can one use the zarlink (or something like it) on the ROACH end, and
>> connect the fiber to an SFP+ module in the computer or switch?  It seems
>> like someone ought to make such a beast, considering there are a lot of
>> cx-4 ports in the field that need to be connected to new CX-4 - only
>> switches and NICs.
>>
>> This is, I'm afraid, the downside to throwing in your lot with
>> commercial
>> products.  You're at the mercy of the markets.
>>
>> John
>>
>>
>> > I am avoiding Myricom for the reasons Rick mentioned. It took a long
>> time
>> > for me to get the sales/technical person to even understand that I
>> wanted
>> > to
>> > go from CX4 to fiber.
>> >
>> > But Chelsio, as several have mentioned on this list, provides the
>> power
>> > necessary for transceivers to work. They also have offloading cards
>> (which
>> > I
>> > believe is what you're describing) - or at least they did until the
>> > discontinued their CX4 line. Not sure what the new Chelsio product
>> line
>> > will
>> > look like and I am somewhat dubious that they will stay on the 4-6
>> week
>> > timeframe. Every vendor that I and a collaborator have called are out
>> of
>> > Chelsio CX4 stock.
>> >
>> > Intel makes 10gbe cards, but the list archives are ambiguous as to
>> whether
>> > they power the transceivers in the Zarlink cables.
>> >
>> > My primary concern is that if companies already see fit to discontinue
>> CX4
>> > products, then (a) it is hard to connect to the ROACH now and (b) will
>> be
>> > nearly impossible when something breaks in 6 years.
>> >
>> > How far along are the GMRT folks?
>> >
>> > Tom
>> >
>> > On Fri, Jan 28, 2011 at 6:06 PM, rick raffanti 
>> > wrote:
>> >
>> >>  The Myricom people told me they don't make NICs with active ports-
>> ie,
>> >> aux
>> >> power for the fiber translator.  That's why we bought the Chelsio.
>> >> Anton is
>> >> getting 6Gb/s throughput with the Chelsio- we haven't tried to push
>> it
>> >> further.  I wasn't aware of the UDP packet handling stuff, though.
>> >>
>> >> Rick
>> >>
>> >>
>> >> On 1/28/2011 5:53 PM, Dan Werthimer wrote:
>> >>
>> >>
>> >> hi tom,
>> >>
>> >> one more note:
>> >>
>> >> if you use fiber optic CX4 cables,
>> >> please see the warning at
>> >>
>> >> http://casper.berkeley.edu/wiki/Recommended_10_GbE_Hardware
>> >>
>> >> not all NIC boards have built in power to support
>> >> fiber optic cables.   check with myricom.
>> >> the ibob/bee2/roach boards have built in power.
>> >>
>> >> dan
>> >>
>> >>
>> >> On 1/28/2011 2:41 PM, Tom Downes wrote:
>> >>
>> >> So Chelsio has end-of-lifed their CX4 line. They say "4-6 weeks"
>> until
>> >> new
>> >> cards come out as part of a new product line, but their sales contact
>> >> said
>> >> this reflected a larger recognition that CX4 is not how the industry
>> is
>> >> goin

Re: [casper] ROACH 2: it exists

[John Ford]

That's awesome, David.  Can't wait for the first R-II Spectrometer... 
We'll be waiting for more news!

John

> Hi All.
>
> As you may know a new CASPER board is in the pipeline called ROACH 2.
> The design is centred around a Xilinx Virtex-6 SX475T FPGA. It should
> be, roughly, a 4-times improvement in terms of overall performance
> over ROACH 1.
>
> Well, the board arrived from assembly just under a week ago and I have
> been working at trying to get it to do stuff (other than emit smoke).
> The board now boots into uboot, we can JTAG in an FPGA bitstream and
> the PowerPC can successfully "talk" to the FPGA. The FTDI USB to JTAG
> + serial works like a charm (which is lucky because neither the Xilinx
> and Macraigor programmer play along with the JTAG chain).
>
> So hopefully progress will be good over the coming weeks so we can
> start making lots of these board soon;)
>
> The wiki page is hopelessly out of date, but includes some more
> information about ROACH 2:
> http://casper.berkeley.edu/wiki/ROACH2
>
> I have also uploaded a video of the board in action for your
> enjoyment. You can view the video directly here:
> http://casper.berkeley.edu/wiki/images/d/d1/Roach2_knight_rider.mpg
>
> Expect more updates on the casper lists and the wiki soon.
>
> All the best,
> David
>
> --
> David George
> Karoo Array Telescope
> Tel: +27 11 442-2434
> Email: david.geo...@ska.ac.za
>

Re: [casper] Licensing dsp tools 10.1

[John Ford]

>  Dear Casperites,
>
>  I'v been having troubles synthesizing the spectrometer, so I wanted to
>  try a different version of every tool I'm using (Ubuntu
>  Lynx/Matlab2009b/Xilinx 11.4 to WinXP/Matlab2007b/Xilinx 10.1) but I
>  can't have dsp tools installed, I installed Xilinx Webpack 10.1 and I
>  execute the dsp_tools installer, the program ask me for a registration
>  ID (I use what xilinx gave me for webpack) but that is not the right
>  one. I can't even have a 30 day trial, so my question is how did you
>  guys can work with this old version for free?

Hi Daniel.  I don't know if you can make these tools work on the ubuntu
system. but anyway, we got our 10.1 toolset through the XUP program. 
Since you are in Chile, that might not work for you, I don't know.

You should be sure to use the versions of the tools specified on the
casper web page, or you may run into trouble...

Can you send your .mdl file to someone and have them try to synthesize it
on a known-working installation?

John


>
>  Kind regards,
>
>  Daniel H.
>

[casper] [Fwd: [Usnc-ursi-j] Deadline for pulsar session in URSI-GA extended to March 4]

[John Ford]

 Original Message 
Subject: [Usnc-ursi-j] Deadline for pulsar session in URSI-GA extended to
March 4
From:"Matsakis, Demetrios" 
Date:Wed, March 2, 2011 6:38 am
To:  "usnc-urs...@nrao.edu" 
--

The URSI General Assembly will take place in Istanbul, Turkey from August
13-20.  You can submit from http://www.ursigass2011.org/

If you have any questions contact Demetrios Masakis (d...@usno.navy.mil)
and/or Michael Kramer (prof.kra...@gmail.com).
___
usnc-ursi-j mailing list
usnc-urs...@listmgr.cv.nrao.edu
http://listmgr.cv.nrao.edu/mailman/listinfo/usnc-ursi-j


The URSI General Assembly will take place in Istanbul, Turkey from August 13-20.  You can submit from http://www.ursigass2011.org/
 
If you have any questions contact Demetrios Masakis (d...@usno.navy.mil) and/or Michael Kramer (prof.kra...@gmail.com).

Re: [casper] Fujitsu XG2000C / where to buy?

[John Ford]

> Hello,
>
> The 10GbE hardware page[1] has not been updated in a while (June 2009),
> and I wonder someone had the chance to test other kind of switches.
>
> For now, I think that the best choice is the Fujitsu XG2000C. Any
> recommendation of distributor/reseller in US? I have quotations right
> now from Dell (~$13k) and ConRes IT Solutions (~$12k), still waiting for
> PC-Rush, and trying to contact the people of Synnex.
>
> [1] CASPER, Recommended 10 GbE Hardware,
> http://casper.berkeley.edu/wiki/Recommended_10_GbE_Hardware
>
> Thanks in advance for your information,

I think we bought the one for GUPPI from Dell.  The prices you quote seem
to be about what we paid for ours.

John

>
> --
> Luis A. Quintero
> NAIC Arecibo Observatory
>
>
>

Re: [casper] Roach NFS root and static IP

[John Ford]

> Hello list,
>
> I'm trying to give a roach a static IP since dhcp is not allowed. There is
> http://gmrt.ncra.tifr.res.in/gmrt_hpage/sub_system/corr/Iru/Roach_BOOT_proc1_V3.pdf
> which says bootargs can have ip=::. So I'm
> trying this:
>
> setenv bootargs console=ttyS0,115200n8 noinitrd rw
> ip=10.0.2.101:10.0.2.1:255.255.255.0 root=/dev/nfs
> nfsroot=10.0.2.94:/rdbe/rdbe_image,nolock
>
> saveenv
>
> Is that ip=... really the proper syntax?
>

Hi.   Here's the boot args from our bee2, if it helps:

BEE2 % get_eeprom

Command line: console=tty0 console=ttyS0,115200
nfsroot=/export/home/tofu/cicadaroots/bee2Guppi
ip=169.254.128.20:169.254.128.6:169.254.128.6:255.255.255.0:bee2
:eth0:off mem=512M rw root=/dev/nfs

MAC address: 006D12B222

Baud rate: 115200

Serial number: 2.2.47

Checksum: 25

BEE2 %



John

Re: [casper] Roach NFS root and static IP

[John Ford]

> Thanks John, David,
>
> thanks for pointers, the correct syntax worked and the ip, gateway,
> netmask are now correct
> (ip=ownip:nfsip:gatewayip:netmask:hostname:eth0:off)
>
> That Roach_BOOT_proc1_V3.pdf was not very good.
>
> Still some reliability issue, sometimes boot&NFS mount work fine, but many
> times during boot I can not ping the roach and get a timeout
>
>Looking up port of RPC 13/2 on 10.0.2.94
>rpcbind: server 10.0.2.94 not responding, timed out
>
> Very possibly a local network issue. D-Link DES 1008D switches do not seem
> to work well at 5100m altitude :P

Our booting is very reliable.  But we're at ~850m!

John

>
>   - Jan
>
> On Mon, 21 Mar 2011, John Ford wrote:
>
>>> Hello list,
>>>
>>> I'm trying to give a roach a static IP since dhcp is not allowed. There
>>> is
>>> http://gmrt.ncra.tifr.res.in/gmrt_hpage/sub_system/corr/Iru/Roach_BOOT_proc1_V3.pdf
>>> which says bootargs can have ip=::. So I'm
>>> trying this:
>>>
>>> setenv bootargs console=ttyS0,115200n8 noinitrd rw
>>> ip=10.0.2.101:10.0.2.1:255.255.255.0 root=/dev/nfs
>>> nfsroot=10.0.2.94:/rdbe/rdbe_image,nolock
>>>
>>> saveenv
>>>
>>> Is that ip=... really the proper syntax?
>>>
>>
>> Hi.   Here's the boot args from our bee2, if it helps:
>>
>> BEE2 % get_eeprom
>>
>> Command line: console=tty0 console=ttyS0,115200
>> nfsroot=/export/home/tofu/cicadaroots/bee2Guppi
>> ip=169.254.128.20:169.254.128.6:169.254.128.6:255.255.255.0:bee2
>> :eth0:off mem=512M rw root=/dev/nfs
>>
>> MAC address: 006D12B222
>>
>> Baud rate: 115200
>>
>> Serial number: 2.2.47
>>
>> Checksum: 25
>>
>> BEE2 %
>>
>>
>>
>> John
>>
>>
>>
>

Re: [casper] ROACH-2 prototypes working well

[John Ford]

This is awesome work, guys!  We're excited about these new boards.

John

> Hi All.
>
> ROACH-2 development and testing has gone well over the last two months. At
> this point we have tested the two prototype boards and are happy that
> everything works. While there were a number of minor issues, we were able
> to
> get everything functioning with a few blue wires and a steady hand. The
> only
> item untested is the DRAM, for which I blame Xilinx's trigger happy memory
> interface group. Work will now start on fixing the various issues.
>
> Have a look at the wiki page for all the latest details and pics:
> http://casper.berkeley.edu/wiki/ROACH2
>
> There is a particularly nice image of the board with two CX4 mezzanine
> cards
> attached (and working!):
> http://casper.berkeley.edu/wiki/Image:Roach2_rev0_2xcx4mezz.jpg
>
> For those who are particularly interested, we are planning to have a
> telecon
> next week Wednesday to discuss the hardware fixes, changes and the way
> forward. This will happen at the regular ROACH telecon time. I'll post
> these
> details a little later.
>
> Kind regards,
> David
>
> --
> David George
> Karoo Array Telescope
> Tel: +27 11 442-2434
>

Re: [casper] Roach: Getting Started Enviroment 2011

[John Ford]

> Hi Miguel,
>
> For 2, put load_system('xps_library'), load_system('casper_library') and
> load_system('gavrt_library') into your startup.m may solve this issue.
> It is due to the libraries are not initialized properly.

Also, note that the "Parameterized link" warning is normal, and does not
cause trouble.  It's due to the library blocks disconnecting from the
library when they redraw, if I remember right.

You can/should ignore them.

John



>
> For 3, the posedge block has been changed from 'Misc/pulse_ext/posedge'
> to 'Misc/posedge' in casper_library, up one level. Just replace it with
> a new one inside 'pkt_sim' block.
>
> For 4, I'm not sure but could you please try if this 'clock pin' trick
> helps? see:
> http://www.mail-archive.com/casper@lists.berkeley.edu/msg01070.html for
> detail.
> It is mentioned at the last section of
> http://casper.berkeley.edu/wiki/Xilinx_ISE_11.4_Setup
>
> For casper tools running environment, we use below combination
>
> CentOS 5.5 x86_64
> Matlab 2009b
> Xilinx ISE 11.5
>
> If you need to run python client scripts on CentOS 5.5, you must install
> a separate python 2.6 from EPEL repository and manually compile numpy,
> matplotlib, ipython, katcp, corr etc.
>
>
> Zhu Yan
>
>
>
> On 4/5/2011 5:58 PM, Mark Wagner wrote:
>> Hi Miguel,
>>
>> For 2, try opening a new model file and putting in the XSG_core_config
>> and System Generator blocks, pulling them from their libraries.  Then
>> open up tut1 and copy everything except the XSG_core_config and the SG
>> blocks and paste it into your new model file. Save and ctrl-D.  If that
>> doesn't work, you may have to redraw tut1 from scratch.
>>
>> Mark
>>
>>
>> On Tue, Apr 5, 2011 at 3:54 AM, ---> Miguel A. S. G <---
>> mailto:migu...@gmail.com>> wrote:
>>
>> Hi Mark,
>> Thank you for your quick reply. Following your instructions...
>> 1.- It's solved.
>> 2.- It's not solved. I mean, I swapped the blocks of tut1.mdl with
>> blocks from my library. Save the model, close matlab, open matlab
>> and same "bad links" appear.
>> 3 and 4.- Im not at work now so.. tomorrow i will try it.
>> Thank you anyway!
>> Miguel.
>>
>> *From:* Mark Wagner 
>> *Sent:* Monday, April 04, 2011 9:05 PM
>> *To:* migu...@gmail.com 
>> *Cc:* casper@lists.berkeley.edu 
>> *Subject:* Re: [casper] Roach: Getting Started Enviroment 2011
>>
>> Hi Miguel,
>>
>> Sorry you're having so much trouble.
>>
>> 1. This is just a warning you're getting and doesn't hav any effect
>> on the functionality of the toolflow, but you can comment out:
>>
>> Browser(2).Library = 'testbench_lib';
>> Browser(2).Name= 'Testbench Blockset';
>>
>> in mlib_devel/gavrt_library/slblocks.m, and you should stop getting
>> that warning.
>>
>> 2.  I think this is because you are opening up the model file with a
>> newer library than what it was originally created with.  But I think
>> you solved this already by deleting the block and pulling from the
>> library you're opening the model file with.
>>
>> 3.  If you look at this posedge, I think it's not being loaded
>> correctly.  If you try deleteing and replacing the posedge
>> (tut2/pkt_sim/posedge) like you did in 2, it should fix the problem.
>>
>> 4. I'm not sure what the issue is here, but try ctrl-D, which will
>> update the design and propagate the data types and hopefully it will
>> give a more telling error.
>>
>> Best,
>> Mark
>>
>>
>> On Tue, Apr 5, 2011 at 1:43 AM, > > wrote:
>>
>> Hi Griffin,
>> Thank you so much!!
>> About the first option
>> centos 5.3 / Xilinx ISE 11.4 / Matlab 2009b
>> Are  Casper Libraries compatibles with? I mean, don’t are they
>> build for Ise 10.1?
>> My problems?  Ok let’s go step by step:
>> 1) Each time I open simulink:
>> Warning: Could not find library ‘testbench_lib’ o speciefied in
>> ‘C:\codigos\mlib_devel\gavrt_library\slblocks.m’
>> 2) The first time i open a model all the yellow blocks are “bad
>> link” and matlab welcomes me with a lot of warnigs like:
>> “Warning: "tut1/counter_value" is a parameterized link. To view,
>> discard, or propagate the changes for this link,
>> use the "Link Options" menu item.”
>> With the tutorial 2 I also get four warnings like,
>> “Warning: casper_library_misc.mdl, line 5905: block_diagram does
>> not have a parameter named 'BlockName'”.
>> And others warning about a parameter "SID” (I can remember a
>> discussion about SID in the casper list)
>> Anyway, then I pick up an element from BEE_XPS System Blockset
>> (i can see this library in the simulink library browser) , put
>> it in the model and the yellow blo

Re: [casper] Roach: Getting Started Enviroment 2011

[John Ford]

> Wow! Thank you for your replies!
>
> Ok let's see:
>
> 1) It was solved with Mark instructions
>
> 2) It's solved following Zhu instructions
>
> 3) It's also ok by replacing the block as you suggested me.

Excellent!

>
> 4) It's better but i still get an error. After 2 hours and a half I get
> the
> following error. Must i follow the instructions and it doesn't matter?:

Unfortunately this error is real.  Ignoring timing errors is not a good
idea in general.  Is this on a tutorial that's known to build?  If it's on
your own design, you'll need to modify it or simplify it in some way. 
Maybe fewer taps in the PFB, or fewer channels in the FFT?

It's interesting and helpful to use the timing analyzer to show the paths
that don't meet timing.  Then you can adjust latencies and add delays to
compensate sometimes.  You might gain timing margin by inserting delay
blocks (registers) in the wires from the ADC to the rest of the system, or
wherever the timing analyzer shows the problem.

John

>
>
> #--#
> # Starting program post_par_trce
> # trce -e 200 -xml system.twx system.ncd system.pcf
> #--#
> Release 10.1.03 - Trace  (nt)
> Copyright (c) 1995-2008 Xilinx, Inc.  All rights reserved.
>
>
> Loading device for application Rf_Device from file '5vsx95t.nph' in
> environment
> c:\Xilinx\10.1\ISE.
>"system" is an NCD, version 3.2, device xc5vsx95t, package ff1136,
> speed -1
> WARNING:ConstraintSystem:65 - Constraint "r_spec_2048_r105_adc/r_spec_2048_r105_adc/adc_clk_buf" PERIOD = 5 ns
> HIGH
> 50%;> [system.pcf(39150)] overrides constraint "r_spec_2048_r105_adc/r_spec_2048_r105_adc/adc_clk_buf" PERIOD = 5 ns
> HIGH
> 50%;> [system.pcf(39148)].
>
> INFO:Timing:3377 - Intersecting Constraints found and resolved.  For more
>information see the TSI report.
> 
> Release 10.1.03 Trace  (nt)
> Copyright (c) 1995-2008 Xilinx, Inc.  All rights reserved.
>
> trce -e 200 -xml system.twx system.ncd system.pcf
>
>
> Design file:  system.ncd
> Physical constraint file: system.pcf
> Device,speed: xc5vsx95t,-1 (PRODUCTION 1.64 2008-12-19,
> STEPPING
> level 0)
> Report level: error report, limited to 200 items per
> constraint
> 
>
> INFO:Timing:2752 - To get complete path coverage, use the unconstrained
> paths
>option. All paths that are not constrained will be reported in the
>unconstrained paths section(s) of the report.
> INFO:Timing:3339 - The clock-to-out numbers in this timing report are
> based
> on a
>50 Ohm transmission line loading model.  For the details of this model,
> and
>for more information on accounting for different loading conditions,
> please
>see the device datasheet.
>
>
> Timing summary:
> ---
>
> Timing errors: 34  Score: 3676
>
> Constraints cover 279937 paths, 1 nets, and 50172 connections
>
> Design statistics:
>Minimum period:  11.245ns (Maximum frequency:  88.928MHz)
>Maximum net delay:   1.637ns
>
>
> Analysis completed Tue Apr 05 17:11:06 2011
> 
>
> Generating Report ...
>
> Number of warnings: 1
> Number of info messages: 3
> Total time: 1 mins 10 secs
>
>
> xflow done!
> touch __xps/system_routed
> xilperl C:/Xilinx/10.1/EDK/data/fpga_impl/observe_par.pl -error yes
> implementation/system.par
> Analyzing implementation/system.par
> 
> ERROR: 1 constraint not met.
>
> PAR could not meet all timing constraints. A bitstream will not be
> generated.
>
> To disable the PAR timing check:
>
> 1> Disable the "Treat timing closure failure as error" option from the
> Project Options dialog in XPS.
>
> OR
>
> 2> Type following at the XPS prompt:
> XPS% xset enable_par_timing_error 0
> 
> make: *** [implementation/system.bit] Error 1
> ERROR:MDT - Error while running "make -f system.make bits"
> No changes to be saved in MSS file
> Saved project XMP file
> Error using ==> gen_xps_files at 680
> Programation files generation failed, EDK compilation probably also
> failed.
>
>
>
>
>
>
> -Mensaje original-
> From: John

Re: [casper] Roach: Getting Started Enviroment 2011

[John Ford]

> Hi John,
>>
>> 4) It's better but i still get an error. After 2 hours and a half I get
>> the
>> following error. Must i follow the instructions and it doesn't matter?:
>
> Unfortunately this error is real.  Ignoring timing errors is not a good
> idea in general.  Is this on a tutorial that's known to build?  If it's on
> your own design, you'll need to modify it or simplify it in some way.
> Maybe fewer taps in the PFB, or fewer channels in the FFT?
>
> No is not my own design. I was trying to run Roach tutorial 3 downloaded
> from Casper web site
> (http://casper.berkeley.edu/svn/trunk/ref_designs_tutorials/workshop_2010/roach_tut3_wideband_spec/).
> I was trying to run the tutorials before running my own design just to be
> sure about my configuration.
>
> So..  do i have to modify the original model?

Hmm.

I would have thought the tutorial would successfully compile without you
having to modify it.  We don't have a working 10.1 installation at
present, so I can't try it on that.  Have you got the latest update of
10.1 from xilinx?  That might make a difference.

As a test, try reducing the number of channels in the FFT and compile it
again to see if it can route that successfully.

John

>
>
> -Mensaje original-
> From: John Ford
> Sent: Wednesday, April 06, 2011 2:58 PM
> To: migu...@gmail.com
> Cc: casper@lists.berkeley.edu
> Subject: Re: [casper] Roach: Getting Started Enviroment 2011
>
>> Wow! Thank you for your replies!
>>
>> Ok let's see:
>>
>> 1) It was solved with Mark instructions
>>
>> 2) It's solved following Zhu instructions
>>
>> 3) It's also ok by replacing the block as you suggested me.
>
> Excellent!
>
>>
>> 4) It's better but i still get an error. After 2 hours and a half I get
>> the
>> following error. Must i follow the instructions and it doesn't matter?:
>
> Unfortunately this error is real.  Ignoring timing errors is not a good
> idea in general.  Is this on a tutorial that's known to build?  If it's on
> your own design, you'll need to modify it or simplify it in some way.
> Maybe fewer taps in the PFB, or fewer channels in the FFT?
>
> It's interesting and helpful to use the timing analyzer to show the paths
> that don't meet timing.  Then you can adjust latencies and add delays to
> compensate sometimes.  You might gain timing margin by inserting delay
> blocks (registers) in the wires from the ADC to the rest of the system, or
> wherever the timing analyzer shows the problem.
>
> John
>
>>
>>
>> #--#
>> # Starting program post_par_trce
>> # trce -e 200 -xml system.twx system.ncd system.pcf
>> #--#
>> Release 10.1.03 - Trace  (nt)
>> Copyright (c) 1995-2008 Xilinx, Inc.  All rights reserved.
>>
>>
>> Loading device for application Rf_Device from file '5vsx95t.nph' in
>> environment
>> c:\Xilinx\10.1\ISE.
>>"system" is an NCD, version 3.2, device xc5vsx95t, package ff1136,
>> speed -1
>> WARNING:ConstraintSystem:65 - Constraint >"r_spec_2048_r105_adc/r_spec_2048_r105_adc/adc_clk_buf" PERIOD = 5 ns
>> HIGH
>> 50%;> [system.pcf(39150)] overrides constraint >"r_spec_2048_r105_adc/r_spec_2048_r105_adc/adc_clk_buf" PERIOD = 5 ns
>> HIGH
>> 50%;> [system.pcf(39148)].
>>
>> INFO:Timing:3377 - Intersecting Constraints found and resolved.  For
>> more
>>information see the TSI report.
>> 
>> Release 10.1.03 Trace  (nt)
>> Copyright (c) 1995-2008 Xilinx, Inc.  All rights reserved.
>>
>> trce -e 200 -xml system.twx system.ncd system.pcf
>>
>>
>> Design file:  system.ncd
>> Physical constraint file: system.pcf
>> Device,speed: xc5vsx95t,-1 (PRODUCTION 1.64 2008-12-19,
>> STEPPING
>> level 0)
>> Report level: error report, limited to 200 items per
>> constraint
>> 
>>
>> INFO:Timing:2752 - To get complete path coverage, use the unconstrained
>> paths
>>option. All paths that are not constrained will be reported in the
>>unconstrained paths section(s) of the report.
>> INFO:Timing:3339 - The clock-to-out numbers in this timing report are
>> based
>> on a
>>50 Ohm transmission line loading model.  For the details of this
>