[casper] Confusion over fft_biplex_real_2x
I think Glenn touched on this in an earlier post but I still have some questions. I'm using the ska-sa fork of mlib_devel (last pull probably 1 month ago). 1) Is the output labeling still wrong? i.e. First output claims to be pol02 and second is pol13. Is it in fact pol01 then pol23 or am I missing how the FFT works? 2) If I have 500 Mhz sampled data that is demuxed by two (i.e. two 250Mhz streams interleaved), can I simply connect them up to pol0 and pol1 and the output of pol02 (pol01?) would be the FFT? I could then do the same with a second channel on pol2 and pol3. 3) If the above is correct what is the channel ordering? for example if I set NFFT to 13 I have 2^12 or 4096 channels. Does each clock cycle output in sequential order 0-4096 on each clock cycle the repeat back to 0? Cheers, Ross -- Ross Williamson Research Scientist - Sub-mm Group California Institute of Technology 626-395-2647 (office) 312-504-3051 (Cell)
Re: [casper] KATCP clients not connecting
I would recommend the python route over the matlab route - others may differ. Ross On Mon, Dec 15, 2014 at 2:53 PM, Michael D'Cruze michael.dcr...@postgrad.manchester.ac.uk wrote: Hi Ross, OK thanks for that, I plan to give that a try tomorrow. Any ideas about Corr? Corr seems the more promising route. BW Michael -Original Message- From: Ross Williamson [mailto:rwilliam...@astro.caltech.edu] Sent: 15 December 2014 22:51 To: Michael D'Cruze Cc: casper@lists.berkeley.edu Subject: Re: [casper] KATCP clients not connecting Hi Michael, The MATLAB katcp is very very old. If you look you will see that it looking for a response from tcpborphserver that it no longer sends - You need to hack the katcp.m file to match what the server is currently sending Ross On Mon, Dec 15, 2014 at 1:50 PM, Michael D'Cruze michael.dcr...@postgrad.manchester.ac.uk wrote: Hi everyone I’m trying to connect to the board using the Corr and Matlab katcp clients, however through both the connection times out. I think I have all the python libraries installed, and I definitely have the ICT toolbox installed in Matlab. I’ve tried disabling the firewall. Katcp does work through telnet…. Has anybody seen this issue before? Is there something I’m missing? Very grateful for any suggestions. Michael PS (possibly related problem): I installed Anaconda after this (thought Corr might not like RHEL6.x’s standard python 2.6.6) to bring my python and packages up-to-date and into sync, but katcp wouldn’t then reinstall to the new version. It was complaining of missing setuptools, but in conda I had version 7.0 installed, and there was definitely some version installed in RHEL’s python as well…. If it won’t install full-stop I’ll just get rid of Anaconda but again if anyone’s seen this issue before and has any suggestions please pass them along J. -- Ross Williamson Research Scientist - Sub-mm Group California Institute of Technology 626-395-2647 (office) 312-504-3051 (Cell) -- Ross Williamson Research Scientist - Sub-mm Group California Institute of Technology 626-395-2647 (office) 312-504-3051 (Cell)
[casper] Mkid DAC error
Hi all, I'm using the dac_mkid from the ska branch of mlib_devel. I get the following error and I'm stumped. Error in 'low_freq/dac_mkid1/Subsystem/parallel_to_serial_converter': Initialization commands cannot be evaluated. Caused by: The LinkStatus can be set only for a linked block The input to sdend is boolean (0) and config10data is 4p0. Also is there any documentation for this block? Ross -- Ross Williamson Research Scientist - Sub-mm Group California Institute of Technology 626-395-2647 (office) 312-504-3051 (Cell)
Re: [casper] KATCP clients not connecting
Hi Michael, The MATLAB katcp is very very old. If you look you will see that it looking for a response from tcpborphserver that it no longer sends - You need to hack the katcp.m file to match what the server is currently sending Ross On Mon, Dec 15, 2014 at 1:50 PM, Michael D'Cruze michael.dcr...@postgrad.manchester.ac.uk wrote: Hi everyone I’m trying to connect to the board using the Corr and Matlab katcp clients, however through both the connection times out. I think I have all the python libraries installed, and I definitely have the ICT toolbox installed in Matlab. I’ve tried disabling the firewall. Katcp does work through telnet…. Has anybody seen this issue before? Is there something I’m missing? Very grateful for any suggestions. Michael PS (possibly related problem): I installed Anaconda after this (thought Corr might not like RHEL6.x’s standard python 2.6.6) to bring my python and packages up-to-date and into sync, but katcp wouldn’t then reinstall to the new version. It was complaining of missing setuptools, but in conda I had version 7.0 installed, and there was definitely some version installed in RHEL’s python as well…. If it won’t install full-stop I’ll just get rid of Anaconda but again if anyone’s seen this issue before and has any suggestions please pass them along J. -- Ross Williamson Research Scientist - Sub-mm Group California Institute of Technology 626-395-2647 (office) 312-504-3051 (Cell)
Re: [casper] dram example
I found it - if anyone is gets the broken_link it's located inside the Accumulators subsection. Drag into the design the vacc_tvg block, the look under the mask (ctrl-U) and copy the generate_pulses from inside there. Also for the latest mlib_devel it looks like you need to update the snap64 with the new green snapshot blocks On Wed, Dec 10, 2014 at 1:35 PM, Ross Williamson rwilliam...@astro.caltech.edu wrote: Hi All, I'm trying to run the DRAM example by Laura Spitler but the generate_pulses file is missing. I've tried both casper-astro and ska-sa mlib_devel but it doesn't seem to be present. Anyone know which repository it is located in? Cheers, Ross -- Ross Williamson Research Scientist - Sub-mm Group California Institute of Technology 626-395-2647 (office) 312-504-3051 (Cell) -- Ross Williamson Research Scientist - Sub-mm Group California Institute of Technology 626-395-2647 (office) 312-504-3051 (Cell)
[casper] 10gb Ethernet issue
I'm trying to get 10Gb ethernet up and running on a ROACH-1. I'm using tutorial-2 as a test. I've plugged a cable between ports 0 and 3 and the red led on the ROACH has lit up. Unfortunately when I run tut2.py it claims: Port 0 linkup: False. Also if I try and use tcpborphserver I get the following: tap-start gbe0 02:02:0A:00:00:14 192.168.5.20 6 !tap-start ok #log warn 1415316436391 poco tgtap\_exited\_with\_code\_71 ifconfig -a shows nothing Any thoughts much appreciated -- Ross Williamson Research Scientist - Sub-mm Group California Institute of Technology 626-395-2647 (office) 312-504-3051 (Cell)
Re: [casper] 10gb Ethernet issue
Thanks Ryan - That would be great R On Thu, Nov 6, 2014 at 3:58 PM, Ryan Monroe ryan.m.mon...@gmail.com wrote: Hey ross, I had a bunch of problems when I tried to use 10gbe, and eventually found that there are some problems with the distro that comes with the ROACH1s. I made an image which I can send to you if you'd like. On Thu, Nov 6, 2014 at 3:50 PM, Ross Williamson rwilliam...@astro.caltech.edu wrote: I'm trying to get 10Gb ethernet up and running on a ROACH-1. I'm using tutorial-2 as a test. I've plugged a cable between ports 0 and 3 and the red led on the ROACH has lit up. Unfortunately when I run tut2.py it claims: Port 0 linkup: False. Also if I try and use tcpborphserver I get the following: tap-start gbe0 02:02:0A:00:00:14 192.168.5.20 6 !tap-start ok #log warn 1415316436391 poco tgtap\_exited\_with\_code\_71 ifconfig -a shows nothing Any thoughts much appreciated -- Ross Williamson Research Scientist - Sub-mm Group California Institute of Technology 626-395-2647 (office) 312-504-3051 (Cell) -- Ross Williamson Research Scientist - Sub-mm Group California Institute of Technology 626-395-2647 (office) 312-504-3051 (Cell)
[casper] aux_clk SMAs
Hi all Just confirming that on a ROACH-1 we cannot use the aux_clk SMAs as GPIO/CLK outs? Best regards, Ross -- Ross Williamson Research Scientist - Sub-mm Group California Institute of Technology 626-395-2647 (office) 312-504-3051 (Cell)
Re: [casper] adc5g block run at 2500MHz
On Wed, Jan 15, 2014 at 7:51 AM, Jack Hickish jackhick...@gmail.com wrote: Hi Ross, Thanks for the info -- I've actually got a 5 Gsps ROACH2 (demux 1:1) pocket correlator compiled, and the final piece of the puzzle was getting the ADCs running properly (I only got hold of the hardware relatively recently). But it's always reassuring to know someone else is using a similar system with success! For anyone that's interested, I think I may have solved my problem. I changed the adc interface to use SERDES blocks in oversampling mode, which allowed me to dispense with the high frequency MMCM output. Without this troublesome output, the MMCM can be set into high bandwidth mode and the data capture seems to perform much more happily. After this mod, and setting the IODELAY blocks appropriately, the ADC appears to be capturing data happily without any problems Cheers, Jack On 14 January 2014 18:18, Ross Williamson rwilliam...@astro.caltech.edu wrote: Hi Jack, Not sure this helps as I'm using two DMUX 2:1 at 4GSPS as a correlator on a ROACH-1. The only think I would say is that I've put a fair amount of effort in planahead to try and get 5GSPS. I'm sure it could be done and I've thought I've got close a number of times but in the end I've just eaten that 500MHz of BW as too much effort for the little gain it gives in receiver noise. I would say that on a Roach-1, two boards at 5GSPS (4-bit) works fine if you are just dumping data to a snapshot. I believe a ROACH-2 is harder to reach timing. Ross On Tue, Jan 14, 2014 at 8:11 AM, Jack Hickish jackhick...@gmail.com wrote: Hi all, Like Weiwei, I'm trying to use the ADC5g at 5 Gsps. I've played with a simple ADC to snap model, and (as Rurik warned) getting reliable data capturing is difficult at this speed. I've tried per-bit calibration of input data streams via IODELAYs in conjunction with phase-shifting of the sampling clock, but can't seem to achieve glitchless data capture for any reasonable length of time. In the email I'm replying to, Rurik suggests a number of ways around this problem, but before I opt for forcing an unsupported MMCM mode by compiling and running at different speeds, I thought a final desperate plea for any advice on the maillist might be worthwhile. If anyone has any words of wisdom, I'd be excessively grateful to hear from them. Cheers, Jack On 6 November 2013 16:31, Primiani, Rurik rprimi...@cfa.harvard.edu wrote: Hi Weiwei, Generally the sma-wideband/mlib_devel has the most recent changes to the ADC5g yellow block, please use the latest commit of that repo (at this moment it is 2c80cb2). The problem your are seeing is related to a change that was introduced in the Xilinx tools (I believe from version 11 to 12) that increased the minimum frequency of the Virtex-6 MMCM's PFD to 135 MHz from 125 MHz in HIGH bandwidth mode. This made it no longer possible to clock the fabric from an ADC5g running at 4800 Msps using an MMCM in HIGH bandwidth mode. There are a few options for moving forward (ordered by ease of implementation): 1. Clock the ADC below (and not including) 2400 MHz 2. Change MMCM from HIGH to LOW bandwidth mode 3. Compile your design with the ADC clocked above (and not including) 5400 MHz, but actually run it at 5 GHz 4. Force the Xilinx tools to allow the PFD to run at 125 MHz in HIGH bandwidth mode 5. Compile your design using the Xilinx 11 tools If you don't need to sample at exactly 5 Gsps then option 1 is the optimal solution. If 5 Gsps is critical then you can go with options 2 or 3. Option 2 has non-ideal clock-to-out timing and may cause problems when trying to calibrate out jitter due to the data capturing. Option 3 may cause timing problems since your fabric clock will run at 337.5 MHz. I have not found a way to implement option 4 but I can't see why this shouldn't be possible. Finally option 5 may or may not be useful to you. The SMA wideband correlator runs its ADCs below 4800 Msps. However we have bitcodes that we use to characterize the ADC that run at 5 Gsps and which have low resource utilization. For what it's worth we used option 3 to get around this issue and this appears to work for us. Whatever reason Xilinx had for changing the minimum PFD frequency to 135 MHz does not seem to cause problems for us. Hope this helps, Rurik On Wed, Nov 6, 2013 at 2:29 AM, Weiwei Sun su...@uw.edu wrote: I tried the casper-astro, ska-sa, sma-wideband. None of them seemly works. Weiwei On Tue, Nov 5, 2013 at 10:20 PM, Primiani, Rurik rprimi...@cfa.harvard.edu wrote: Hi, Which version
[casper] Simple clk divider
Hi All, I suspect this is really simple but I just cannot get this to work in simulink. I would like to divide the sys_clk by a factor set by a software register. To do this in VHDL is very simple - You setup a counter and invert the output when it reaches half of the required clk divide - the counter is then reset. The problem is trying to draw the simulink equivalent. The counter and relational are fairly simple but you need to be able to assign an initial value to the not gate but I cannot seem to be able to do this. What is the obvious thing that I'm missing here? Ross -- Ross Williamson Research Scientist - Sub-mm Group California Institute of Technology 626-395-2647 (office) 312-504-3051 (Cell)
Re: [casper] Simple clk divider
Thanks Glen - I can see that will work. On Wed, Nov 13, 2013 at 2:41 PM, G Jones glenn.calt...@gmail.com wrote: Usually people just slice the bit you want off a counter. To select the bit using a software register, just use the software register as the select for a mux. Or use the software register as a bit mask and AND it with the counter, then use the output of a relational == 0 as your divided counter. On Wed, Nov 13, 2013 at 5:38 PM, Ross Williamson rwilliam...@astro.caltech.edu wrote: Hi All, I suspect this is really simple but I just cannot get this to work in simulink. I would like to divide the sys_clk by a factor set by a software register. To do this in VHDL is very simple - You setup a counter and invert the output when it reaches half of the required clk divide - the counter is then reset. The problem is trying to draw the simulink equivalent. The counter and relational are fairly simple but you need to be able to assign an initial value to the not gate but I cannot seem to be able to do this. What is the obvious thing that I'm missing here? Ross -- Ross Williamson Research Scientist - Sub-mm Group California Institute of Technology 626-395-2647 (office) 312-504-3051 (Cell) -- Ross Williamson Research Scientist - Sub-mm Group California Institute of Technology 626-395-2647 (office) 312-504-3051 (Cell)
Re: [casper] Fwd: Boot Filesystem
I have a bloated Wheezy distribution working over NFS boot - It only works with the mmap kernel on a ROACH-1 and tcpborphserver3. I can tar it up and place it somewhere accessible if you like. R On Tue, Nov 5, 2013 at 3:51 AM, Prajwal Mohanmurthy praj...@mit.edu wrote: Hi, Is there somewhere a filesystem which is perhaps derived from a more recent debian distribution? I am only aware of the ones located at https://casper.berkeley.edu/svn/trunk/roach/sw/binaries/filesystem/ where 2010 Debian etch derived version looks like the latest one. Thanks, Prajwal -- ___ Prajwal Mohanmurthy Laboratory for Nuclear Science Massachusetts Institute of Technology 77 Massachusetts Avenue 540 Building 26 Cambridge, MA 02139 USA Voice: +001 662 546 0508 EMail: praj...@mohanmurthy.com Web: www.mohanmurthy.com ___ -- ___ Prajwal Mohanmurthy Laboratory for Nuclear Science Massachusetts Institute of Technology 77 Massachusetts Avenue 540 Building 26 Cambridge, MA 02139 USA Voice: +001 662 546 0508 EMail: praj...@mohanmurthy.com Web: www.mohanmurthy.com ___ -- Ross Williamson Research Scientist - Sub-mm Group California Institute of Technology 626-395-2647 (office) 312-504-3051 (Cell)
Re: [casper] MMAP on Roach-1
Hi Andrew and Wes, You've both convinced me to write a parser for the core_info.tab file - It's more transferable and less likely to screw things up. Cheers, Ross On Mon, Oct 21, 2013 at 11:58 PM, Andrew Martens and...@ska.ac.za wrote: Hi Ross Hi Wes and all, So the MMAP is working really quite well on a ROACH-1 - This question is more my lack of understanding of the tool-chain. Does anybody know how to fix the memory address for the various CASPER brams and registers. I edited the core_info.tab inside the copied XPS_ROACH_BASE and unchecked Copy base package but It still was overwritten (I'm assuming this is in the system generator stage). I'd rather not hack the top level core_info.tab so what would be the best way to define the memory locations? I am assuming that you want to write code that has the addresses hard-coded in some way. The best would be not to do this and have your code figure out the addresses from the core_info.tab file. If you must, build your design till the last stage (uncheck the EDK and ISE part). Then go hand edit the system.mhs file in the XPS_ROACH_BASE directory. You will find your registers and brams and where you they are on the bus. You can change where they are in the address space. When you are done, perform the final stage in the build (uncheck everything except the EDK, ISE part and build). Take some time to figure out how the address space is organised (most devices are hard-coded but the registers and shared brams are allocated address space within a specific area at compile time). If you have many yellow blocks you may have to also figure out how opb bridges work. Good luck Regards Andrew Ross On Tue, Oct 15, 2013 at 4:48 PM, Ross Williamson rwilliam...@astro.caltech.edu wrote: Hi Wes, Thanks - I got the MMAP up and running on a ROACH1 with those instructions. R On Tue, Oct 15, 2013 at 12:19 AM, Wesley New wes...@ska.ac.za wrote: Hi Ross, The steps should be outlined here. https://casper.berkeley.edu/wiki/FPGA_Device_Driver_Memo I am not sure if these steps work for ROACH1 and 2 but at least it is a starting point. Wes Wesley New South African SKA Project +2721 506 7365 www.ska.ac.za On Tue, Oct 15, 2013 at 3:09 AM, Ross Williamson rwilliam...@astro.caltech.edu wrote: Hi All, I know from the CASPER meeting that MMAP is available for the ROACH-1. Are there any instructions anywhere on getting it up and running? Best regards, Ross -- Ross Williamson Research Scientist - Sub-mm Group California Institute of Technology 626-395-2647 (office) 312-504-3051 (Cell) -- Ross Williamson Research Scientist - Sub-mm Group California Institute of Technology 626-395-2647 (office) 312-504-3051 (Cell) -- Ross Williamson Research Scientist - Sub-mm Group California Institute of Technology 626-395-2647 (office) 312-504-3051 (Cell)
[casper] Random failures on Compile
I'm in a rather frustrating situation where the casper tools will only compile in a seemingly random nature. I can load up a design that I know compiles into simulink and run it and I will get an error like the following: Error reported by S-function 'sysgen' in 'ccat_corr_lowbits/ADC0/Constant6': An internal error occurred in the Xilinx Blockset Library. There is nothing obviously wrong with the constant (and the whole .slx has compiled as is before) Shutting down and starting up matlab sometimes fixes the issue - trying to compiled a different .slx and then going back to the one that doesn't work sometimes fixes it (Sometimes does not) - I can screw around a whole day trying to get it to compile and the next day it works fine. Has anyone experienced this (pseudo) random compile problems and know of a good sequence to make a model compile again? Ross -- Ross Williamson Research Scientist - Sub-mm Group California Institute of Technology 626-395-2647 (office) 312-504-3051 (Cell)
Re: [casper] bram and katcp
Thanks everyone for the input. I've been trying not to move towards the 10 gb option if possible for a couple of reasons but I might have to bite the bullet. I'm also going to look at another option which is with the mmap kernel I have access to the FPGA memory in /dev/roach/mem. I think it should be fairly easy to write a custom server that runs on the roach that collects the bram data from the mem and then buffers if for sending over ethernet via udp. This is probably very similar to what the UDP option in tcpborphserver does but I'll be able to control the amount of buffering I guess you could call it a replacement for tcpborphserver that is specific for my application. Cheers, Ross On Wed, Oct 16, 2013 at 6:01 AM, Marc Welz m...@ska.ac.za wrote: Hello The path FGA-PPC-ethernet-python hasn't been optimised for speed. So if you can get hold of a PCI(e) CX4 ethernet card for your capture machine then you will save yourself a considerable amount of effort and get way better max transfer rates However: If this isn't an option, there are a couple of things you can attempt. The warning is that you will have to be(come) reasonably handy with C. As Jason mentioned, you could try larger read sizes and maybe have multiple concurrent reads from different connections in an effort to amortise the round trip time. If that doesn't work: tcpborphserver(2,3) has an extension mechanism... you can run callbacks which do things - and one option is to run something which sends out your data in UDP packets - that saves on encoding time (no katcp escaping) and also doesn't halve throughput on packet loss. It turns out that in tcpborphserver2 there is an optional mode which can be built which is specific for a pocket correlator - this does provide an example on how to implement udp data dumping. The downside is that the interface is not documented and there are some differences between v2 and v3 Another option is to look at the linux kernel driver for the network interface, there was some weirdness with the EMAC and also the PHY - so there may be the option of tweaking and fixing things to get better throughput regards marc -- Ross Williamson Research Scientist - Sub-mm Group California Institute of Technology 626-395-2647 (office) 312-504-3051 (Cell)
Re: [casper] bram and katcp
Hi Guys, Thanks - I'm initially going to pursue the mmap option. I think quite a few of the issues are tcp latencies and by removing those I can make the link more reliable. I'm looking at a max of about 5Mb/s through the FPGA--PPC interface. I should fairly soon be able to check what speed I can achieve. Ross On Wed, Oct 16, 2013 at 11:26 AM, David Hawkins d...@ovro.caltech.edu wrote: Hi Dave, Boot the board, stop in U-Boot, write to the DMA registers directly, and probe the bus to see what the maximum rate possible is ... then you can decide whether to write a device driver to use the DMA controller under Linux. Oh, yeah, trying to use the DMA controllers on the PPC side would be very interesting! I was referring to the CASPER implementation of the FPGA side of the EPB bus not supporting being a DMA bus master (I'm not even sure that the EPB bus supports external DMA bus masters). The 440EP and the Freescale processors do not support external DMA masters ... in fact, I'm not sure that I have seen any recent processor that supports this feature (I've looked at many ARM-based processor data sheets). Although I think its a common feature on DSP processors ... If Ross has never had to do this before, he might not have appreciated where to look/where to start. If Ross has never had to do this before, he's probably better off using the pre-canned Ethernet directly from the FPGA solution rather than (re-)writing a Linux device driver to use DMA. :-) Sure, I was just adding to his list of options :) Cheers, Dave -- Ross Williamson Research Scientist - Sub-mm Group California Institute of Technology 626-395-2647 (office) 312-504-3051 (Cell)
Re: [casper] bram and katcp
So I just did a very quick test where I read 10 an ADC snapshot (8192 Bytes) via mmap(boost::iostreams::mapped_file) using std::copy(). This took about 52 seconds which is about 15MB/s or 120Mb/s - Sound to fast??? Ross On Wed, Oct 16, 2013 at 11:47 AM, Ross Williamson rwilliam...@astro.caltech.edu wrote: Hi Guys, Thanks - I'm initially going to pursue the mmap option. I think quite a few of the issues are tcp latencies and by removing those I can make the link more reliable. I'm looking at a max of about 5Mb/s through the FPGA--PPC interface. I should fairly soon be able to check what speed I can achieve. Ross On Wed, Oct 16, 2013 at 11:26 AM, David Hawkins d...@ovro.caltech.edu wrote: Hi Dave, Boot the board, stop in U-Boot, write to the DMA registers directly, and probe the bus to see what the maximum rate possible is ... then you can decide whether to write a device driver to use the DMA controller under Linux. Oh, yeah, trying to use the DMA controllers on the PPC side would be very interesting! I was referring to the CASPER implementation of the FPGA side of the EPB bus not supporting being a DMA bus master (I'm not even sure that the EPB bus supports external DMA bus masters). The 440EP and the Freescale processors do not support external DMA masters ... in fact, I'm not sure that I have seen any recent processor that supports this feature (I've looked at many ARM-based processor data sheets). Although I think its a common feature on DSP processors ... If Ross has never had to do this before, he might not have appreciated where to look/where to start. If Ross has never had to do this before, he's probably better off using the pre-canned Ethernet directly from the FPGA solution rather than (re-)writing a Linux device driver to use DMA. :-) Sure, I was just adding to his list of options :) Cheers, Dave -- Ross Williamson Research Scientist - Sub-mm Group California Institute of Technology 626-395-2647 (office) 312-504-3051 (Cell) -- Ross Williamson Research Scientist - Sub-mm Group California Institute of Technology 626-395-2647 (office) 312-504-3051 (Cell)
[casper] NFS ROACH 1 kernel and filesytem
Hi All, I'm looking at NFS booting (from https://casper.berkeley.edu/wiki/ROACH_NFS_guide) but there are couple of different filesystems without dates on them. Which one is the latest? I'm using a ROACH-1 Ross -- Ross Williamson Research Scientist - Sub-mm Group California Institute of Technology 626-395-2647 (office) 312-504-3051 (Cell)
[casper] bram and katcp
I was wondering what kind of readout speed should I expect through
katcp (python) and the tcpborphserver3 on a Roach1 (MMAP).
My simple spectrometer design has 16/channels per fft (48_34 bit) with
8 simultaneous paths (total of 128 channels). These get fed into 12
brams (32 bits 2^10 address). This gives me 64 integrations before
the address wraps. I'm trying to accumulate the data so that it reads
out at 100Hz so I have approximately 0.5 seconds to grab 32kb*12
(384kb) of data which is roughly 1Mb/s.
Using read('var', 4096) on each of the brams struggles (fails 10%
time) to make this 1Mb/s. Is this slow rate something to be expected
or do I have a coding error? I'm concerned because the correlator
version will have 32kb*48 outputs which if the speed scales will mean
the data collection time is too slow if I don't want to loose samples.
Ross
p.s. The MMAP improves the speed by about a factor of 2 over the
tcpborphserver2.
--
Ross Williamson
Research Scientist - Sub-mm Group
California Institute of Technology
626-395-2647 (office)
312-504-3051 (Cell)
[casper] Problem with fi and test suite
Hi, I'm trying to implement a test suite for a correlator and I'm having serious problems with my understanding of fi. The output of the fft stage is UFIX 36_0. I capture that in a matlab variable (say fft_out0). All I want to do is split that up into Re and Im parts at FIX 18_17. I'm finding this rather difficult to do in matlab (especially because simple bit operations such as and representing numbers via 0x notation do not work). If for example I try and convert the output from matlab fi(fft_out0,0,36,0) I still get a fractional number which baffles me. Is there a way to take this UFIX36_0, split into two FIX 18_17 and turn it into a complex number? Ross p.s. I'm using the unbus blocks to create the simulink output. I don't want to manually add gateways from every re_im block unless I really have to. (p.p.s I'm coming from scipy where this would be trivial hence the want to throw the toys out of the pram) -- Ross Williamson Research Scientist - Sub-mm Group California Institute of Technology 626-395-2647 (office) 312-504-3051 (Cell)
Re: [casper] Problem with fi and test suite
I could do that but it's messy and it should not be difficult to do in Matlab - I have screwed up though fi(fft_out0,0,36,0) is not a fractional number at all - Matlab puts it in exponential form which is described at the top of the list about 100 page-scrolls back.. This might make the rest of what I'm doing make more sense.. Matlab always put's me in a good mood. Ross On Thu, Oct 3, 2013 at 1:48 PM, G Jones glenn.calt...@gmail.com wrote: I always just break out the real and imag parts before going to matlab workspace On Oct 3, 2013 4:23 PM, Ross Williamson rwilliam...@astro.caltech.edu wrote: Hi, I'm trying to implement a test suite for a correlator and I'm having serious problems with my understanding of fi. The output of the fft stage is UFIX 36_0. I capture that in a matlab variable (say fft_out0). All I want to do is split that up into Re and Im parts at FIX 18_17. I'm finding this rather difficult to do in matlab (especially because simple bit operations such as and representing numbers via 0x notation do not work). If for example I try and convert the output from matlab fi(fft_out0,0,36,0) I still get a fractional number which baffles me. Is there a way to take this UFIX36_0, split into two FIX 18_17 and turn it into a complex number? Ross p.s. I'm using the unbus blocks to create the simulink output. I don't want to manually add gateways from every re_im block unless I really have to. (p.p.s I'm coming from scipy where this would be trivial hence the want to throw the toys out of the pram) -- Ross Williamson Research Scientist - Sub-mm Group California Institute of Technology 626-395-2647 (office) 312-504-3051 (Cell) -- Ross Williamson Research Scientist - Sub-mm Group California Institute of Technology 626-395-2647 (office) 312-504-3051 (Cell)
Re: [casper] Problem with fi and test suite
Hi Danny,
It was the reinterpretcast function that fixed my problems.
Cheers,
Ross
p.s. BTW in python there is a fixed_point module called SPFPM but it's
not great. I've just found that bit manipulation is a little more
straight forward using python.
On Thu, Oct 3, 2013 at 1:39 PM, Danny Price dpr...@cfa.harvard.edu wrote:
Hi Ross
I think this should do exactly what you want:
% Convert complex data stored in a 36_0 Unsigned format into
% actual complex data in a matlab array
% Useful for converting output of casper FFT into complex array.
function cplx_vec = conv36u_cplx(vec_36u)
%disp('Converting 36_0 data to 18_17 complex')
s18 = numerictype(1, 18, 17);
cplx_vec = complex(zeros(length(vec_36u),1));
for jj=1:length(vec_36u)
a = fi(vec_36u(jj), 0, 64, 0);
re = reinterpretcast(bitsliceget(a, 18, 1), s18);
im = reinterpretcast(bitsliceget(a, 36, 19), s18);
cplx = re + im*1i;
cplx_vec(jj) = cplx;
end
There may be a neater way to do this (in which case please tell me!).
Regards
Danny
PS: I've never done fixed point stuff with scipy, can you point me in the
direction of some examples?
Ross Williamson wrote:
Hi,
I'm trying to implement a test suite for a correlator and I'm having
serious problems with my understanding of fi. The output of the fft
stage is UFIX 36_0. I capture that in a matlab variable (say
fft_out0). All I want to do is split that up into Re and Im parts at
FIX 18_17. I'm finding this rather difficult to do in matlab
(especially because simple bit operations such as and
representing numbers via 0x notation do not work).
If for example I try and convert the output from matlab
fi(fft_out0,0,36,0) I still get a fractional number which baffles me.
Is there a way to take this UFIX36_0, split into two FIX 18_17 and
turn it into a complex number?
Ross
p.s. I'm using the unbus blocks to create the simulink output. I don't
want to manually add gateways from every re_im block unless I really
have to.
(p.p.s I'm coming from scipy where this would be trivial hence the
want to throw the toys out of the pram)
--
Ross Williamson
Research Scientist - Sub-mm Group
California Institute of Technology
626-395-2647 (office)
312-504-3051 (Cell)
[casper] Matlab 2012b simulation problem
Hi All, I'm trying to run a simple simulation on an ADC block. I'm just changing the frequency of the input sine wave. Unless I refresh the ADC block (change frequency etc) then the simulation fails to run correctly - no sync pulse generated and the output of the ADC is always zero (a scope on the sine simulator does show the correct wave). I also get the following warning: Warning: did not properly cleanup after previous model termination2012 Any ideas much appreciated as it's a real pain at the moment to run anything. Ross -- Ross Williamson Research Scientist - Sub-mm Group California Institute of Technology 626-395-2647 (office) 312-504-3051 (Cell)
[casper] Simulation of tutorial3
I'm trying to simulate tut3 by putting in a sine-wave at the input and looking at the output of the accumulators - the acc_length is 2 and FFT and pfb size is 12. Input parameters for the sine wave are: Sample based, Simulation Time Amplitude 0.1 Bias 0 Sample per period 100 number of offset samples 0 sample time 1/4 Interpret vector parameters as 1-D checked I only look in the region where the output valid flag is high - The problem is that I get a forest of lines out of both accumulators with no obvious spike where the signal should be. It doesn't look like there is clipping. I can post pictures of the scopes if needed but I'm just wondering if I'm missing something obvious? -- Ross Williamson Research Scientist - Sub-mm Group California Institute of Technology 626-395-2647 (office) 312-504-3051 (Cell)
Re: [casper] Simulation of tutorial3
yes indeed a sync pulse does help significantly doh On Wed, May 15, 2013 at 12:36 PM, Jack Hickish jackhick...@gmail.com wrote: Hi Ross, Have you looked upstream at, eg, the FFT output, to check there is a single spike coming out of that? Might also be worth making sure that you are simulating a sync pulse, and waiting long enough for data after the sync to propagate all the way through the design. Cheers, Jack On 15 May 2013 20:28, Ross Williamson rwilliam...@astro.caltech.edu wrote: I'm trying to simulate tut3 by putting in a sine-wave at the input and looking at the output of the accumulators - the acc_length is 2 and FFT and pfb size is 12. Input parameters for the sine wave are: Sample based, Simulation Time Amplitude 0.1 Bias 0 Sample per period 100 number of offset samples 0 sample time 1/4 Interpret vector parameters as 1-D checked I only look in the region where the output valid flag is high - The problem is that I get a forest of lines out of both accumulators with no obvious spike where the signal should be. It doesn't look like there is clipping. I can post pictures of the scopes if needed but I'm just wondering if I'm missing something obvious? -- Ross Williamson Research Scientist - Sub-mm Group California Institute of Technology 626-395-2647 (office) 312-504-3051 (Cell) -- Ross Williamson Research Scientist - Sub-mm Group California Institute of Technology 626-395-2647 (office) 312-504-3051 (Cell)
Re: [casper] Simulation of tutorial3
A couple of more questions regarding simulation of tutorial3 - The setup has a 2^8 FFT (so 128 channels, 64 per vacc) 1) It looks as if the valid flag on Vacc is going high about 6 clock cycles before it should. This was tested by putting in an f=0.5 sine wave at the input to the adc (sample/period = 4, sample time = 1/4). The output from the vacc1 is at 38 rather than 32 and a DC component is also shifted by 6 (I'm not sure why there is a DC component). If you look at the latencies from the valid flag to dout there is 4 (so not quite 6) but I guess that gets us close - it is an error though and a think there should be a delay on the vacc valid line. 2) Maybe this is to be expected but if I shift the frequency below f=0.5, say f=0.25 then there are quite distinct harmonics present at f= 0.5 (about 1/8 of main freq) 0.75 (about half of main freq). I'm wondering if this is something to do with the discrete nature if the input sine-wave but I haven't thought too much about it. On Wed, May 15, 2013 at 1:04 PM, Ross Williamson rwilliam...@astro.caltech.edu wrote: yes indeed a sync pulse does help significantly doh On Wed, May 15, 2013 at 12:36 PM, Jack Hickish jackhick...@gmail.com wrote: Hi Ross, Have you looked upstream at, eg, the FFT output, to check there is a single spike coming out of that? Might also be worth making sure that you are simulating a sync pulse, and waiting long enough for data after the sync to propagate all the way through the design. Cheers, Jack On 15 May 2013 20:28, Ross Williamson rwilliam...@astro.caltech.edu wrote: I'm trying to simulate tut3 by putting in a sine-wave at the input and looking at the output of the accumulators - the acc_length is 2 and FFT and pfb size is 12. Input parameters for the sine wave are: Sample based, Simulation Time Amplitude 0.1 Bias 0 Sample per period 100 number of offset samples 0 sample time 1/4 Interpret vector parameters as 1-D checked I only look in the region where the output valid flag is high - The problem is that I get a forest of lines out of both accumulators with no obvious spike where the signal should be. It doesn't look like there is clipping. I can post pictures of the scopes if needed but I'm just wondering if I'm missing something obvious? -- Ross Williamson Research Scientist - Sub-mm Group California Institute of Technology 626-395-2647 (office) 312-504-3051 (Cell) -- Ross Williamson Research Scientist - Sub-mm Group California Institute of Technology 626-395-2647 (office) 312-504-3051 (Cell) -- Ross Williamson Research Scientist - Sub-mm Group California Institute of Technology 626-395-2647 (office) 312-504-3051 (Cell)
Re: [casper] Latency in PFB and FFT
Hi Ryan and Andrew, Thanks for the info - I'm looking into it. Ryan - Anytime between 4 and 5 works for me - I'm in 365 Cheers, Ross On Tue, May 7, 2013 at 9:51 AM, Ryan Monroe ryan.m.mon...@gmail.com wrote: Hi Ross, I just added a memo to the CASPER page. It was a study I did on meeting timing for ROACH2, but it applies to ROACH1 and should be illuminating w.r.t. timing closure on these parts. Using the techniques I describe there /might/ get you to 325 MHz. Keep in mind that I was *completely* unprofessional in that document. Don't go looking for something that can be published in nature ;-) BUT you will get to see how I really feel about Xilinx tools That said, your goal is pretty ambitious so be prepared for a struggle. I support everything Andrew said below. Specifically, there is generally a hard limit, past which adding more latency *never* helps. For instance, with a multiply that is 18x25 or smaller, that limit is 4 (but Xilinx often doesn't choose the optimal configuration so it's worse) DSP48 adds, it's 3. for fabric adds, it's 1. Anything more than these numbers will almost always hurt you, although less can help. I'm planning on being down at Caltech 3:30-4:00 today. If you want, I can meet you and talk about it either before or after that slot? --Ryan On 05/06/2013 11:33 PM, Andrew Martens wrote: Hi Ross The guys at Berkeley and Ryan would probably have more detailed advice (especially regarding hand-placement) but the following are some general guidelines if trying to optimise timing from within System Generator; 1. Adding latency to an operation in System Generator results in the following; a. Register stages are added to sections within the operation so as to pipeline things and allow higher speed operation. This is useful where pipeline registers exist in cores e.g the DSP48 multiplier core. It is also useful in operations that can be pipelined e.g the cast/convert block uses a sequence of operations. b. Once all possible register stages within the operation are exhausted, the remaining latency is allocated after the operation. This latency will be limited in the benefit it adds as it is normally implemented in a single slice (the look up table can act as a shift register in Xilinx FGPAs and the final register stage of latency is implemented using the register in the slice). This leads to the following tips; 1. Avoid long chains of asynchronous logic. Add latency to operations involving large fanout or fanin e.g muxes, adders, comparators, cast/convert. Do a bit of thinking and research on how the various operations would be implemented under-the-hood. 2. Register inputs and outputs of blocks. 3. Use the CASPER Delays/pipeline block instead of the System Generator delay block on critical timing paths (the pipeline block forces the latency to be implemented in a pipeline of register stages instead of being absorbed into a single slice). 4. BRAMs followed by Multipliers often cause timing problems as they are limited and location constrained. These occur in the pfb_fir and fft. Add lots of BRAM latency to help (at least 3 to start) and Multiplier latency (4 would be a start but adding too much adds register stages *after* the Multiplier which is pointless). 5. Any input/output to/from yellow blocks (especially FPGA pins) should contain a pipeline block with a latency of at least 2 (allowing one register stage near source and one near destination). 6. Check to see if the System Generator block you are using has timing related options e.g the cast/convert has a 'Pipeline for maximum performance' option. Cheers Andrew Hi All, I'm trying to get the ROACH1 to run at 325MHz (5GSPS) in a simple spectrometer. This is obviously pushing the limits of the hardware - I'm kind or arbitrarily tweaking the latencies in these blocks to try and meet timing requirements. Are there any guidelines/notes I should be following - i.e should certain latencies match such as Add and bram where as say Fanout doesn't matter. Also are there any limits on these - i.e say 20 rather than 2? I'm sure if my understanding of the PFB and FFT was more than minimal this would be obvious... R -- Ross Williamson Research Scientist - Sub-mm Group California Institute of Technology 626-395-2647 (office) 312-504-3051 (Cell) -- Ross Williamson Research Scientist - Sub-mm Group California Institute of Technology 626-395-2647 (office) 312-504-3051 (Cell)
[casper] Latency in PFB and FFT
Hi All, I'm trying to get the ROACH1 to run at 325MHz (5GSPS) in a simple spectrometer. This is obviously pushing the limits of the hardware - I'm kind or arbitrarily tweaking the latencies in these blocks to try and meet timing requirements. Are there any guidelines/notes I should be following - i.e should certain latencies match such as Add and bram where as say Fanout doesn't matter. Also are there any limits on these - i.e say 20 rather than 2? I'm sure if my understanding of the PFB and FFT was more than minimal this would be obvious... R -- Ross Williamson Research Scientist - Sub-mm Group California Institute of Technology 626-395-2647 (office) 312-504-3051 (Cell)
[casper] Debian Sqeeze and BORPH
Hi All, I've been playing around in my spare time trying to get Debian squeeze as the OS for a ROACH board (possibly a bad/pointless idea but hey). The issue I'm facing is that I need a kernel with UDEV support in and so launched into cross-compiling one. The problem is finding a BORPH patch that matches the kernel - I came across the following two links https://github.com/brandonhamilton/BORPH http://wiki.netfpga.org/foswiki/bin/view/NetFPGA/OneGig/BORPH The first one doesn't mention which kernel the patch is for (fails on latest 2.6) and then second one has no permissions for the link. Does anyone have links to a later version of the kernel with the BORPH patch in? I'd like sources so I can really break things. Cheers, Ross -- Ross Williamson Research Scientist - Sub-mm Group California Institute of Technology 626-395-2647 (office) 312-504-3051 (Cell)
Re: [casper] ERROR:Xflow - map: application received signal 9
Sig 9 can be caused by not enough memory - Have you watched memory usage during mapping? On Sun, Mar 31, 2013 at 11:32 PM, Haoxuan Zheng jef...@mit.edu wrote: Hi, Sorry for the spam but here's a small update. I just restarted the (virtual) machine and tried casper_xps again, and the same error occurred at a later stage. I have successfully compiled non-trivial designs on this same machine/setting/versions before, but this one is by far the most intense (should take up roughly 50% of the FPGA resource). Here's the new error message: Writing file system_map.ngm... Running directed packing... Running delay-based LUT packing... *Updating timing models...* INFO:Map:215 - The Interim Design Summary has been generated in the MAP Report (.mrp). Running timing-driven placement... Total REAL time at the beginning of Placer: 8 mins 6 secs Total CPU time at the beginning of Placer: 8 mins 3 secs Phase 1.1 Initial Placement Analysis Phase 1.1 Initial Placement Analysis (Checksum:86815621) REAL time: 8 mins 59 secs Phase 2.7 Design Feasibility Check Phase 2.7 Design Feasibility Check (Checksum:86815621) REAL time: 9 mins 14 secs Phase 3.31 Local Placement Optimization Phase 3.31 Local Placement Optimization (Checksum:44c9354) REAL time: 9 mins 14 secs Phase 4.37 Local Placement Optimization Phase 4.37 Local Placement Optimization (Checksum:44c9354) REAL time: 9 mins 14 secs Phase 5.2 Initial Placement for Architecture Specific Features *ERROR:Xflow - map: application received signal 9* *ERROR:Xflow:42 - Aborting flow execution... * *gmake: *** [__xps/system_routed] Error 1* *ERROR:EDK - * * Error while running gmake -f system.make bits.* *Error using gen_xps_files (line 640)* *XPS failed.* * * Thank you so much for any inputs! Jeff -- *From:* casper-boun...@lists.berkeley.edu [ casper-boun...@lists.berkeley.edu] on behalf of Haoxuan Zheng [ jef...@mit.edu] *Sent:* Sunday, March 31, 2013 11:45 PM *To:* casper@lists.berkeley.edu; Jonathan L Losh; sanchez.nev...@gmail.com *Subject:* [casper] ERROR:Xflow - map: application received signal 9 Hi Casper, I have been getting the following error when running casper_xps compilation (see bold part towards the end). I am running Xilinx ISE 14.2 on Matlab 2012a on Ubuntu 11.10. Any thoughts or suggestions would be greatly appreciated! #--# # Starting program map # map -timing -detail -ol high -xe n -register_duplication -o system_map.ncd -w -pr b system.ngd system.pcf #--# Release 14.2 - Map P.28xd (lin64) Copyright (c) 1995-2012 Xilinx, Inc. All rights reserved. PMSPEC -- Overriding Xilinx file /media/80Gb/Programs/Xilinx/14.2/ISE_DS/EDK/data/Xdh_PrimTypeLib.xda with local file /media/80Gb/Programs/Xilinx/14.2/ISE_DS/ISE/data/Xdh_PrimTypeLib.xda Using target part 6vsx475tff1759-1. Mapping design into LUTs... WARNING:MapLib:701 - Signal qdr1_cq_n connected to top level port qdr1_cq_n has been removed. **similar warning skipped here** WARNING:MapLib:701 - Signal qdr1_bw_n3 connected to top level port qdr1_bw_n3 has been removed. **similar warning skipped here** WARNING:MapLib:701 - Signal aux_clk_n connected to top level port aux_clk_n has been removed. WARNING:MapLib:701 - Signal aux_clk_p connected to top level port aux_clk_p has been removed. Writing file system_map.ngm... Running directed packing... Running delay-based LUT packing... *Updating timing models...* *ERROR:Xflow - map: application received signal 9* *ERROR:Xflow:42 - Aborting flow execution... * *gmake: *** [__xps/system_routed] Error 1* *ERROR:EDK - * * Error while running gmake -f system.make bits.* *Error using gen_xps_files (line 640)* *XPS failed.* Thank you so much! Jeff -- Ross Williamson Research Scientist - Sub-mm Group California Institute of Technology 626-395-2647 (office) 312-504-3051 (Cell)
Re: [casper] ADC 1x5000-8 Dux 1:2 Notes
Thanks Kim for the info - let me know if you get something up and running. R On Thu, Mar 14, 2013 at 6:35 PM, Kim Guzzino kguzz...@yahoo.com wrote: Ross, I did a little work on the 1:2 after Rurik had finished it, although I abandoned it also. I will check my code and see if it compiles ok for Roach 1. I do remember it having some issue with using both ZDOKs but I'm not sure. I will let you know in the morning. Kim -Original Message- From: casper-boun...@lists.berkeley.edu [mailto:casper-boun...@lists.berkeley.edu] On Behalf Of Rurik A Primiani Sent: Thursday, March 14, 2013 4:14 PM To: Ross Williamson Cc: casper Subject: Re: [casper] ADC 1x5000-8 Dux 1:2 Notes Hi Ross, I developed a large part of the 5GSps ADC yellow block(s) in the sma-wideband repository using previous code kindly provided by Homin Jiang and Kim Guzzino. Unfortunately, as Jonathan mentioned in a previous email, we basically left the ROACH1, 1:2 DMUX yellow block behind when we realized we weren't going to use it. In its present state it's basically broken. I would suggest getting it up to date by bringing in the clock-domain crossing FIFO that was added into the other blocks. If I remember correctly this was the last feature left when I stopped developing that particular block. You should be able to copy the FIFO-related VHDL code and the FIFO netlist over from the 1:1, just make sure to adjust the MPD, PAO, etc as needed. Using the ROACH2, 1:2 block as a comparison is also a good idea. Basically the biggest difference between the two is that the R2 version uses a MMCM while the R1 version uses DCM/PLL. About the adc1_dcm_locked error you're receiving: this is a bug and I guess I forgot to fix it for ROACH1. If you look at line 203 in system.mhs, https://github.com/sma-wideband/mlib_devel/blob/master/xps_base/XPS_ROACH_ba se/system.mhs#L203, you'll notice that the conditional statement checks for the presence of adc0: #IF# (strcmp(get(b,'type'),'xps_adc5g')) get(b,'use_adc0')# PORT adc1_dcm_locked = adc1_dcm_locked This should actually read: #IF# (strcmp(get(b,'type'),'xps_adc5g')) get(b,'use_adc1')# PORT adc1_dcm_locked = adc1_dcm_locked If you make this change it should get rid of your error and allow you to use just adc0 or adc1 without needing both present. If you do make this change please feel free to issue a pull-request to sma-wideband and we'll merge it into the repo. Best, Rurik On 3/14/2013 12:33 PM, Ross Williamson wrote: Hi All, I'm starting to look into getting the ADC 1x5000-8 DMUX 1:2 to work on a roach 1. I'm just posting a couple of comments here that I've uncovered so far - I think most of these stem from the fact that a lot of work has gone into developing the 1:1 demux with 2 cards for the sma-wideband project and ROACH-2. Notes: 1) I'm using the git repo from the sma-wideband project - If I should be looking elsewhere then let me know. 2) The 1:1 version uses the Xilinx FIFO IP core where as the 1:2 does not - This causes the 1:2 to not compile 3) If you hack to remove the FIFO ports from the system.mhs (bad idea) then you quickly notice that the opb_adc5g_controller has ports for the FIFO and also for 2 adc's - i.e. I don't think it will compile if you only have adc0 and not adc1 - error is adc1_dcm_locked - port is driven by a sourceless connector 4) I'm going to look at the ROACH-2 implementation as that might help a lot but I haven't got to it yet. Anyone know of a quick fix before I delve into the vhdl - different repo/earlier version? I know most people are pushing ahead with the 1:1 on the ROACH-2 with this board and so I'm happy looking into these issues but if anyone has some quick good ideas it would be great to hear them. Cheers Ross -- Ross Williamson Research Scientist - Sub-mm Group California Institute of Technology 626-395-2647 (office) 312-504-3051 (Cell)
Re: [casper] ADC 1x5000-8 Dux 1:2 Notes
Hi Rurik, Thanks - this is really useful. I've started delving into the datasheets - head hurts a little - it took me far to long to work out why we can only do 4-bits in 1:2 mode (number of pins! on ZDOK). This is making me wonder why the adc_bit_width in the 1:2 version is 8 and not 4? Also the ROACH2 version of the 1:2 doesn't have the FIFO in (although I have no idea why anyone would use the 1:2 on a ROACH2) I'll keep you updated Best regards, Ross On Thu, Mar 14, 2013 at 4:14 PM, Rurik A Primiani rprim...@cfa.harvard.edu wrote: Hi Ross, I developed a large part of the 5GSps ADC yellow block(s) in the sma-wideband repository using previous code kindly provided by Homin Jiang and Kim Guzzino. Unfortunately, as Jonathan mentioned in a previous email, we basically left the ROACH1, 1:2 DMUX yellow block behind when we realized we weren't going to use it. In its present state it's basically broken. I would suggest getting it up to date by bringing in the clock-domain crossing FIFO that was added into the other blocks. If I remember correctly this was the last feature left when I stopped developing that particular block. You should be able to copy the FIFO-related VHDL code and the FIFO netlist over from the 1:1, just make sure to adjust the MPD, PAO, etc as needed. Using the ROACH2, 1:2 block as a comparison is also a good idea. Basically the biggest difference between the two is that the R2 version uses a MMCM while the R1 version uses DCM/PLL. About the adc1_dcm_locked error you're receiving: this is a bug and I guess I forgot to fix it for ROACH1. If you look at line 203 in system.mhs, https://github.com/sma-wideband/mlib_devel/blob/master/xps_base/XPS_ROACH_base/system.mhs#L203, you'll notice that the conditional statement checks for the presence of adc0: #IF# (strcmp(get(b,'type'),'xps_adc5g')) get(b,'use_adc0')# PORT adc1_dcm_locked = adc1_dcm_locked This should actually read: #IF# (strcmp(get(b,'type'),'xps_adc5g')) get(b,'use_adc1')# PORT adc1_dcm_locked = adc1_dcm_locked If you make this change it should get rid of your error and allow you to use just adc0 or adc1 without needing both present. If you do make this change please feel free to issue a pull-request to sma-wideband and we'll merge it into the repo. Best, Rurik On 3/14/2013 12:33 PM, Ross Williamson wrote: Hi All, I'm starting to look into getting the ADC 1x5000-8 DMUX 1:2 to work on a roach 1. I'm just posting a couple of comments here that I've uncovered so far - I think most of these stem from the fact that a lot of work has gone into developing the 1:1 demux with 2 cards for the sma-wideband project and ROACH-2. Notes: 1) I'm using the git repo from the sma-wideband project - If I should be looking elsewhere then let me know. 2) The 1:1 version uses the Xilinx FIFO IP core where as the 1:2 does not - This causes the 1:2 to not compile 3) If you hack to remove the FIFO ports from the system.mhs (bad idea) then you quickly notice that the opb_adc5g_controller has ports for the FIFO and also for 2 adc's - i.e. I don't think it will compile if you only have adc0 and not adc1 - error is adc1_dcm_locked - port is driven by a sourceless connector 4) I'm going to look at the ROACH-2 implementation as that might help a lot but I haven't got to it yet. Anyone know of a quick fix before I delve into the vhdl - different repo/earlier version? I know most people are pushing ahead with the 1:1 on the ROACH-2 with this board and so I'm happy looking into these issues but if anyone has some quick good ideas it would be great to hear them. Cheers Ross -- Ross Williamson Research Scientist - Sub-mm Group California Institute of Technology 626-395-2647 (office) 312-504-3051 (Cell)
[casper] ADC 1x5000-8 Dux 1:2 Notes
Hi All, I'm starting to look into getting the ADC 1x5000-8 DMUX 1:2 to work on a roach 1. I'm just posting a couple of comments here that I've uncovered so far - I think most of these stem from the fact that a lot of work has gone into developing the 1:1 demux with 2 cards for the sma-wideband project and ROACH-2. Notes: 1) I'm using the git repo from the sma-wideband project - If I should be looking elsewhere then let me know. 2) The 1:1 version uses the Xilinx FIFO IP core where as the 1:2 does not - This causes the 1:2 to not compile 3) If you hack to remove the FIFO ports from the system.mhs (bad idea) then you quickly notice that the opb_adc5g_controller has ports for the FIFO and also for 2 adc's - i.e. I don't think it will compile if you only have adc0 and not adc1 - error is adc1_dcm_locked - port is driven by a sourceless connector 4) I'm going to look at the ROACH-2 implementation as that might help a lot but I haven't got to it yet. Anyone know of a quick fix before I delve into the vhdl - different repo/earlier version? I know most people are pushing ahead with the 1:1 on the ROACH-2 with this board and so I'm happy looking into these issues but if anyone has some quick good ideas it would be great to hear them. Cheers Ross -- Ross Williamson Research Scientist - Sub-mm Group California Institute of Technology 626-395-2647 (office) 312-504-3051 (Cell)
Re: [casper] ADC 1x5000-8 1:2 boards
Hi Homin, Thanks - My understanding is that we can not achieve 5 GSPS 8bits on a ROACH-1 - we need a ROACH-2 for that. We gain a lot more in our correlator design by having a larger bandwidth than number of bits - We may be able to push it up the 1:1 to about 3.6 GSPS which would be ok but we can do better with the 1:2 Best regards, Ross On Tue, Mar 12, 2013 at 5:12 AM, Homin Jiang ho...@asiaa.sinica.edu.tw wrote: Dear Ross: I will check our inventory. I guess we still have some. I am interested to know why not 1:1 ? cheers homin -- Ross Williamson Research Scientist - Sub-mm Group California Institute of Technology 626-395-2647 (office) 312-504-3051 (Cell)
Re: [casper] ADC1X5000-8 correlator question
Hi Jonathan, Thank you for the detailed response (which I read after replying to Homin - doh). We already have our ROACH-1 here and are trying to keep costs down so I'm going to push ahead a little more with trying to figure out if we can get this to work with a ROACH-1 and 1:2 ADCs. I do have a couple of questions/points though before I ask to borrow the 1:2 boards. 1) The nominal plan would be to run 2 channels at 5GSa/s, 4bit on a ROACH-1- i.e. using 2 ADC boards. My understanding is the the ROACH-1 in practice should be ok to do this (depending on number of channels etc in the PFB) 2) Am I being very naive (I suspect I am) in thinking that with some work (but not a total rewrite) I could just take the correlator tutorial, replace the ADC and with the yellow block for the 1x5000-8 boards and tweek the number of channels in the PFB (we don't need many at all which should help fitting on the VIRTEX 5). If 1+2 are within the bounds of sanity then it might be worth trying to see if we can get this up and running - We can always fall back to the 3.6 GS/s if it's proving to be a nightmare. I'll check out the memo and website too. Cheers, Ross On Tue, Mar 12, 2013 at 7:37 AM, Jonathan Weintroub jweintr...@cfa.harvard.edu wrote: Hi Ross, I am commenting this older thread prompted by your most recent message re DMUX1:2 ADCs, to which Homin responded today. Your approach, and the advice received from Dan and Glenn, is sound---in principal. With suitable bit codes, you can run DMUX1:2 4-bit versions of the ASIAA ADC at full rate, in dual channel 2.5 GSa/s mode, hosted on a ROACH1. And with two ADC boards installed you can enable four such 2.5 GSa/s input channels on ROACH1. Whether the ROACH1 can process the four channels with Virtex 5 resources of course depends on what you want to do, Dan gave one benchmark. We have a PFB resource utilization memo which may be able to help you. There is a caveat, however: my group is among a few CASPER collaborators who are doing wideband correlator design using ASIAA 5 GSa/s ADCs. We decided some time ago to standardize on using the 8-bit DMUX 1:1 version of the ADC supported by ROACH2. In our case we without question needed the computational resources of Virtex6-SX475, so the higher GPIO interface speed (translates to Z-DOK speed) in some sense came for free. Though we could probably meet our requirements with fewer than 8-bits, there was no penalty for enabling them by using the DMUX1:1 board. A consequence of this is that all our developments and contributions to the CASPER open source infrastructure support this configuration (8-bit and ROACH2). In brief we have contributed yellow block work, ADC characterization, and resource calculations for PFBs. Now, we are not the only ones doing this kind of work, and much of what we do is probably transferable to the ROACH1 and 4-bit case. However, at least from my biased perspective, you may find the ROACH2 8-but case to be better supported, and thus the hardware cost savings through using ROACH1 may prove to be false economy. The 4-bit and 8-bit ADCs are equal in cost. (By the way the 8-bit ADC board can be used on ROACH1 but you would be limited to 1.8 GSa/s per channel or 3.6 GSa/s per ADC board.) All that said, I have a few DMUX1:2 ADCs sitting in the lab fully assembled, working, and unused, and I would be happy to loan these to you. Actually they probably belong to Homin / ASIAA, so I guess subject to his ok. Our wideband developments are documented on a public Wiki: https://www.cfa.harvard.edu/twiki/bin/view/SMAwideband Dig down for ADC characterization and our resource memo. Cheers, stay in touch. Jonathan Weintroub CfA +1-617-495-7319 On Feb 12, 2013, at 4:09 PM, Ross Williamson wrote: Hi Dan and Glenn, All sounds good - I think have the ROACH-1 design will help us out a lot here to get started. We really don't need a very high spectral response as we are just trying to measure the amplitude and phase of a PSFs wings referenced to the central core of the PSF. Cheers, Ross On Tue, Feb 12, 2013 at 1:05 PM, G Jones glenn.calt...@gmail.com wrote: Note that the design Dan is referring to currently has only been tested to ~1.5 GHz BW. Getting to higher bandwidths will likely require some work to meet timing. Also the data comes out over 10 gigabit Ethernet so requires something to catch the data. On Tue, Feb 12, 2013 at 4:02 PM, Dan Werthimer d...@ssl.berkeley.edu wrote: hi ross, how many frequency channels do you need in your two input correlator? we have a full stokes VEGAS 1K channel spectrometer design that uses a pair of ADC08-5000's. (a full stokes spectrometer is the same thing as a two input correlator) our current design is for roach2, but we had tested working designs for roach1 last year, and we can probably dig these up. best wishes, dan On Tue, Feb 12, 2013
[casper] Errors compiling pfb_fir_real
Dear all, I'm getting the following error when compiling any tutorial that uses the pfb_fir_real function block. Error evaluating parameter 'initVector' in 'tut3/pfb_fir_real/pol1_in1_coeffs/ROM1' I'm running the ska-sa branch on ISE 14.4 https://github.com/ska-sa/mlib_devel.git Anybody seen this error and know how to fix it? I'm investigating at the moment. Ross -- Ross Williamson Research Scientist - Sub-mm Group California Institute of Technology 626-395-2647 (office) 312-504-3051 (Cell)
Re: [casper] Errors compiling pfb_fir_real
Hi Glenn, Thanks - That fixed that issue but there are a couple more now coming up. I'm just assuming that the tutorials are old compared to the ska branch and that I'm probably going to have to re-implement them. Good way to learn I guess R On Thu, Mar 7, 2013 at 4:19 PM, G Jones glenn.calt...@gmail.com wrote: There was a recent change to the pfb inner workings that makes it incompatible with previous models. Drag a new pfb block into the model and set the parameters to those of thee existing block and it should fix it. On Mar 7, 2013 7:12 PM, Ross Williamson rwilliam...@astro.caltech.edu wrote: Dear all, I'm getting the following error when compiling any tutorial that uses the pfb_fir_real function block. Error evaluating parameter 'initVector' in 'tut3/pfb_fir_real/pol1_in1_coeffs/ROM1' I'm running the ska-sa branch on ISE 14.4 https://github.com/ska-sa/mlib_devel.git Anybody seen this error and know how to fix it? I'm investigating at the moment. Ross -- Ross Williamson Research Scientist - Sub-mm Group California Institute of Technology 626-395-2647 (office) 312-504-3051 (Cell) -- Ross Williamson Research Scientist - Sub-mm Group California Institute of Technology 626-395-2647 (office) 312-504-3051 (Cell)
[casper] ADC1X5000-8 correlator question
Hi All, I'm new to CASPER/ROACH boards and so apologies if this is obvious. We are hoping to build a simple 2-channel correlator with a fairly high bandwidth. We are in the process of ordering a ROACH-1 board and I was thinking of also purchasing the ADC1X5000-8 ADC - A few questions: 1) Should I even be looking at an ADC1X5000-8 for use as a correlator? 2) I believe I need the DMUX 1:2 version to work with ROACH-1 board - is that correct? 3) I should be able to run 2 channels at 2.5GHz 4bits with a single board - correct? 4) If I wanted to could I purchase another ADC1X5000-8 and try and run with 5GHz bandwidth on each channel using the ROACH-1? Best regards, Ross -- Ross Williamson Research Scientist - Sub-mm Group California Institute of Technology 626-395-2647 (office) 312-504-3051 (Cell)
Re: [casper] ADC1X5000-8 correlator question
Hi Glenn, Thanks, I was being a tad blase regarding Nyquist/sampling rates. I think if we can operate at 2.5GHz BW on each channel using the ROACH-I then we should be fine - at least as a good proof of concept. Ross On Tue, Feb 12, 2013 at 12:58 PM, G Jones glenn.calt...@gmail.com wrote: Hi Ross, One point to clarify, the 5000 refers to the samping rate, not the total bandwidth. So a single ADC1X5000 demux 1:2 will give you 5000 Msps at 4 bits per sample, allowing you to sample signals up to 2.5 GHz bandwidth. With a single board, you'd need to put the board in the mode that instead acts as two ADCs each providing 2500 Msps at 4 bits per sample, hence you'd be able to correlate two signals each of up to 1.25 GHz bandwidth. With two ADC cards, you could correlate two 2.5 GHz BW signals. Glenn On Tue, Feb 12, 2013 at 3:53 PM, Ross Williamson rwilliam...@astro.caltech.edu wrote: Hi All, I'm new to CASPER/ROACH boards and so apologies if this is obvious. We are hoping to build a simple 2-channel correlator with a fairly high bandwidth. We are in the process of ordering a ROACH-1 board and I was thinking of also purchasing the ADC1X5000-8 ADC - A few questions: 1) Should I even be looking at an ADC1X5000-8 for use as a correlator? 2) I believe I need the DMUX 1:2 version to work with ROACH-1 board - is that correct? 3) I should be able to run 2 channels at 2.5GHz 4bits with a single board - correct? 4) If I wanted to could I purchase another ADC1X5000-8 and try and run with 5GHz bandwidth on each channel using the ROACH-1? Best regards, Ross -- Ross Williamson Research Scientist - Sub-mm Group California Institute of Technology 626-395-2647 (office) 312-504-3051 (Cell) -- Ross Williamson Research Scientist - Sub-mm Group California Institute of Technology 626-395-2647 (office) 312-504-3051 (Cell)
