Re: [casper] CASPER Advisory Board
Hi Francois: This is Homin from Taiwan. Hope all is well with you. I would like to nominate Mitch Burnett as a new member of the advisory board. Mitch has come up with a whole set of RFSoC stuff, it is a great contribution to the community. Grabbing him in the advisory board will make him contribute even more. best homin On Thu, Mar 3, 2022 at 8:38 PM Francois Kapp wrote: > > Dear casperites, > > As we gradually emerge from the 2 year pandemic imposed hiatus of almost > everything, this is a long overdue message to announce that I have taken over > as chair of the CASPER advisory board from Jack Hickish. I want to take this > opportunity to thank Jack for the years that he was the chair and all the > fantastic work that he has done for CASPER. > > We are also looking for nominations for some new members of the Advisory > Board. We encourage diversity in membership in as many dimensions as > feasible. Please submit nominations to me or to any of the other current > Advisory Board members that you know. You can find the current members here: > https://casper.berkeley.edu/index.php/about/casper-advisory-board/ > > A nomination should be accompanied by a brief motivation that at least > includes the rationale for the nomination, and preferably sufficient > information for the Advisory Board to make a decision. If necessary, we will > seek additional information regarding nominees - either from the person who > nominated them or via any other reasonable means. > > We are looking forward to the next workshop to be hosted in Sardinia from 5 - > 9 September 2022 - hopefully many of us will be able to attend in person. > > As always, it bears reminding that CASPER is a collection of volunteers, > often contributing to the collaboration in their personal capacity, after > hours, over weekends, or whenever there is a spare moment. Please continue > to respect this and be mindful of increasing the workload that these > volunteers need to juggle. If you are in any doubt whatsoever about the code > of conduct that is expected, you can read the document here: > https://casper.berkeley.edu/index.php/code-of-conduct/ > > I welcome any input from the community, but please send it to me directly to > respect the inboxes of everyone on the list. I will also try to keep > communication to a minimum, while recognising we probably undershot that mark > in recent months. I would also like to remind the community that we have a > means of receiving anonymous information, should that be necessary, via a > Google Form here: https://goo.gl/forms/u7rNWXrOfJc6DFcf2 > > On behalf of the CASPER Advisory Board, > Francois > > > > -- > 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/CAB4_c0qGvMmt6Sn1sc6EjGsJqtwxZutiDs09sbKC9gSnJMSd4g%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/CAGbeiKj9vozbOXxLYZwkpf%2BikSBdA9eK0nuYekaMckZiB7bkvA%40mail.gmail.com.
[casper] X engine green block
Dear all: Hope that you are well all. Recently we have an issue about correlation that motivates me to dig in the X engine block. Found that it might be a bug in the X engine block. I compare the current X engine with the one a couple years ago, "mdl" era. The difference is that there is one more delay in the current X engine. The older one has no problem. They are here: --- Xengine -> auto_tap, baseline_tap1, baseline_tap2, ... baseline_tapn -> dual_pol_cmac->cmac2, cmac3, cmac4-> cmult -> latency -> change "convert latency" from 1 to 0. -- If you used directly, the output will not be exactly correct. best regards 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 view this discussion on the web visit https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAGbeiKjwbDbi3C3XFLbgzsiZ4bKvcD1jvgP7Z5TbLrDc-PFWUw%40mail.gmail.com.
Re: [casper] casperites receive breakthough prize
Dear Dan and all: Congratulate to the EHT collaboration, thanks to the entire CASPER community of supporting this ground-breaking science. You all should be proud by yourselves. EHT is a very good example of collaboration as well as CASPER. Let us keep going. And I am very keen to see next breakthrough event by casperites. Best Regards. Homin Jiang On Fri, Sep 6, 2019 at 12:06 AM Dan Werthimer wrote: > > > casperites, > > several casper people received the breakthrough prize today for making the > first image of a black hole, > including jonathan weintroub, homin jiang, nimish patel, matt dexter, arash > roshanineshat, laura vertaschitsch, and casper co-founder mel wright. > the $3M prize is divided equally by the 347 member event horizon telescope > team listed below, so our fellow casperite's aren't rich. > > details at https://breakthroughprize.org/News/54 > > dan > > > > Kazunori Akiyama, Antxon Alberdi, Walter Alef, Juan-Carlos Algaba, Alexander > Allardi, Rodrigo Amestica, Jadyn Anczarski, Keiichi Asada, Rebecca Azulay, > Uwe Bach, Anne-Kathrin Baczko, Frederick K. Baganoff, David Ball, Mislav > Baloković, John Barrett, Christopher Beaudoin, Bradford A. Benson, Ryan > Berthold, Dan Bintley, Lindy Blackburn, Jay M. Blanchard, Ray Blundell, > Wilfred Boland, Katherine L. Bouman, Geoffrey C. Bower, Michael Bremer, > Christiaan D. Brinkerink, Roger Brissenden, Silke Britzen, Avery E. > Broderick, Dominique Broguiere, Thomas Bronzwaer, Sandra Bustamente, Do-Young > Byun, Roger Cappallo, John E. Carlstrom, Edgar Castillo-Domínguez, Andrew > Chael, Chi-kwan Chan, Chih-Cheng Chang, Shu-Hao Chang, Song-Chu Chang, Shami > Chatterjee, Koushik Chatterjee, Ming-Tang Chen, Chung-Chen Chen, Yongjun Chen > (陈永军), Ryan Chilson, Ilje Cho, Pierre Christian, Tim C. Chuter, John E. > Conway, James M. Cordes, Rodrigo Córdova Rosado, Iain M. Coulson, Thomas M. > Crawford, Geoffrey B. Crew, Joseph Crowley, Yuzhu Cui, Jordy Davelaar, John > David, Mariafelicia De Laurentis, Roger Deane, Jessica Dempsey, Mark Derome, > Gregory Desvignes, Jason Dexter, Matthew Dexter, Sheperd S. Doeleman, Sven > Dornbusch, Sergio A. Dzib, Ralph P. Eatough, Andreas Eckart, Chris Eckert, > Neal R. Erickson, Wendeline B. Everett, Aaron Faber, Heino Falcke, Joseph R. > Farah, Vernon Fath, Vincent L. Fish, Thomas W. Folkers, Ed Fomalont, David C. > Forbes, Raquel Fraga-Encinas, William T. Freeman, Robert Freund, Per Friberg, > Christian M. Fromm, David M. Gale, Peter Galison, Charles F. Gammie, Feng > Gao, Roberto García, Gertie Geertsema, Olivier Gentaz, Boris Georgiev, > Ciriaco Goddi, Roman Gold, José L. Gómez, Arturo I. Gómez-Ruiz, David A. > Graham, Christopher H. Greer, Ronald Grosslein, Minfeng Gu(顾敏峰), Frédéric > Gueth, Mark Gurwell, Kazuhiro Hada, Daryl Haggard, Nils W. Halverson, > Chih-Chiang Han, Kuo-Chang Han, Jinchi Hao, Yutaka Hasegawa, Michael H. > Hecht, Jason W. Henning, Antonio Hernández-Gómez, Rubén Herrero-Illana, > Ronald Hesper, Stefan Heyminck, Akihiko Hirota, Paul Ho, Luis C. Ho (何子山), > James Hoge, Mareki Honma, Chih-Wei L. Huang, Yau-De Huang, Lei Huang (黄磊), > David H. Hughes, Shiro Ikeda, C. M. Violette Impellizzeri, Makoto Inoue, Sara > Issaoun, David J. James, Huib Jan van Langevelde, Buell T. Jannuzi, Michael > Janssen, Britton Jeter, Homin Jiang, Wu Jiang (江悟), Michael D. Johnson, > Svetlana Jorstad, Taehyun Jung, Atish Kamble, Mansour Karami, Ramesh > Karuppusamy, Tomohisa Kawashima, Garrett K. Keating, Ryan Keisler, Mark > Kettenis, Jae-Young Kim, Junhan Kim, Jongsoo Kim, Kimihiro Kimura, Motoki > Kino, Patrick M. Koch, Yusuke Kono, Shoko Koyama, Michael Kramer, Carsten > Kramer, Thomas P. Krichbaum, Derek Kubo, Cheng-Yu Kuo, John Kuroda, Richard > Lacasse, Robert A. Laing, Tod R. Lauer, Sang-Sung Lee, Erik M. Leitch, > Chao-Te Li, Yan-Rong Li (李彦荣), Zhiyuan Li (李志远), Lupin C.-C. Lin, Michael > Lindqvist, Kuo Liu, Ching-Tang Liu, Kuan-Yu Liu, Elisabetta Liuzzo, Wen-Ping > Lo, Andrei P. Lobanov, Laurent Loinard, Colin Lonsdale, Li-Ming Lu, Ru-Sen Lu > (路如森), Nicholas R. MacDonald, Jirong Mao (毛基荣), Sera Markoff, Daniel P. > Marrone, Alan P. Marscher, Ralph G. Marson, Pierre L. Martin-Cocher, Iván > Martí-Vidal, Kyle D. Massingill, Satoki Matsushita, Lynn D. Matthews, Callie > Matulonis, Martin P. McColl, Stephen R. McWhirter, Lia Medeiros, Karl M. > Menten, Hugo Messias, Zheng Meyer-Zhao, Daniel Michalik, Yosuke Mizuno, Izumi > Mizuno, Alfredo Montaña, William Montgomerie, Matias Mora-Klein, James M. > Moran, Kotaro Moriyama, Monika Moscibrodzka, Dirk Muders, Cornelia Müller, > Andrew Nadolski, Hiroshi Nagai, Neil M. Nagar, Masanori Nakamura, Ramesh > Narayan, Gopal Narayanan, Iniyan Natarajan, Santiago Navarro, Joseph Neilsen, > Roberto Neri, Chi H.
Re: [casper] VCU118 Support
Hi Jack: I modified the vivado version from 2018.2 to 2018.1 in a file under cont_microblaze. The compilation is fine and completed. Bitcodes are generated. I have the UART output as following. My problem is the DHCP i guess. Looks like the DHCP didn't work. Usually, the led right next to the RJ45 port should be flashing for some time, but in my case, that led was so quiet. I have the dhcp running at computer side. Did i do something wrong? best homin --- # JAM starting Built 2019/01/14-17:46-0800 jackh@acme1 mlib_devel-2010-09-20-2405-gb46bd8d264 # Compiled without XADC support # Compiled without SPI flash support # Compiled without ICAPE support using ethernet core gbe MAC 0x020304050118 IP NM GW link is UP On Tue, Jan 15, 2019 at 11:23 AM Jack Hickish wrote: > > Hi CASPERites, > > I know a few of you have been playing around with the VCU118 Virtex > Ultrascale Plus dev board. For a while the toolflow has been able to compile > designs for this board, but without any support for accessing the software > registers / brams in the generated bitstream (making the toolflow effectively > useless). > > The VCU118 branch of mlib_devel -- > https://github.com/casper-astro/mlib_devel/tree/vcu118 -- now supports > compiling a VCU118 design with an embedded microblaze core, which allows you > to talk to the board using the standard casperfpga library. > > Note the following caveats -- > > - use the latest version of casperfpga > (https://github.com/casper-astro/casperfpga, currently at commit ee9c43f ) > and install the dependencies with `pip install -r requirements.txt` before > installing casperfpga with `python setup.py install`. I strongly recommend > using a python virtual environment to be sure you are using the right > libraries. Note that the dependencies include a custom tftpy **not the one > obtained with `pip install tftpy`. > - casperfpga comms are (currently) only supported through the VCU118's 1GbE > RJ45 port > - You must instantiate a 1GbE yellow block in your design - see > https://github.com/casper-astro/mlib_devel/blob/vcu118/jasper_library/test_models/test_onegbe.slx > for a simple example > - You must check the "enable microblaze" checkbox in the VCU118 configuration > block. > - I tested using MATLAB 2017b and Vivado 2018.2. Use other versions of > software at your own risk. In particular, other versions of Vivado will > probably fail spectacularly. > - Your VCU118 will attempt to DHCP an IP address on boot. It has the MAC > address 02:03:04:05:01:18 . Once DHCP is complete, you should be able to ping > the board. > - Debugging information can be obtained on the VCU's USB UART port, with your > serial interface set to 115200 8N1. > - You must program the bitstream generated by the toolflow manually via JTAG > in vivado (the bitstream can be found at > /myproj/myproj.runs/impl_1/top.bit). casperfpga's > upload_to_ram_and_program command **will NOT work**. > > There is still a bunch of work to do to support this board -- for example: > supporting writing an image to the onboard flash, getting a unique per-board > MAC address, supporting other peripherals (notably 100GbE, which some > CASPERites are already working on, and an FMC ADC from ASIAA), etc. etc. But > for now, hopefully this zeroth-order support will help with other yellow > block development efforts, by allowing you to probe the board without > resorting to the joy of the vivado logic analyzer. > > Further help always appreciated, and feel free to shout when the above > doesn't work for you. > > Jack > > -- > 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] Vivado System Generator cannot find parts
Hi Arash and all :
I tried Vivado 2018.1 with Matlab 2018a under scientific Linux 7.0, after
struggling a while, it is fine now.
Back to "hardware porting" workshop last summer, l had the issue of FPGA
model name as Adam mentioned. It have to be exactly the same.
best regards
homin
On Fri, Dec 14, 2018 at 2:51 AM Arash Roshanineshat <
aroshanines...@email.arizona.edu> wrote:
> Hi all
>
> I'm trying to get CASPER toolflow running with latest version of Xilinx
> Vivado and I have faced some issues.
>
> First I started with Vivado 2018.2 and Matlab 2017b. At this point, there
> is no information about supported versions of Matlab for Vivado 2018.2 in
> the official website:
>
> https://www.xilinx.com/support/answers/55830.html
>
> So I decided to try Matlab 2017b but it didn't work. There were issues
> with libstdc++.so.6. So in case you get errors like this:
>
> ***
> cp: cannot stat
> `/home/Xilinx/2018/Vivado/2018.2/lib/lnx64.o:/home/Xilinx/2018/Vivado/2018.2/lib/lnx64.o/Default/libstdc++.so.6':
> No such file or directory
> Error evaluating 'PreLoadFcn' callback of block_diagram 'xbsIndex_r4'.
> Callback string is
> 'warning('off','MATLAB:mex:deprecatedExtension');xlSysGenPreLoadCheck;xlmeta;evalin('base','xilinx.environment.loadAllStrategies();');'
> [2 similar]
> Caused by:
> Invalid MEX-file
> '/home/Xilinx/2018/Vivado/2018.2/lib/lnx64.o/matlab/xlmeta.mexa64':
> **
>
> and a lot of "Missing Symbols ", It's probably because of the version
> mismatch.
>
> Next, I installed Matlab 2018a and the issues mentioned above were solved,
> however a very interesting issue raised up. When I tried simulating a
> simple design, I got the following error for SNAP board:
>
> **
> Part on the System Generator Token in your design is set to Kintex7
> xc7k160t-2ffg676. This part is not found in your Vivado installation.
> Please modify the System Generator Token to a part that is currently
> installed or update Vivado by installing this part.
> **
>
> I also tried running the simulation for VCU118. The device was changed to
> "xcvu9p-2L-e-eslflga2104" and I got the same error message.
>
> I doubled check the installed devices by running the Vivado installer and
> it seems all devices are installed:
>
> [image: VivadoInstallation.PNG]
> Vivado and Matlab work standalone without issues. I get the aforementioned
> error when I try to simulate a design in Simulink.
>
> I'm using CentOS 6.10. In Vivado Release Notes, It doesn't mention a
> support for this version of CentOS:
> [image: VivadoInstallation2.PNG]
> However, since Vivado works independently, I assume there shouldn't be an
> issue with CentOS version.
>
> I would be grateful if you could share your opinion and possible debugging
> methods.
>
> --
> Arash Roshanineshat
> Department of Electrical & Computer Engineering
> Department of Astronomy
> Steward Observatory
> University of Arizona
>
> --
> 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] New Wideband Spectrometer Designs
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 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. > > > -- > 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 t
[casper] position for digital expert for ALMA development in Mitaka
Hi all: There is job opportunity in Japan. https://www.nao.ac.jp/en/contents/job-vacancy/job-20180702-chile-en.pdf 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.
Re: [casper] packets lost of a packetized correlator
Dear Danny and John: Thanks of your suggestion. I checked the ARP table as below, the unused ones are all "FF FF ...". Did you suggest assign all the ARP table with different address ? best homin ARP Table: IP: 10. 0. 0. 0: MAC: FF FF FF FF FF FF IP: 10. 0. 0. 1: MAC: FF FF FF FF FF FF ... IP: 10. 0. 0. 19: MAC: FF FF FF FF FF FF IP: 10. 0. 0. 20: MAC: 00 60 DD 44 9D 38 IP: 10. 0. 0. 21: MAC: FF FF FF FF FF FF ... IP: 10. 0. 0.126: MAC: FF FF FF FF FF FF IP: 10. 0. 0.127: MAC: FF FF FF FF FF FF IP: 10. 0. 0.128: MAC: 02 02 0A 00 00 80 IP: 10. 0. 0.129: MAC: 02 02 0A 00 00 81 IP: 10. 0. 0.130: MAC: 02 02 0A 00 00 82 IP: 10. 0. 0.131: MAC: 02 02 0A 00 00 83 IP: 10. 0. 0.132: MAC: 02 02 0A 00 00 84 IP: 10. 0. 0.133: MAC: 02 02 0A 00 00 85 IP: 10. 0. 0.134: MAC: 02 02 0A 00 00 86 IP: 10. 0. 0.135: MAC: 02 02 0A 00 00 87 IP: 10. 0. 0.136: MAC: 02 02 0A 00 00 88 IP: 10. 0. 0.137: MAC: 02 02 0A 00 00 89 IP: 10. 0. 0.138: MAC: 02 02 0A 00 00 8A IP: 10. 0. 0.139: MAC: 02 02 0A 00 00 8B IP: 10. 0. 0.140: MAC: 02 02 0A 00 00 8C IP: 10. 0. 0.141: MAC: FF FF FF FF FF FF IP: 10. 0. 0.142: MAC: 02 02 0A 00 00 8E IP: 10. 0. 0.143: MAC: 02 02 0A 00 00 8F IP: 10. 0. 0.144: MAC: 02 02 0A 00 00 90 IP: 10. 0. 0.145: MAC: 02 02 0A 00 00 91 IP: 10. 0. 0.146: MAC: 02 02 0A 00 00 92 IP: 10. 0. 0.147: MAC: 02 02 0A 00 00 93 IP: 10. 0. 0.148: MAC: 02 02 0A 00 00 94 IP: 10. 0. 0.149: MAC: 02 02 0A 00 00 95 IP: 10. 0. 0.150: MAC: 02 02 0A 00 00 96 IP: 10. 0. 0.151: MAC: 02 02 0A 00 00 97 IP: 10. 0. 0.152: MAC: 02 02 0A 00 00 98 IP: 10. 0. 0.153: MAC: 02 02 0A 00 00 99 IP: 10. 0. 0.154: MAC: 02 02 0A 00 00 9A IP: 10. 0. 0.155: MAC: 02 02 0A 00 00 9B IP: 10. 0. 0.156: MAC: 02 02 0A 00 00 9C IP: 10. 0. 0.157: MAC: 02 02 0A 00 00 9D IP: 10. 0. 0.158: MAC: 02 02 0A 00 00 9E IP: 10. 0. 0.159: MAC: 02 02 0A 00 00 9F IP: 10. 0. 0.160: MAC: FF FF FF FF FF FF ... IP: 10. 0. 0.255: MAC: FF FF FF FF FF FF On Wed, Mar 14, 2018 at 7:21 AM, John Ford <jmfor...@gmail.com> wrote: > 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 <dav...@berkeley.edu> > 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 <ho...@asiaa.sinica.edu.tw> 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 <dav...@berkeley.edu> >> 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 yo
Re: [casper] packets lost of a packetized correlator
Dear Danny and John: Thanks of your suggestion. I checked the ARP table as below, they are all "FF FF ... FF" for unused X engine ports except the one with IP =10.0.0.141. The F engine is all "FF FF". Did you suggest that assign different numbers to all the IP including the unused ones ? best homin ARP Table: IP: 10. 0. 0. 0: MAC: FF FF FF FF FF FF IP: 10. 0. 0. 1: MAC: FF FF FF FF FF FF ... IP: 10. 0. 0. 19: MAC: FF FF FF FF FF FF IP: 10. 0. 0. 20: MAC: 00 60 DD 44 9D 38 IP: 10. 0. 0. 21: MAC: FF FF FF FF FF FF ... IP: 10. 0. 0.126: MAC: FF FF FF FF FF FF IP: 10. 0. 0.127: MAC: FF FF FF FF FF FF IP: 10. 0. 0.128: MAC: 02 02 0A 00 00 80 IP: 10. 0. 0.129: MAC: 02 02 0A 00 00 81 IP: 10. 0. 0.130: MAC: 02 02 0A 00 00 82 IP: 10. 0. 0.131: MAC: 02 02 0A 00 00 83 IP: 10. 0. 0.132: MAC: 02 02 0A 00 00 84 IP: 10. 0. 0.133: MAC: 02 02 0A 00 00 85 IP: 10. 0. 0.134: MAC: 02 02 0A 00 00 86 IP: 10. 0. 0.135: MAC: 02 02 0A 00 00 87 IP: 10. 0. 0.136: MAC: 02 02 0A 00 00 88 IP: 10. 0. 0.137: MAC: 02 02 0A 00 00 89 IP: 10. 0. 0.138: MAC: 02 02 0A 00 00 8A IP: 10. 0. 0.139: MAC: 02 02 0A 00 00 8B IP: 10. 0. 0.140: MAC: 02 02 0A 00 00 8C IP: 10. 0. 0.141: MAC: FF FF FF FF FF FF IP: 10. 0. 0.142: MAC: 02 02 0A 00 00 8E IP: 10. 0. 0.143: MAC: 02 02 0A 00 00 8F IP: 10. 0. 0.144: MAC: 02 02 0A 00 00 90 IP: 10. 0. 0.145: MAC: 02 02 0A 00 00 91 IP: 10. 0. 0.146: MAC: 02 02 0A 00 00 92 IP: 10. 0. 0.147: MAC: 02 02 0A 00 00 93 IP: 10. 0. 0.148: MAC: 02 02 0A 00 00 94 IP: 10. 0. 0.149: MAC: 02 02 0A 00 00 95 IP: 10. 0. 0.150: MAC: 02 02 0A 00 00 96 IP: 10. 0. 0.151: MAC: 02 02 0A 00 00 97 IP: 10. 0. 0.152: MAC: 02 02 0A 00 00 98 IP: 10. 0. 0.153: MAC: 02 02 0A 00 00 99 IP: 10. 0. 0.154: MAC: 02 02 0A 00 00 9A IP: 10. 0. 0.155: MAC: 02 02 0A 00 00 9B IP: 10. 0. 0.156: MAC: 02 02 0A 00 00 9C IP: 10. 0. 0.157: MAC: 02 02 0A 00 00 9D IP: 10. 0. 0.158: MAC: 02 02 0A 00 00 9E IP: 10. 0. 0.159: MAC: 02 02 0A 00 00 9F IP: 10. 0. 0.160: MAC: FF FF FF FF FF FF ... IP: 10. 0. 0.255: MAC: FF FF FF FF FF FF On Wed, Mar 14, 2018 at 7:21 AM, John Ford <jmfor...@gmail.com> wrote: > 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 <dav...@berkeley.edu> > 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 <ho...@asiaa.sinica.edu.tw> 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 <dav...@berkeley.edu> >> 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 i
Re: [casper] packets lost of a packetized correlator
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 <dav...@berkeley.edu> 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 <ho...@asiaa.sinica.edu.tw> 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.
[casper] packets lost of a packetized correlator
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.
Re: [casper] Writing calibrated data to QDR of ROACH2
Thanks, Jack. I have done it by myself. I grabbed the derived the parameters, then use "qdr_apply" in "qdr.py" to write those parameters back to ROACH2s every times after power cycled. It works fine, best homin On Tue, Jan 30, 2018 at 4:33 AM, Jack Hickish <jackhick...@gmail.com> wrote: > Hi Homin, > > No-one replied to this, so i'll bite. > In principle you could do this, but there is no canned way to > obtain/save/reload the calibrations. They are implemented by stepping some > MMCMs (rather than a register containing fixed offsets) so you'd have to > count the steps during calibration, and then save these somewhere ready to > be reloaded after reprogramming. > > Cheers > Jack > > On Sun, 21 Jan 2018 at 17:34 Homin Jiang <ho...@asiaa.sinica.edu.tw> > wrote: > >> Dear Folks: >> >> This might be a trivial question. >> Is there a way to write the QDR calibrated data to ROACH2 ? It will save >> time if we don't have to do it every time. >> >> 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.
[casper] Writing calibrated data to QDR of ROACH2
Dear Folks: This might be a trivial question. Is there a way to write the QDR calibrated data to ROACH2 ? It will save time if we don't have to do it every time. 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.
[casper] EMI test data of ROACH2
Hello: Did anyone carry out the EMI measurement for ROACH-2 ? Highly appreciate of sharing the information. regards homin jiang
[casper] 32 parallel input to fft_wideband_real
Dear all: I have trouble in the output order of the fft_wideband_real which i fed 32 parallel inputs. I marked the "unscramble output". The output sequence seems not in order as the 8 or 16 parallel inputs fft does. Has anyone tried the 32 input to the fft block ? Comments are highly appreciate. regards homin
Re: [casper] 32 parallel inputs to fft_wideband_real
Hi Jack: I tried 128, 512, 1024, 2048 channels. When the input is 32, the fft block generates 4 stages of butterfly, it fails in generation of coeff_gen which is inside the 4th stage of butterfly. There is no line connections inside the coeff_gen blocks. regards homin On Tue, Jan 12, 2016 at 12:38 AM, Jack Hickish <jackhick...@gmail.com> wrote: > Hi Homin, > > What total size of FFT are you trying to do? How does the FFT fail? > > Cheers, > Jack > > On Mon, 11 Jan 2016 at 00:35 Homin Jiang <ho...@asiaa.sinica.edu.tw> > wrote: > >> Hello: >> >> Does anyone have the experience of the 32 simultaneous inputs to the >> fft_wideband_real ? I have tried that for couple of days without any luck. >> >> Best regards >> homin jiang >> >> >> >
[casper] QDR control of V14.7
Hello: Recently I upgraded my toolflow from V14.4 to V14.7. In V14.4, the QDR can work properly without any control from Python. In V14.7, the QDR didn't work that way, so i want to make sure that is there any activation command by Python code ? regards homin jiang
[casper] constraints for qdr2/ROACH2
Dear All: Recently i found out the locations I/O pins for qdr2/ROACH2 are not in the same FPGA area.(from the Planahead/device map). Some of them are in the left edge of the device, and some of them are in the middle of the device. Is there someone experienced this problem and have constraints in hand to share with ? regards homin jiang
Re: [casper] software register
Hi Jack: I followed your instruction, but i didn't have good luck. I am using latest version of mlib_devel library from ska-sa, and i guess the latest software register block has something wrong. There is a software register_OLD in the library, is there a command i can replace the software register by software register_OLD ? regards homin On Fri, Nov 7, 2014 at 7:03 PM, Jack Hickish jackhick...@gmail.com wrote: Hi Homin, As Wes says, there's a good chance you need to replace your sw registers with new versions from the library. For sanity, you can do this automatically from the matlab prompt with the command (open your model first so bdroot points to it): update_casper_blocks(bdroot, 'Tag', 'xps:sw_reg') You can update *all* casper blocks with: update_casper_blocks(bdroot) Cheers, Jack On Fri Nov 07 2014 at 08:30:09 Wesley New wes...@ska.ac.za wrote: Can you elaborate on these errors? A while ago the software registers were updated so you might have to replace all of the software registers in you your design with the new on from the library. Wesley New South African SKA Project +2721 506 7365 www.ska.ac.za On Fri, Nov 7, 2014 at 3:55 AM, Homin Jiang ho...@asiaa.sinica.edu.tw wrote: Hello: I am upgrading my system to xilinx 14.7 with Matlab 2012a and up to date mlib_devel library. I encountered errors by the software register in XPS library. Any one can help ? thanks homin
[casper] software register
Hello: I am upgrading my system to xilinx 14.7 with Matlab 2012a and up to date mlib_devel library. I encountered errors by the software register in XPS library. Any one can help ? thanks homin
Re: [casper] casper Digest, Vol 65, Issue 38
Hi Haoxuan: There is a bug in Planahead V14. It works fine with the ngc files generated by the version older than 14. If the ngc files are generated by V14 itself, the planahead won't work. I opened a xilinx webcase CASE:966795, but no answer so far. cheers homin On Wed, May 1, 2013 at 3:14 AM, casper-requ...@lists.berkeley.edu wrote: Send casper mailing list submissions to casper@lists.berkeley.edu To subscribe or unsubscribe via the World Wide Web, visit https://calmail.berkeley.edu/manage/list/listinfo/casper@lists.berkeley.edu or, via email, send a message with subject or body 'help' to casper-requ...@lists.berkeley.edu You can reach the person managing the list at casper-ow...@lists.berkeley.edu When replying, please edit your Subject line so it is more specific than Re: Contents of casper digest... Today's Topics: 1. PlanAhead 14.2 help (Haoxuan Zheng) 2. More Tutorial 3 problems (Jason Castro) -- Message: 1 Date: Tue, 30 Apr 2013 15:53:25 + From: Haoxuan Zheng jef...@mit.edu Subject: [casper] PlanAhead 14.2 help To: casper@lists.berkeley.edu casper@lists.berkeley.edu Message-ID: f5a6a735282c114199cd5f617dc370b46ac03...@oc11expo33.exchange.mit.edu Content-Type: text/plain; charset=iso-8859-1 Hi CASPER, We would like to use PlanAhead to help achieve timing closure in our latest design where the failed route has 80% routing time. However the PlanAhead software we have is version 14.2, which looks significantly different from the example on CASPERwiki, https://casper.berkeley.edu/wiki/Speed_Optimization_with_PlanAhead. I imported all the files generated from the failed casper_xps into PlanAhead without issues, but I can't follow the first step in Manually floorplan the design since I don't see a more button in Ctrl-F dialogue. Does anyone has experience with PlanAhead 14.2 and would be so kind to offer some help? Thank you so much! Jeff -- next part -- An HTML attachment scrubbed and removed. HTML attachments are only available in MIME digests. -- Message: 2 Date: Tue, 30 Apr 2013 13:15:03 -0400 From: Jason Castro jcas...@nrao.edu Subject: [casper] More Tutorial 3 problems To: casper@lists.berkeley.edu Message-ID: 517ffc17.8010...@nrao.edu Content-Type: text/plain; charset=ISO-8859-1; format=flowed I recently upgraded my CASPER tools to the latest and greatest versions (Xilinx 14.4 and Matlab 2012b) as well as the latest SKA-SA mlib_devel libraries. As a sanity check I downloaded and recompiled tutorial 3 from here: https://github.com/casper-astro/tutorials_devel/blob/master/tut3/tut3.slx I had to replace the even and odd BRAM blocks, but other than that it appeared to compile just fine. However when I run the bof file I read all zeros back from the even and odd registers. If I keep everything else constant and just change the mlib_devel library to this branch (http://astro.berkeley.edu/~davidm/mlib_devel.git/) I get a reasonable spectrum out but with a peak that corresponds to the FPGA clock frequency. If I use the precompiled bof file here (https://github.com/casper-astro/tutorials_devel/blob/master/tut3/tut3.bof ) the FPGA clock frequency peak disappears. Can I get some assistance here? First off, it appears that the lastest ska_sa libraries aren't compatible with the latest tutorial3 files. Second does anyone know why I'd have clock frequency peaks from one compile to the next? Thanks, Jason Castro NRAO End of casper Digest, Vol 65, Issue 38 **
Re: [casper] casper Digest, Vol 65, Issue 38
Hi : I should make my statement more precise. I have problems on Planahead V14.3 and V14.4. Couple of groups said that the V14.2 works fine. regards homin On Wed, May 1, 2013 at 3:14 AM, casper-requ...@lists.berkeley.edu wrote: Send casper mailing list submissions to casper@lists.berkeley.edu To subscribe or unsubscribe via the World Wide Web, visit https://calmail.berkeley.edu/manage/list/listinfo/casper@lists.berkeley.edu or, via email, send a message with subject or body 'help' to casper-requ...@lists.berkeley.edu You can reach the person managing the list at casper-ow...@lists.berkeley.edu When replying, please edit your Subject line so it is more specific than Re: Contents of casper digest... Today's Topics: 1. PlanAhead 14.2 help (Haoxuan Zheng) 2. More Tutorial 3 problems (Jason Castro) -- Message: 1 Date: Tue, 30 Apr 2013 15:53:25 + From: Haoxuan Zheng jef...@mit.edu Subject: [casper] PlanAhead 14.2 help To: casper@lists.berkeley.edu casper@lists.berkeley.edu Message-ID: f5a6a735282c114199cd5f617dc370b46ac03...@oc11expo33.exchange.mit.edu Content-Type: text/plain; charset=iso-8859-1 Hi CASPER, We would like to use PlanAhead to help achieve timing closure in our latest design where the failed route has 80% routing time. However the PlanAhead software we have is version 14.2, which looks significantly different from the example on CASPERwiki, https://casper.berkeley.edu/wiki/Speed_Optimization_with_PlanAhead. I imported all the files generated from the failed casper_xps into PlanAhead without issues, but I can't follow the first step in Manually floorplan the design since I don't see a more button in Ctrl-F dialogue. Does anyone has experience with PlanAhead 14.2 and would be so kind to offer some help? Thank you so much! Jeff -- next part -- An HTML attachment scrubbed and removed. HTML attachments are only available in MIME digests. -- Message: 2 Date: Tue, 30 Apr 2013 13:15:03 -0400 From: Jason Castro jcas...@nrao.edu Subject: [casper] More Tutorial 3 problems To: casper@lists.berkeley.edu Message-ID: 517ffc17.8010...@nrao.edu Content-Type: text/plain; charset=ISO-8859-1; format=flowed I recently upgraded my CASPER tools to the latest and greatest versions (Xilinx 14.4 and Matlab 2012b) as well as the latest SKA-SA mlib_devel libraries. As a sanity check I downloaded and recompiled tutorial 3 from here: https://github.com/casper-astro/tutorials_devel/blob/master/tut3/tut3.slx I had to replace the even and odd BRAM blocks, but other than that it appeared to compile just fine. However when I run the bof file I read all zeros back from the even and odd registers. If I keep everything else constant and just change the mlib_devel library to this branch (http://astro.berkeley.edu/~davidm/mlib_devel.git/) I get a reasonable spectrum out but with a peak that corresponds to the FPGA clock frequency. If I use the precompiled bof file here (https://github.com/casper-astro/tutorials_devel/blob/master/tut3/tut3.bof ) the FPGA clock frequency peak disappears. Can I get some assistance here? First off, it appears that the lastest ska_sa libraries aren't compatible with the latest tutorial3 files. Second does anyone know why I'd have clock frequency peaks from one compile to the next? Thanks, Jason Castro NRAO End of casper Digest, Vol 65, Issue 38 **
Re: [casper] No ADC clock signal in ROACH2 Rev. 2
Hi Jonathan and all:
Thanks of inform me the bug that is the exact fault caused the malfunction.
We just had a good luck while running Rev 1, turned out we didn't pay
attention to it.
So, please check the R104 and R105 if you are using the 5G adc.
cheers
homin
On Fri, Apr 19, 2013 at 11:02 AM, Jonathan Weintroub
jweintr...@cfa.harvard.edu wrote:
Hi Homin,
One other thing to check is the resistor locations R104 and R105.
--R104 should be unpopulated.
--R105 should be populated with 0 ohm.
When checking this note that the silkscreen markings are quite ambiguous.
So identify R104 explicitly by noting that one side of it goes to pin 7 of
U2 etc.
In an early build of the ADCs we had similar trouble due to these two
sites being mixed up by the assembler.
If R105 is indeed missing, the needed reset does not get to the input of
buffer U3 even if you are using the correct bitcode which provides that
reset.
Jonathan
On Apr 18, 2013, at 10:27 PM, Homin Jiang wrote:
Dear Rurik:
I downloaded the library from github/ska-sa at Jan 21,2013.
Could you specify where is the floating reset line ? that might give me
some hints.
Dear Mark and Glenn:
Could you share me what you have done ? That might save me couple of
days.
cheers
homin
On Thu, Apr 18, 2013 at 11:09 PM, Rurik A Primiani
rprim...@cfa.harvard.edu wrote:
Hi Homin,
What version of the yellow block are you using?
We had an issue with the clock not coming through due to a floating
reset line that was not being driven. This was fixed a while ago on
sma-wideband/mlib_devel and I believe has also been merged into the main
casper-astro repository.
Thanks,
Rurik
On 4/18/2013 10:49 AM, John Ford wrote:
Hi
Thanks of prompt response
I have compared the schematics of both versions . The clock pins are kept
the same.
I compiled the bof files using the rev 2 ucf file.
Hi Homin.
We are successfully using the ASIAA 5 GS/s ADC and Rev 2 roach together
using the ADC clock input. Maybe Glenn Jones or Mark Wagner can comment
on the yellow blocks we're using.
John
Homin
Henno Kriel 於 2013年4月18日星期四寫道：
Hi Homin
There was a change to the routing from the ZDOK pins to the FPGA from
rev1
to rev2.
Are you still running a design that was compiled for rev1?
Regards
Henno
On Thu, Apr 18, 2013 at 2:22 PM, Homin Jiang
ho...@asiaa.sinica.edu.twjavascript:_e({}, 'cvml',
'ho...@asiaa.sinica.edu.tw');
wrote:
Hello:
After couple of tests, we found that the ADC clock signal is not able
enter to the ROACH2 Rev 2. We physically measure the clock pin on ZDOK
(F19,F20) of one 5G adc board which was plugged into Rev 1 and then Rev
2.
In the Rev 1, there is clock signal, but no signal in the Rev 2.
4 of ROACH2 Rev. 2 have been tested by 10G ethernet bof file which used
the system clock. The Rev 2 boards are working well in that case. The
only
difference i know is the Rev 1 is under tcpborphserver 2 , and the Rev
2 is
under tcpborphserver 3. Is there IO bank control in the tcpborphserver
3 ?
regards
homin jiang
--
Henno Kriel
DSP Engineer
Digital Back End
meerKAT
SKA South Africa
Third Floor
The Park
Park Road (off Alexandra Road)
Pinelands
7405
Western Cape
South Africa
Latitude: -33.94329 (South); Longitude: 18.48945 (East).
(p) +27 (0)21 506 7300
(p) +27 (0)21 506 7365 (direct)
(f) +27 (0)21 506 7375
(m) +27 (0)84 504 5050
[casper] No ADC clock signal in ROACH2 Rev. 2
Hello: After couple of tests, we found that the ADC clock signal is not able enter to the ROACH2 Rev 2. We physically measure the clock pin on ZDOK (F19,F20) of one 5G adc board which was plugged into Rev 1 and then Rev 2. In the Rev 1, there is clock signal, but no signal in the Rev 2. 4 of ROACH2 Rev. 2 have been tested by 10G ethernet bof file which used the system clock. The Rev 2 boards are working well in that case. The only difference i know is the Rev 1 is under tcpborphserver 2 , and the Rev 2 is under tcpborphserver 3. Is there IO bank control in the tcpborphserver 3 ? regards homin jiang
Re: [casper] No ADC clock signal in ROACH2 Rev. 2
Hi
Thanks of prompt response
I have compared the schematics of both versions . The clock pins are kept
the same.
I compiled the bof files using the rev 2 ucf file.
Homin
Henno Kriel 於 2013年4月18日星期四寫道：
Hi Homin
There was a change to the routing from the ZDOK pins to the FPGA from rev1
to rev2.
Are you still running a design that was compiled for rev1?
Regards
Henno
On Thu, Apr 18, 2013 at 2:22 PM, Homin Jiang
ho...@asiaa.sinica.edu.twjavascript:_e({}, 'cvml',
'ho...@asiaa.sinica.edu.tw');
wrote:
Hello:
After couple of tests, we found that the ADC clock signal is not able
enter to the ROACH2 Rev 2. We physically measure the clock pin on ZDOK
(F19,F20) of one 5G adc board which was plugged into Rev 1 and then Rev 2.
In the Rev 1, there is clock signal, but no signal in the Rev 2.
4 of ROACH2 Rev. 2 have been tested by 10G ethernet bof file which used
the system clock. The Rev 2 boards are working well in that case. The only
difference i know is the Rev 1 is under tcpborphserver 2 , and the Rev 2 is
under tcpborphserver 3. Is there IO bank control in the tcpborphserver 3 ?
regards
homin jiang
--
Henno Kriel
DSP Engineer
Digital Back End
meerKAT
SKA South Africa
Third Floor
The Park
Park Road (off Alexandra Road)
Pinelands
7405
Western Cape
South Africa
Latitude: -33.94329 (South); Longitude: 18.48945 (East).
(p) +27 (0)21 506 7300
(p) +27 (0)21 506 7365 (direct)
(f) +27 (0)21 506 7375
(m) +27 (0)84 504 5050
Re: [casper] No ADC clock signal in ROACH2 Rev. 2
Dear Rurik:
I downloaded the library from github/ska-sa at Jan 21,2013.
Could you specify where is the floating reset line ? that might give me
some hints.
Dear Mark and Glenn:
Could you share me what you have done ? That might save me couple of days.
cheers
homin
On Thu, Apr 18, 2013 at 11:09 PM, Rurik A Primiani rprim...@cfa.harvard.edu
wrote:
Hi Homin,
What version of the yellow block are you using?
We had an issue with the clock not coming through due to a floating reset
line that was not being driven. This was fixed a while ago on
sma-wideband/mlib_devel and I believe has also been merged into the main
casper-astro repository.
Thanks,
Rurik
On 4/18/2013 10:49 AM, John Ford wrote:
Hi
Thanks of prompt response
I have compared the schematics of both versions . The clock pins are kept
the same.
I compiled the bof files using the rev 2 ucf file.
Hi Homin.
We are successfully using the ASIAA 5 GS/s ADC and Rev 2 roach together
using the ADC clock input. Maybe Glenn Jones or Mark Wagner can comment
on the yellow blocks we're using.
John
Homin
Henno Kriel 於 2013年4月18日星期四寫道：
Hi Homin
There was a change to the routing from the ZDOK pins to the FPGA from
rev1
to rev2.
Are you still running a design that was compiled for rev1?
Regards
Henno
On Thu, Apr 18, 2013 at 2:22 PM, Homin Jiang
ho...@asiaa.sinica.edu.tw**javascript:_e({}, 'cvml',
'ho...@asiaa.sinica.edu.tw');
wrote:
Hello:
After couple of tests, we found that the ADC clock signal is not able
enter to the ROACH2 Rev 2. We physically measure the clock pin on ZDOK
(F19,F20) of one 5G adc board which was plugged into Rev 1 and then Rev
2.
In the Rev 1, there is clock signal, but no signal in the Rev 2.
4 of ROACH2 Rev. 2 have been tested by 10G ethernet bof file which used
the system clock. The Rev 2 boards are working well in that case. The
only
difference i know is the Rev 1 is under tcpborphserver 2 , and the Rev
2 is
under tcpborphserver 3. Is there IO bank control in the tcpborphserver
3 ?
regards
homin jiang
--
Henno Kriel
DSP Engineer
Digital Back End
meerKAT
SKA South Africa
Third Floor
The Park
Park Road (off Alexandra Road)
Pinelands
7405
Western Cape
South Africa
Latitude: -33.94329 (South); Longitude: 18.48945 (East).
(p) +27 (0)21 506 7300
(p) +27 (0)21 506 7365 (direct)
(f) +27 (0)21 506 7375
(m) +27 (0)84 504 5050
[casper] ADC 1x5000-8 1:2 boards
Dear Ross: I will check our inventory. I guess we still have some. I am interested to know why not 1:1 ? cheers homin
[casper] 16 ports of ADC
Dear all: I am developing the 5G adc board. I am feeding 16 ports with 4 bits from ADC block to PFB and FFT after finished the test of 8 ports with 8 bits. In my previous test of 8 ports with 8 bits, i have compiled the 2K channels , 8 taps model successfully under normal Windows without 3GB options. At this moment, i am forced to switch on the option of 3GB , also i have to reduce the channel size to 1K, otherwise the Virtex 5 will explode. Are there anyway to make the PFB and FFT more efficient to accommodate the 16 ports input ? My thinking is 16x4 should be equal to 8x8,right ? cheers homin jiang
Re: [casper] F engine for Packetized correlator
Hi Jason: Thanks of your suggestion. If you're just wanting to play around with it, the easiest might be to just directly replace the QuADCs in the rev306 design with iADCs from the library, but only use 1/4 of the time-series outputs on each ADC (effectively reducing your sample rate by 4). Then tie the extra PFB unused inputs to constant zeros. I've attached an untested model file where i've done this for you, but I haven't tested it and don't even know if it'll compile. I have modified the rev. 306 to what quite close as your suggestion. compiled OK. We will give a try to have a sense of packetized correlator. -- Regards, Homin Jiang(¦¿§»©ú)
Re: [casper] casper Digest, Vol 25, Issue 16
Hi Jason: I compiled the 322g couple of times with different system clock rate,210MHz, 205Mhz and 200MHz. unfortunately, all failed at timing contraint. Is there anywhere the timing constraint can be relaxed ? the errors as : 210MHz: - -- Constraint| Check | Worst Case | Best Case | Timing | Timing | |Slack | Achievable | Errors |Score -- * NET epb_cs_n_IBUF MAXDELAY = 4 ns | MAXDELAY|-0.750ns| 4.750ns| 1| 750 -- * TS_clk_8623c679 = PERIOD TIMEGRP clk_862 | SETUP |-0.426ns| 5.187ns| 31|2977 3c679 4.7619 ns HIGH 50% | HOLD| 0.236ns| | 0| 0 -- TS_mgt_clk_1 = PERIOD TIMEGRP mgt_clk_1 | SETUP | 0.025ns| 6.375ns| 0| 0 156.25 MHz HIGH 50% | HOLD| 0.101ns| | 0| 0 -- 205MHz and 200MHz: ... * NET epb_cs_n_IBUF MAXDELAY = 4 ns | MAXDELAY|-0.750ns| 4.750ns| 1| 750 ... cheers homin jiang Jason Manley wrote: I have just checked-in the latest versions. F engine is at revision 306 (stable) for ibobs and X engine is up to rev 322g (debug compile) for roach. There are two major outstanding issues before the system is deployable: 1) Loss of packets from F engines. There is a loss of data (about 1 in 4 million packets) in the 10GbE network. I am trying to debug this at the moment, and the problem appears to be in the 10GbE RX core, but this is as yet unconfirmed. There should be zero data loss in a correctly functioning system. 2) Output not thoroughly checked. I do not yet have working receive code to capture and plot the correlator output packets and so have not confirmed correct end-to-end instrument operation. Minor issues which I hope to correct by Feb 2010: * SPEAD metadata not yet issued. The python code that controls the system will eventually output SPEAD compliant metadata describing the data stream, including instructions on how the receiver should interpret the data. See http://github.com/sratcliffe/PySPEAD for further info. * Some cleanup is required. I want to mux the output data over the existing 10GbE link rather than use a separate 10GbE core. Various blocks can use some optimisation too. If you want to start playing with the design, please ensure that you're running the latest tcpborphserver2 on your ROACHes (http://casper.berkeley.edu/svn/trunk/roach/sw/binaries/tcpborphserver/) because there were fixes to the tgtap call. Jason On 22 Dec 2009, at 10:49, Homin Jiang wrote: Hi Jason: Are there stable model files for packetized correlator on ROACH ? I saw there are 2 model files in the /roach subdirectory, but with comments of lots of stuff here for debug . cheers homin jiang Today's Topics: 1. roach reference designs (Jason Manley) -- Message: 1 Date: Mon, 21 Dec 2009 09:13:15 +0200 From: Jason Manley jasonman...@gmail.com Subject: [casper] roach reference designs To: casper@lists.berkeley.edu, casper-correla...@lists.berkeley.edu Message-ID: 2abda70f-7b3d-4d2d-90cf-fdc18e662...@gmail.com Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Hi all It came to my attention that not many people know about the ROACH reference designs from the last CASPER workshop. The reference designs can be found in SVN here: http://casper.berkeley.edu/svn/trunk/ref_designs_tutorials/ and provide a great way to get started with CASPER and ROACH. The tutorials at the 2009 CASPER workshop are as follows: 1) Introduction === Introduction to Simulink, communication with FPGAs. Build a simple program that flashes LEDs, counts and adds numbers on demand, captures raw ADC data. Communicate with ROACH's FPGA using the PPC's BORPH operating system and also using raw KATCP commands. Includes step-by- step walkthrough for building your design, compiling it, loading onto ROACH and communicating with it. Prerequisites: just your enthusiastic self, your computer with 10.1 libraries and a ROACH board. * PDF walkthrough: http://casper.berkeley.edu/svn/trunk/ref_designs_tutorials
Re: [casper] casper Digest, Vol 25, Issue 16
Hi Jason: Are there stable model files for packetized correlator on ROACH ? I saw there are 2 model files in the /roach subdirectory, but with comments of lots of stuff here for debug . cheers homin jiang Today's Topics: 1. roach reference designs (Jason Manley) -- Message: 1 Date: Mon, 21 Dec 2009 09:13:15 +0200 From: Jason Manley jasonman...@gmail.com Subject: [casper] roach reference designs To: casper@lists.berkeley.edu, casper-correla...@lists.berkeley.edu Message-ID: 2abda70f-7b3d-4d2d-90cf-fdc18e662...@gmail.com Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Hi all It came to my attention that not many people know about the ROACH reference designs from the last CASPER workshop. The reference designs can be found in SVN here: http://casper.berkeley.edu/svn/trunk/ref_designs_tutorials/ and provide a great way to get started with CASPER and ROACH. The tutorials at the 2009 CASPER workshop are as follows: 1) Introduction === Introduction to Simulink, communication with FPGAs. Build a simple program that flashes LEDs, counts and adds numbers on demand, captures raw ADC data. Communicate with ROACH's FPGA using the PPC's BORPH operating system and also using raw KATCP commands. Includes step-by- step walkthrough for building your design, compiling it, loading onto ROACH and communicating with it. Prerequisites: just your enthusiastic self, your computer with 10.1 libraries and a ROACH board. * PDF walkthrough: http://casper.berkeley.edu/svn/trunk/ref_designs_tutorials/workshop_2009/roach_tut1_intro/tut1_intro.pdf * Completed Simulink model file: http://casper.berkeley.edu/svn/trunk/ref_designs_tutorials/workshop_2009/roach_tut1_intro/tut1.mdl 2) 10GbE, KATCP === Construct a design that transmits a counter over 10GbE to another ROACH port. During this tutorial, you will learn more about the CASPER hardware interfaces, communicating with ROACH remotely using KATCP and the supplied Python libraries. Prerequisites: Introduction tutorial (we expect conceptual understanding of software registers and PPC/FPGA mapped memory regions along with some basic Simulink experience). Also useful, but not required, is some experience in programming in Python, since sample scripts for configuring and controlling the system are provided. You will need a ROACH board and a 10GbE cable. Please also ensure that you're running the latest versions of tcpborphserver and tgtap on your ROACH, else the 10GbE may not function correctly. Get 'em here: http://casper.berkeley.edu/svn/trunk/roach/sw/binaries/ * PDF walkthrough: http://casper.berkeley.edu/svn/trunk/ref_designs_tutorials/workshop_2009/roach_tut2_10GbE/tut2_10gbe.pdf * Simulink model file: http://casper.berkeley.edu/svn/trunk/ref_designs_tutorials/workshop_2009/roach_tut2_10GbE/tut2.mdl * Python control script: http://casper.berkeley.edu/svn/trunk/ref_designs_tutorials/workshop_2009/roach_tut2_10GbE/tut2.py 3) Wideband spectrometer Build a 512MHz wideband spectrometer with 2048 FFT channels on ROACH. This will introduce the ADC boards, the CASPER DSP libraries including the wideband PFB and FFT blocks as well as demonstrate the use of vector accumulators, shared BRAMs and readout through the PPC's 1GbE port. We will make use of KATCP for remote control of the ROACHes using Python libraries to plot the output. Prerequisites: tutorials 1 and 2. This design is complete and tested working, but is not documented. You'll need a ROACH board and an iADC board. Revision 102 had a design flaw in the VACC (bit growth), so rev103 adds requantisation after the FFT. Careful of configuring this correctly for your given signal type. See comments in Python code. Or, you can forego to requantisation if you opt for a 64-bit VACC (not demonstrated). * Revision 103, tested working: http://casper.berkeley.edu/svn/trunk/ref_designs_tutorials/workshop_2009/roach_tut3_wideband_spec/r_spec_2048_r103.mdl * Compiled bitstream, ready for execution on ROACH: http://casper.berkeley.edu/svn/trunk/ref_designs_tutorials/workshop_2009/roach_tut3_wideband_spec/r_spec_2048_r103_2009_Nov_23_1234.bof * Python script to configure it: http://casper.berkeley.edu/svn/trunk/ref_designs_tutorials/workshop_2009/roach_tut3_wideband_spec/spectrometer.py 4.1) Wideband pocket correlator === Build a wideband correlator, ported from the original IBOB design for use on ROACH. This is a good starting point for your field-deployable correlator and demonstrates the use of requantisation after the FFT. It is not documented. Code is commented, so you could probably figure it out. You'll need a ROACH board and two iADCs. * Revision 311 Simulink model file using standard CASPER 10.1 libraries: http://casper.berkeley.edu/svn
[casper] /3GB
Hello: I am writing this email just for record. I met the same problem as ZhiWei had in OCt 13,2009 while compiling the tutorial example 4,'poco_wide_10_r311'. http://www.mail-archive.com/casper@lists.berkeley.edu/msg00901.html I followed the suggestion in the emails, put the /3GB option in boot.ini. After rebooting, my Windows desktop didn't function as it was, couple of strange error messages kept popping out and the response is extremely slow. After i removed the /3GB option, it back to normal. So, i am pretty sure the 3GB option made the malfunction of Windows computer. After searching the internet, i put USERVA = with /3GB option. At first attempt, i put /3GB /USERVA = 2500 that means 2.5G user memory. With the USERVA option, the Windows computer functioned well as it should be, but i still got the out of memory error message while compiling the wide band tutorial 4 example, 'poco_wide_10_r311'. I also tried to increase USERVA =3030, the compilation of tut4 still failed by out of memory. Then i put another option of PAE ,Physical Address Extension,as the website below suggested as : /PAE /3GB /USERVA = 3030 The compilation of 'poco_wide_10_r311' passed with computer time of 5:18:42. I compiled it again with computer time of 04:15:30. http://blogs.technet.com/askperf/archive/2007/03/23/memory-management-demystifying-3gb.aspx Cheers homin jiang
Re: [casper] /3GB
My Windows desktop is Dell OptiPlex 755, Intel Q35 Express chipset onboard graphics. regards Jason Manley wrote: The biggest difference between working /3GB option and not working is the memory card and its driver. It depends how much system memory it's mapping. With the /3GB option, you're only leaving 1GB for kernel address space and everything else. We've had to fit PCI-E graphics cards to our Dell machines (which had onboard graphics previously) to get it to work properly. The nvidia cards seem to play nicely with the /3GB option. Jason On 18 Nov 2009, at 03:41, Zhiwei Liu wrote: Hello, For me, I just put the /3GB option in boot.ini. Everything just works fine. Zhiwei On Tue, Nov 17, 2009 at 8:42 PM, Homin Jiang ho...@asiaa.sinica.edu.tw wrote: Hello: I am writing this email just for record. I met the same problem as ZhiWei had in OCt 13,2009 while compiling the tutorial example 4,'poco_wide_10_r311'. http://www.mail-archive.com/casper@lists.berkeley.edu/msg00901.html I followed the suggestion in the emails, put the /3GB option in boot.ini. After rebooting, my Windows desktop didn't function as it was, couple of strange error messages kept popping out and the response is extremely slow. After i removed the /3GB option, it back to normal. So, i am pretty sure the 3GB option made the malfunction of Windows computer. After searching the internet, i put USERVA = with /3GB option. At first attempt, i put /3GB /USERVA = 2500 that means 2.5G user memory. With the USERVA option, the Windows computer functioned well as it should be, but i still got the out of memory error message while compiling the wide band tutorial 4 example, 'poco_wide_10_r311'. I also tried to increase USERVA =3030, the compilation of tut4 still failed by out of memory. Then i put another option of PAE ,Physical Address Extension,as the website below suggested as : /PAE /3GB /USERVA = 3030 The compilation of 'poco_wide_10_r311' passed with computer time of 5:18:42. I compiled it again with computer time of 04:15:30. http://blogs.technet.com/askperf/archive/2007/03/23/memory-management-demystifying-3gb.aspx Cheers homin jiang --Zhiwei Liu -- Regards, Homin Jiang(¦¿§»©ú)
[casper] ROACH pin assignment
Hello:
I opened the file of /xps_library/bee2_hw_routes.mat, it showed only as :
--
led : {4x1 cell}
gpioa : {8x1 cell}
gpiob : {8x1 cell}
diff_gpio : {20x1 cell}
zdok0_p {40x1 cell}
...
gpiob_oe_n: {'AE18'}
Is there anyway to look the detail of each pin assignment ? for example
: i would like to know where it goes of the zdok0_p_18.
cheers
homin
--
Regards,
Homin Jiang(¦¿§»©ú)
Re: [casper] ADC initiate software
Hi David: I have read the VHDL code as you specified in last email. But i still can't find there is parallel to 3-wire serial mechanism in that file. Do i miss something ? cheers homin David George wrote: Hi Homin. The ROACH iADC is 'automatically' set up in gateware, have a look at the casper svn at: mlib_devel_10_1/xps_lib/XPS_ROACH_base/pcores/opb_adccontroller_v1_00_a At the time this was done BORPH wasn't quite ready and a software-free configuration mechanism was required. Currently the configuration could be performed using borph/tcpborphserver client. I don't think a borph iadc driver exists, but it would be a good thing to have. Regards, David -- Regards, Homin Jiang(¦¿§»©ú)
[casper] ADC initiate software
Hi: I am not familiar with ROACH environment so far, anyone can answer my question is highly appreciate. I am searching the C code for ADC initiation , there is a C program called adc.c in iBOB, but i don't know where it is in ROACH environment. Guess should be somewhere under BORPH. Homin Jiang(¦¿§»©ú), ho...@asiaa.sinica.edu.tw http://www.asiaa.sinica.edu.tw/~homin/
[casper] SPI driver
Hello: I am looking for a device driver for SPI which as a spare on the ROACH board. Did anyone try it in the ROACH/Linux environment ? We have made a 5Gsps ADC board with 2 ZODK connectors which bridge the ROACH board. The main ADC chip is from e2V with SPI programming interface, that is why i am looking for the device driver. Anyone has suggestion of SPI programming on ROACH is highly welcome. -- Homin Jiang(¦¿§»©ú), ho...@asiaa.sinica.edu.tw http://www.asiaa.sinica.edu.tw/~homin/ Tel:(02)3365-2200 ext:788 Fax:(02)2367-7849 P.O. Box 23-141, Taipei, Taiwan, 106 Institute of Astronomy and Astrophysics, Academia Sinica (7F of Condensed Matter Sciences and Physics Department Building, National Taiwan University) 1 Roosevelt Rd., Sec. 4, Taipei 106, Taiwan. O¥_¶l¬F 23-141 ¤¤¥¡¬ã¨s°|¤Ñ¤å¤Î¤Ñ¤åª«²z¬ã¨s©ÒÄw³Æ³B (¦ì©ó»OÆW¤j¾Ç¾®ºA¬ì¾Ç»Pª«²z¾ÇÀ]¤C¼Ó) »O¥_¥«106ù´µºÖ¸ô4¬q1¸¹
[casper] USB and done bit not asserted
Hello: Couple of trials here shown that 2 GB USB works well in current configuration. I have tried 4 G, 8 G, both of them didn't work. Key in USB start in UBOOT didn't help. It would be a temporary solution. I tried to run one bof file which was compiled with latest library updated, but i got the same problem as Wan Cheng had in May 14. SelectMap - Done pin has not been asserted. Is there something missed in my Linux setup ? -- Regards, Homin Jiang(¦¿§»©ú)
Re: [casper] USB and done bit not asserted
Hi Alec: Yes, our ROACH is populated with LX110s. I selected that item in the compiler. homin Alec Rust wrote: Hi, we are still looking into the USB issues. Regarding the done pin, what device is your ROACH populated with? It seems some of the boards destined for Taiwan are populated with LX110s and not the SX devices. Regards Alec Homin Jiang wrote: Hello: Couple of trials here shown that 2 GB USB works well in current configuration. I have tried 4 G, 8 G, both of them didn't work. Key in USB start in UBOOT didn't help. It would be a temporary solution. I tried to run one bof file which was compiled with latest library updated, but i got the same problem as Wan Cheng had in May 14. SelectMap - Done pin has not been asserted. Is there something missed in my Linux setup ? -- Regards, Homin Jiang(¦¿§»©ú)
[casper] bug report -- opb_adccontroller_v1_00_a -- user_logic.vhd
Hello: I have first 10.1 bit stream compilation success with ROACH based after comment out 3 lines from line 178 to 180 in the /opb_adccontroller_v1_00_a/hdl/vhdl/user_logic.vhd files. - attribute iob: string; attribute iob of adc0_ddrb_reg : entity is true; --ensure IOB acking to ensure minimum skew attribute iob of adc1_ddrb_reg : entity is true; --- -- I think those 3 lines are added on purpose as the comment said. But it stops the compilation with error of ERROR:HDLParsers:715 - user_logic.vhd Line 179. Attribute on units are only allowed on current unit. Regards, Homin Jiang(¦¿§»©ú)
Re: [casper] Missing downsample
Hi Glenn: You are right. The problem is gone after i include the signal processing blockset . Thanks a lot homin G Jones wrote: I believe this is in the Simulink signal processing blockset or communications blockset. Glenn On Sun, Nov 9, 2008 at 5:28 PM, Homin Jiang ho...@asiaa.sinica.edu.tw wrote: Dear all: I am trying the 10.1 toolflow. The first problem i have is the downsample block under the ADC yellow block missed. I searched the library a while, but can't find any. The ADC blocks workd well in 7.1. Could someone show me where it is ? -- Regards, Homin Jiang(¦¿§»(c)ú) -- Regards, Homin Jiang(¦¿§»©ú)
