Re: [casper] One input FFT block [ROACH2]
Thanks, It worked! Franco On Mon, Jan 6, 2020 at 4:47 AM Adam Isaacson wrote: > Hi Franco, > > I sent you an invite to join slack casper-astro.slack.com. I hope it > works. Let me know. > > Kind regards, > > Adam Isaacson > South African Radio Astronomy Observatory (SARAO) > Hardware Manager > Cell: (+27) 825639602 > Tel: (+27) 215067300 > email: aisaac...@ska.ac.za > > > > On Mon, Dec 30, 2019 at 8:30 PM Franco wrote: > >> Hi Dan, >> >> I was unaware that the compiler was able to remove unused logic, that's >> pretty useful. >> What I need is one real input to one complex output, so I'll check Nitish >> model and import it to ROACH2 if I need to, thanks for the info. >> >> On a sidenote: It is possible still to join the slack? I remember >> something was mentioned about sending an email earlier this year. >> >> Thanks, >> >> Franco >> >> On Mon, Dec 30, 2019 at 3:10 PM Dan Werthimer >> wrote: >> >>> >>> hi franco, >>> >>> are you looking for an FFT with a real input and complex output? >>> >>> you mentioned you are connected the unused inputs of the the >>> biplex_real-4x to ground. >>> this is useful, as the compiler should remove all the unused parts of >>> the FFT, >>> although it's probably not as resource efficient as a dedicated single >>> input real to complex FFT. >>> >>> if you need further reduction in resources, >>> nitish recently developed a single stream complex to complex fft. >>> nitish's posting on casper's snap slack channel is appended below . >>> >>> you could modify nitish's design to compute two reals in one complex >>> FFT, >>> or a single real of N points in an N/2 complex FFT. >>> >>> best wishes, >>> >>> dan >>> >>> -- >>> new messages >>> Nitish <https://app.slack.com/team/UMWDNQD7W> 10:54 PM >>> <https://casper-astro.slack.com/archives/CMNK6V19Q/p1576911266004700> >>> Hi, in reference to our previous discussion concerning the complex FFT >>> of a single stream of samples, we wanted to share the piece of the design >>> which worked, might prove useful to someone. So, we clock the SNAP at 250 >>> MHz and ADC is done at 250 MSps, thus one sample per clock cycle. We wished >>> to perform complex FFT, which would require a block taking 1 stream at 1 >>> sample per clock. The blocks available could only take powers of 2 samples >>> in parallel from a given stream, thus we had to find another way. Thanks to >>> Jack Hickish, we managed to make a small design with the FFT internal >>> blocks which performs the job. Please find attached. Channels 1 and 2 are >>> two separate streams (two distinct signals) coming from the mixer and they >>> contain 1 complex sample per clock cycle. The example shows a 2048 points >>> FFT. The unscrambler block is needed to put some order in the frequency >>> channels output. The channels from any one output have to be put in order >>> using this small code for example: >>> >>> for i in range(0, 1024): >>> spectrum1.append(channels1[i]) >>> spectrum1.append(channels1[2047 - i]) >>> >>> (edited) >>> Single_stream_complex_FFT.jpg >>> [image: Single_stream_complex_FFT.jpg] >>> >>> <https://files.slack.com/files-pri/THU1J9JDC-FRYDQAY5S/single_stream_complex_fft.jpg> >>> >>> >>> >>> >>> >>> On Mon, Dec 30, 2019 at 9:31 AM Franco wrote: >>> >>>> Hello everyone, >>>> >>>> Is there an FFT block in the CASPER library (ROACH2) that can be used >>>> as 1 input -> 1 output? The closest thing I've found is the 'fft' block >>>> which has a minimum of 2 inputs. >>>> >>>> For now I'm using the fft_biplex_real-4x and zeroing 3 of the 4 inputs, >>>> but that's wasteful. I've also tried the Xilinx FFT block, but it has a >>>> strange problem where the noise floor increase considerably when injecting >>>> a tone at the middle point between two FFT bins. >>>> >>>> Thanks, >>>> >>>> Franco Curotto >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "casper@lists.berkeley.edu" group. >>>> To unsubscribe from this group and stop receiving emails f
Re: [casper] One input FFT block [ROACH2]
Hi Dan, I was unaware that the compiler was able to remove unused logic, that's pretty useful. What I need is one real input to one complex output, so I'll check Nitish model and import it to ROACH2 if I need to, thanks for the info. On a sidenote: It is possible still to join the slack? I remember something was mentioned about sending an email earlier this year. Thanks, Franco On Mon, Dec 30, 2019 at 3:10 PM Dan Werthimer wrote: > > hi franco, > > are you looking for an FFT with a real input and complex output? > > you mentioned you are connected the unused inputs of the the > biplex_real-4x to ground. > this is useful, as the compiler should remove all the unused parts of the > FFT, > although it's probably not as resource efficient as a dedicated single > input real to complex FFT. > > if you need further reduction in resources, > nitish recently developed a single stream complex to complex fft. > nitish's posting on casper's snap slack channel is appended below . > > you could modify nitish's design to compute two reals in one complex FFT, > or a single real of N points in an N/2 complex FFT. > > best wishes, > > dan > > -- > new messages > Nitish <https://app.slack.com/team/UMWDNQD7W> 10:54 PM > <https://casper-astro.slack.com/archives/CMNK6V19Q/p1576911266004700> > Hi, in reference to our previous discussion concerning the complex FFT of > a single stream of samples, we wanted to share the piece of the design > which worked, might prove useful to someone. So, we clock the SNAP at 250 > MHz and ADC is done at 250 MSps, thus one sample per clock cycle. We wished > to perform complex FFT, which would require a block taking 1 stream at 1 > sample per clock. The blocks available could only take powers of 2 samples > in parallel from a given stream, thus we had to find another way. Thanks to > Jack Hickish, we managed to make a small design with the FFT internal > blocks which performs the job. Please find attached. Channels 1 and 2 are > two separate streams (two distinct signals) coming from the mixer and they > contain 1 complex sample per clock cycle. The example shows a 2048 points > FFT. The unscrambler block is needed to put some order in the frequency > channels output. The channels from any one output have to be put in order > using this small code for example: > > for i in range(0, 1024): > spectrum1.append(channels1[i]) > spectrum1.append(channels1[2047 - i]) > > (edited) > Single_stream_complex_FFT.jpg > [image: Single_stream_complex_FFT.jpg] > > <https://files.slack.com/files-pri/THU1J9JDC-FRYDQAY5S/single_stream_complex_fft.jpg> > > > > > > On Mon, Dec 30, 2019 at 9:31 AM Franco wrote: > >> Hello everyone, >> >> Is there an FFT block in the CASPER library (ROACH2) that can be used as >> 1 input -> 1 output? The closest thing I've found is the 'fft' block which >> has a minimum of 2 inputs. >> >> For now I'm using the fft_biplex_real-4x and zeroing 3 of the 4 inputs, >> but that's wasteful. I've also tried the Xilinx FFT block, but it has a >> strange problem where the noise floor increase considerably when injecting >> a tone at the middle point between two FFT bins. >> >> Thanks, >> >> Franco Curotto >> >> -- >> You received this message because you are subscribed to the Google Groups >> "casper@lists.berkeley.edu" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to casper+unsubscr...@lists.berkeley.edu. >> To view this discussion on the web visit >> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CACBfcEnPcxk-k4oFTD__%2BVYkTsGTSc%2B85uiLqejdEUthdGXwLA%40mail.gmail.com >> <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CACBfcEnPcxk-k4oFTD__%2BVYkTsGTSc%2B85uiLqejdEUthdGXwLA%40mail.gmail.com?utm_medium=email_source=footer> >> . >> > -- > You received this message because you are subscribed to the Google Groups " > casper@lists.berkeley.edu" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to casper+unsubscr...@lists.berkeley.edu. > To view this discussion on the web visit > https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAGHS_vFeEcLgYhcYLfL8KuYM4%3DzcDkmk4yC%2BgWWqc%2BttDi40pA%40mail.gmail.com > <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAGHS_vFeEcLgYhcYLfL8KuYM4%3DzcDkmk4yC%2BgWWqc%2BttDi40pA%40mail.gmail.com?utm_medium=email_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "casper@lists.berkeley.edu" group. To unsubscribe from this group and stop receiving emails from it, send an email to casper+unsubscr...@lists.berkeley.edu. To view this discussion on the web visit https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CACBfcEn1O-RhKbRhpo2XDDgWhSpshQUadpMkq3KZ%3Dnstsgzwtw%40mail.gmail.com.
[casper] One input FFT block [ROACH2]
Hello everyone, Is there an FFT block in the CASPER library (ROACH2) that can be used as 1 input -> 1 output? The closest thing I've found is the 'fft' block which has a minimum of 2 inputs. For now I'm using the fft_biplex_real-4x and zeroing 3 of the 4 inputs, but that's wasteful. I've also tried the Xilinx FFT block, but it has a strange problem where the noise floor increase considerably when injecting a tone at the middle point between two FFT bins. Thanks, Franco Curotto -- You received this message because you are subscribed to the Google Groups "casper@lists.berkeley.edu" group. To unsubscribe from this group and stop receiving emails from it, send an email to casper+unsubscr...@lists.berkeley.edu. To view this discussion on the web visit https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CACBfcEnPcxk-k4oFTD__%2BVYkTsGTSc%2B85uiLqejdEUthdGXwLA%40mail.gmail.com.
Re: [casper] Use of xBlock for block scripting
Thanks Jack! I'll check the tutorial. Franco On Mon, Sep 2, 2019 at 12:23 PM Jack Hickish wrote: > Hi Franco, > > Here's an ancient tutorial - > https://casper.ssl.berkeley.edu/wiki/Tutorial_HDL_Black_Box > > The files referenced should be at > https://github.com/casper-astro/tutorials_devel/tree/b6147e29646741863b8eee9bf8366680beef2ae3/tut6 > > Cheers > Jack > > On Mon, 2 Sep 2019, 9:14 am Franco, wrote: > >> Hi all, >> >> Thanks you for your replies. I actually found the same problems David and >> Andrew mentioned. In bigger models there is a lot of line overlaid, and you >> don't have control over the block size. I didn't know about mdl2m, that is >> a big time saver! Because most of the time I was manually extracting the >> position of each block in my parametrized system. >> >> I'm also interested in the the 'black box' that Jack mentioned. Is there >> a tutorial or memo on the topic? I found this >> https://github.com/casper-astro/publications/blob/master/Memos/files/Black_box_memo.pdf >> but it seems to focus on creating black boxes from existing blocks. >> >> Thanks, >> >> Franco >> >> On Sat, Aug 31, 2019 at 2:25 AM Andrew Martens wrote: >> >>> To add to what Dave has said. I found that having no control over the >>> relative size and placement of the blocks when using xBlocks made it hard >>> to see what was happening, making the design write-only and hard to debug. >>> >>> Generating scipts can be tedious though. The mdl2m.m script in the >>> casper_library folder will grovel through a model and generate an >>> associated script which can help save time and effort in this regard. >>> >>> Regards >>> Andrew >>> >>> On Sat, 31 Aug 2019, 00:33 David MacMahon, wrote: >>> >>>> I could be wrong, but as I recall, the block diagrams created via >>>> xBlocks were (at least at the time) not very conducive to visualizing the >>>> structure of the diagrams (e.g. lots of lines/traces overlaid on top of >>>> each other). This was not a serious problem when everything worked as it >>>> should, but it was a nightmare when it didn't. >>>> >>>> Dave >>>> >>>> On Aug 30, 2019, at 15:21, Dan Werthimer wrote: >>>> >>>> >>>> >>>> i don't know much about xblocks, so can't add much to jack's comments, >>>> except: >>>> >>>> about a dozen years ago chris dick and others at xilinx recommended >>>> casper use xblocks, >>>> so hong chen tried it out, and ported several of the casper dsp blocks. >>>> i think it worked well, and hong chen liked xblocks, but it didn't >>>> catch on in the casper community. >>>> not sure why. >>>> >>>> best wishes, >>>> >>>> dan >>>> >>>> >>>> >>>> >>>> On Fri, Aug 30, 2019 at 1:39 PM Jack Hickish >>>> wrote: >>>> >>>>> Hi Franco, >>>>> >>>>> I don't think there's any reason not to use xblocks. Someone can >>>>> correct me if I'm wrong. >>>>> >>>>> Several years ago there was a quest to move the whole casper library >>>>> to xblocks -- https://github.com/casper-astro/xblocks_devel/ -- but it >>>>> never seemed to get traction and the original libraries won over. I >>>>> suspect had the project been more aggressive about just replacing the >>>>> casper libraries it would have caught on. >>>>> >>>>> Cheers >>>>> Jack >>>>> >>>>> On Thu, 29 Aug 2019 at 12:34, Franco wrote: >>>>> > >>>>> > Dear Casperites, >>>>> > >>>>> > I've recently been playing around with the creation of block >>>>> libraries and I found out about Xilinx's API for programmatic model >>>>> creation (xBlock). I find it particularly convenient because you don't >>>>> have >>>>> to explicitly position the blocks, as the software does all the >>>>> positioning >>>>> for you, and for what I tested the results are pretty nice. >>>>> > >>>>> > However when I checked in the CASPER library, only a few blocks are >>>>> created using xBlock, and moreover, some blocks where re-implemented from >>>>> xBlock to standard Matlab
Re: [casper] Use of xBlock for block scripting
Hi all, Thanks you for your replies. I actually found the same problems David and Andrew mentioned. In bigger models there is a lot of line overlaid, and you don't have control over the block size. I didn't know about mdl2m, that is a big time saver! Because most of the time I was manually extracting the position of each block in my parametrized system. I'm also interested in the the 'black box' that Jack mentioned. Is there a tutorial or memo on the topic? I found this https://github.com/casper-astro/publications/blob/master/Memos/files/Black_box_memo.pdf but it seems to focus on creating black boxes from existing blocks. Thanks, Franco On Sat, Aug 31, 2019 at 2:25 AM Andrew Martens wrote: > To add to what Dave has said. I found that having no control over the > relative size and placement of the blocks when using xBlocks made it hard > to see what was happening, making the design write-only and hard to debug. > > Generating scipts can be tedious though. The mdl2m.m script in the > casper_library folder will grovel through a model and generate an > associated script which can help save time and effort in this regard. > > Regards > Andrew > > On Sat, 31 Aug 2019, 00:33 David MacMahon, wrote: > >> I could be wrong, but as I recall, the block diagrams created via xBlocks >> were (at least at the time) not very conducive to visualizing the structure >> of the diagrams (e.g. lots of lines/traces overlaid on top of each other). >> This was not a serious problem when everything worked as it should, but it >> was a nightmare when it didn't. >> >> Dave >> >> On Aug 30, 2019, at 15:21, Dan Werthimer wrote: >> >> >> >> i don't know much about xblocks, so can't add much to jack's comments, >> except: >> >> about a dozen years ago chris dick and others at xilinx recommended >> casper use xblocks, >> so hong chen tried it out, and ported several of the casper dsp blocks. >> i think it worked well, and hong chen liked xblocks, but it didn't catch >> on in the casper community. >> not sure why. >> >> best wishes, >> >> dan >> >> >> >> >> On Fri, Aug 30, 2019 at 1:39 PM Jack Hickish >> wrote: >> >>> Hi Franco, >>> >>> I don't think there's any reason not to use xblocks. Someone can >>> correct me if I'm wrong. >>> >>> Several years ago there was a quest to move the whole casper library >>> to xblocks -- https://github.com/casper-astro/xblocks_devel/ -- but it >>> never seemed to get traction and the original libraries won over. I >>> suspect had the project been more aggressive about just replacing the >>> casper libraries it would have caught on. >>> >>> Cheers >>> Jack >>> >>> On Thu, 29 Aug 2019 at 12:34, Franco wrote: >>> > >>> > Dear Casperites, >>> > >>> > I've recently been playing around with the creation of block libraries >>> and I found out about Xilinx's API for programmatic model creation >>> (xBlock). I find it particularly convenient because you don't have to >>> explicitly position the blocks, as the software does all the positioning >>> for you, and for what I tested the results are pretty nice. >>> > >>> > However when I checked in the CASPER library, only a few blocks are >>> created using xBlock, and moreover, some blocks where re-implemented from >>> xBlock to standard Matlab block scripting. >>> > >>> > So my question is: is there any reason why I should avoid using >>> xBlock? The only inconvenient I have had with it for now is that you have >>> to install some additional libraries in Linux to make it work, which I >>> didn't find it documented anywhere. >>> > >>> > Thanks, >>> > >>> > Franco Curotto >>> > >>> > -- >>> > You received this message because you are subscribed to the Google >>> Groups "casper@lists.berkeley.edu" group. >>> > To unsubscribe from this group and stop receiving emails from it, send >>> an email to casper+unsubscr...@lists.berkeley.edu. >>> > To view this discussion on the web visit >>> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CACBfcEmKHeDGr5ny5HH2ruqvHgYr-VbNbyyPjpJz5eR1C-JaRA%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 i
Re: [casper] Use of xBlock for block scripting
Hi Jack, I see. We actually found problems when trying to script xBlocks within an xBlock, we got some weird block connection error, but I guess that is something solvable with some debugging. We'll evaluate if we stay with xBlock scripting or we switch back to standard simulink scripting. Thanks for the info! Franco On Fri, Aug 30, 2019 at 4:39 PM Jack Hickish wrote: > Hi Franco, > > I don't think there's any reason not to use xblocks. Someone can > correct me if I'm wrong. > > Several years ago there was a quest to move the whole casper library > to xblocks -- https://github.com/casper-astro/xblocks_devel/ -- but it > never seemed to get traction and the original libraries won over. I > suspect had the project been more aggressive about just replacing the > casper libraries it would have caught on. > > Cheers > Jack > > On Thu, 29 Aug 2019 at 12:34, Franco wrote: > > > > Dear Casperites, > > > > I've recently been playing around with the creation of block libraries > and I found out about Xilinx's API for programmatic model creation > (xBlock). I find it particularly convenient because you don't have to > explicitly position the blocks, as the software does all the positioning > for you, and for what I tested the results are pretty nice. > > > > However when I checked in the CASPER library, only a few blocks are > created using xBlock, and moreover, some blocks where re-implemented from > xBlock to standard Matlab block scripting. > > > > So my question is: is there any reason why I should avoid using xBlock? > The only inconvenient I have had with it for now is that you have to > install some additional libraries in Linux to make it work, which I didn't > find it documented anywhere. > > > > Thanks, > > > > Franco Curotto > > > > -- > > You received this message because you are subscribed to the Google > Groups "casper@lists.berkeley.edu" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to casper+unsubscr...@lists.berkeley.edu. > > To view this discussion on the web visit > https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CACBfcEmKHeDGr5ny5HH2ruqvHgYr-VbNbyyPjpJz5eR1C-JaRA%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/CAG1GKSn%2Bgy-f4HFRXYsNAoheHDJxYA_EzFcXyxUgwnM_STxWtA%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/CACBfcEmHFEofvwv%3DqP1bvtaEdsx2hm-RKtXAFtEQ5vQ2ahsL3A%40mail.gmail.com.
[casper] Use of xBlock for block scripting
Dear Casperites, I've recently been playing around with the creation of block libraries and I found out about Xilinx's API for programmatic model creation (xBlock). I find it particularly convenient because you don't have to explicitly position the blocks, as the software does all the positioning for you, and for what I tested the results are pretty nice. However when I checked in the CASPER library, only a few blocks are created using xBlock, and moreover, some blocks where re-implemented from xBlock to standard Matlab block scripting. So my question is: is there any reason why I should avoid using xBlock? The only inconvenient I have had with it for now is that you have to install some additional libraries in Linux to make it work, which I didn't find it documented anywhere. Thanks, Franco Curotto -- You received this message because you are subscribed to the Google Groups "casper@lists.berkeley.edu" group. To unsubscribe from this group and stop receiving emails from it, send an email to casper+unsubscr...@lists.berkeley.edu. To view this discussion on the web visit https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CACBfcEmKHeDGr5ny5HH2ruqvHgYr-VbNbyyPjpJz5eR1C-JaRA%40mail.gmail.com.
Re: [casper] Deploy a CASPER Server
Just to report: x2go works very well! is almost as native display. thanks for the suggestion! Franco On Wed, Aug 7, 2019 at 2:13 PM Franco wrote: > Thanks Arash! X2go looks very good, I'll give it a try. > > Franco > > PD: Forgot to mention, to the whole community, looking forward to meeting > you next week! > > On Wed, Aug 7, 2019 at 1:11 PM Arash Roshanineshat < > aroshanines...@email.arizona.edu> wrote: > >> Hi Franco, >> >> We do have such a setup. We use X2go to have virtual desktops. >> https://wiki.x2go.org/doku.php/start >> >> You need to install x2go server on your sever and the clients (users) >> need to have x2go client. all information is provided in the link above. >> >> You have VNC option too but I believe X2go (which uses NX protocol) is >> faster. >> >> Arash >> >> On Wed, Aug 7, 2019 at 9:58 AM Franco wrote: >> >>> Dear community, >>> >>> I'm trying to deploy a 'CASPER server' in my lab, where multiple users >>> can connect to a local 'powerful' computer from other PCs for model design >>> and compilation. The idea is that many users can use the same computer >>> without interfering with themselves (ie teamviewer doesn't work). For now >>> simple 'ssh -X' works well in a wired connection, but the graphical part is >>> a bit slow (mostly zooming in and out). >>> >>> Does somebody have experience with this type of setups and can give me >>> some advice to improve the usability (either by configuring ssh, or using >>> another protocol)? >>> >>> Thanks, >>> >>> Franco >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "casper@lists.berkeley.edu" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to casper+unsubscr...@lists.berkeley.edu. >>> To view this discussion on the web visit >>> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CACBfcEkQ0w-xU0j6fQ0T3D_rOe2yDRzBYj%2Bvt6VhCxN-E0Xq%3Dw%40mail.gmail.com >>> <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CACBfcEkQ0w-xU0j6fQ0T3D_rOe2yDRzBYj%2Bvt6VhCxN-E0Xq%3Dw%40mail.gmail.com?utm_medium=email_source=footer> >>> . >>> >> >> >> -- >> 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 view this discussion on the web visit https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CACBfcEn_G_AUEiXoYVCD20homb685D29RYF8DJg_FUCFfbwDjw%40mail.gmail.com.
Re: [casper] Deploy a CASPER Server
Thanks Arash! X2go looks very good, I'll give it a try. Franco PD: Forgot to mention, to the whole community, looking forward to meeting you next week! On Wed, Aug 7, 2019 at 1:11 PM Arash Roshanineshat < aroshanines...@email.arizona.edu> wrote: > Hi Franco, > > We do have such a setup. We use X2go to have virtual desktops. > https://wiki.x2go.org/doku.php/start > > You need to install x2go server on your sever and the clients (users) need > to have x2go client. all information is provided in the link above. > > You have VNC option too but I believe X2go (which uses NX protocol) is > faster. > > Arash > > On Wed, Aug 7, 2019 at 9:58 AM Franco wrote: > >> Dear community, >> >> I'm trying to deploy a 'CASPER server' in my lab, where multiple users >> can connect to a local 'powerful' computer from other PCs for model design >> and compilation. The idea is that many users can use the same computer >> without interfering with themselves (ie teamviewer doesn't work). For now >> simple 'ssh -X' works well in a wired connection, but the graphical part is >> a bit slow (mostly zooming in and out). >> >> Does somebody have experience with this type of setups and can give me >> some advice to improve the usability (either by configuring ssh, or using >> another protocol)? >> >> Thanks, >> >> Franco >> >> -- >> You received this message because you are subscribed to the Google Groups >> "casper@lists.berkeley.edu" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to casper+unsubscr...@lists.berkeley.edu. >> To view this discussion on the web visit >> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CACBfcEkQ0w-xU0j6fQ0T3D_rOe2yDRzBYj%2Bvt6VhCxN-E0Xq%3Dw%40mail.gmail.com >> <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CACBfcEkQ0w-xU0j6fQ0T3D_rOe2yDRzBYj%2Bvt6VhCxN-E0Xq%3Dw%40mail.gmail.com?utm_medium=email_source=footer> >> . >> > > > -- > 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 view this discussion on the web visit https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CACBfcE%3DtwdRvdKfOnxr3pZUWVV9uugKF%2BxBH2PxtYcp8a5-CYQ%40mail.gmail.com.
[casper] Deploy a CASPER Server
Dear community, I'm trying to deploy a 'CASPER server' in my lab, where multiple users can connect to a local 'powerful' computer from other PCs for model design and compilation. The idea is that many users can use the same computer without interfering with themselves (ie teamviewer doesn't work). For now simple 'ssh -X' works well in a wired connection, but the graphical part is a bit slow (mostly zooming in and out). Does somebody have experience with this type of setups and can give me some advice to improve the usability (either by configuring ssh, or using another protocol)? Thanks, Franco -- You received this message because you are subscribed to the Google Groups "casper@lists.berkeley.edu" group. To unsubscribe from this group and stop receiving emails from it, send an email to casper+unsubscr...@lists.berkeley.edu. To view this discussion on the web visit https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CACBfcEkQ0w-xU0j6fQ0T3D_rOe2yDRzBYj%2Bvt6VhCxN-E0Xq%3Dw%40mail.gmail.com.
Re: [casper] Sharing papers related to CASPER
Thanks for the info Jack! I'll do just that. Franco On Fri, Jul 19, 2019 at 4:19 AM Jack Hickish wrote: > Hi Franco, > > That wiki page is pretty deprecated, I've redirected it to the > publications repository on github where we've been keeping > papers/memos -- https://github.com/casper-astro/publications. You're > very welcome to add your paper here via pull request, or by emailing > me a pdf. If your publication is in ADS include that link too for > Danny's library. > > On Fri, 19 Jul 2019 at 03:10, Danny Price wrote: > > > > Hi Franco, > > > > I have been keeping an ADS library of CASPER instrument papers: > > https://ui.adsabs.harvard.edu/public-libraries/7mm5XbqlRiW5FN-Si0l7oA > > > > Happy to add your papers to it! (And anyone else reading who has a paper > -- just send me an email with links to your ADS entries). > > > > Cheers, > > Danny > > > > On 19 July 2019 at 9:41:22 am, Franco (francocuro...@gmail.com) wrote: > > > > Dear CASPERites, > > > > Is there a place where research (papers) related to CASPER hardware > design/programming is curated? We, as the digital design group of the > University of Chile, would like to add our research output to that place if > exists. The only thing I could find was the paper list of the CASPER > website (https://casper.ssl.berkeley.edu/wiki/Papers), but I'm not sure > if it is still active, and open to the whole community. > > > > Regards, > > > > Franco Curotto > > -- > > You received this message because you are subscribed to the Google > Groups "casper@lists.berkeley.edu" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to casper+unsubscr...@lists.berkeley.edu. > > To view this discussion on the web visit > https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CACBfcEn43qjhF-6PTki22ZPkd0wvz8RN36u%3D2QEg6YiwYdjMVw%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/CAAtMgq%3Dyk8%2Bg4M79yAWgXF8r4QrKP7hjPKCyg-Datx92e4avdg%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/CACBfcEmyEtbUWPLbp8d0CsJ-zyLoQB2oHKL6tFBkRgD3_uSJXg%40mail.gmail.com.
[casper] Sharing papers related to CASPER
Dear CASPERites, Is there a place where research (papers) related to CASPER hardware design/programming is curated? We, as the digital design group of the University of Chile, would like to add our research output to that place if exists. The only thing I could find was the paper list of the CASPER website (https://casper.ssl.berkeley.edu/wiki/Papers), but I'm not sure if it is still active, and open to the whole community. Regards, Franco Curotto -- You received this message because you are subscribed to the Google Groups "casper@lists.berkeley.edu" group. To unsubscribe from this group and stop receiving emails from it, send an email to casper+unsubscr...@lists.berkeley.edu. To view this discussion on the web visit https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CACBfcEn43qjhF-6PTki22ZPkd0wvz8RN36u%3D2QEg6YiwYdjMVw%40mail.gmail.com.
Re: [EXTERNAL] [casper] JAI Special Issue in RFI
I didn't know about that publication! I recently finished my master thesis in an RFI mitigation technique, and I would have submitted something. Very cool regardless. Franco On Mon, Jun 10, 2019 at 5:34 PM 'Jarnot, Robert F (386A)' via casper@lists.berkeley.edu wrote: > Jonathon, > > >It looks like the issue contains many really good articles. > > > Robert > > > -- > *From:* Jonathon Kocz > *Sent:* Monday, June 10, 2019 2:29:38 PM > *To:* casper@lists.berkeley.edu > *Subject:* [EXTERNAL] [casper] JAI Special Issue in RFI > > Hi All, > > Just in case there is interest, the JAI special issue in radio frequency > interference mitigation in radio astronomy has now been published. > > Attached is the preface and author/paper list. - The issue itself can be > found online at: https://www.worldscientific.com/toc/jai/08/01 > > Thanks to those CASPERites who contributed! > > Cheers, > Jonathon > > -- > You received this message because you are subscribed to the Google Groups " > casper@lists.berkeley.edu" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to casper+unsubscr...@lists.berkeley.edu. > To post to this group, send email to casper@lists.berkeley.edu. > > -- > You received this message because you are subscribed to the Google Groups " > casper@lists.berkeley.edu" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to casper+unsubscr...@lists.berkeley.edu. > To post to this group, send email to casper@lists.berkeley.edu. > -- You received this message because you are subscribed to the Google Groups "casper@lists.berkeley.edu" group. To unsubscribe from this group and stop receiving emails from it, send an email to casper+unsubscr...@lists.berkeley.edu. To post to this group, send email to casper@lists.berkeley.edu.
Re: [casper] adc16x250-8 duplicated samples
Hi Jack, Thank you for the help. I tried the code, but I've got the same result, both for my model and the one from the CASPER page :(. Franco On Sun, Apr 7, 2019 at 6:58 AM Jack Hickish wrote: > Hi Franco, > > Can you try this software with the model you compiled? > https://github.com/jack-h/casper_adc16 . > > Cheers > Jack > > > On Fri, 5 Apr 2019 at 19:34, Franco wrote: > >> Hi Matt, >> >> I'm not sure what you mean by 'ADC IC test pattern'. I'm looking into >> using the ADC in the different demux modes by following this guide: >> https://casper.ssl.berkeley.edu/wiki/images/4/4c/ADC16_user_guide.txt >> >> For what I understand, I have to make a new model and change the "User IP >> clock Rate", and certain 'demux factor' parameter: >> >>> >>> For the ADC16 yellow block one must specify the "User IP Clock Rate" >>> as shown above *and demux factor in the XSG block*. "adc0_clk" must be >>> selected as the "User IP Clock Source". The demux factor is due to >>> how the Hittite ADC chip supplies the data to the FPGA as a function >>> of the number of analog inputs to sample. >> >> >> I don't have that option in my XSG block (and I find it weird that that >> option would be in that block). Was that parameter developed in a different >> branch of the mlib_devel library? >> >> Thanks, >> >> Franco >> >> On Thu, Apr 4, 2019 at 8:20 PM Matt Dexter wrote: >> >>> What happens when the ADC IC test pattern modes are used? >>> This includes the fixed value patterns. >>> >>> What happens when the higher bandwidth modes of >>> 2 channel/ADC IC and/or 1 channel/ADC IC are used ? >>> (as Dave has already warned, the correct clock rate for the mode >>> must be used) >>> >>> On Thu, 4 Apr 2019, Franco wrote: >>> >>> > Date: Thu, 4 Apr 2019 20:12:00 -0300 >>> > From: Franco >>> > Reply-To: casper@lists.berkeley.edu >>> > To: Casper Lists >>> > Subject: Re: [casper] adc16x250-8 duplicated samples >>> > >>> > Thanks for the info! I tried using the design from the CASPER page and >>> got the same results using the >>> > adc16_plot_chans.rb script. I even print (puts) the snapshot data to >>> verify it wasn't a visual effect of >>> > the plot, and effectively the data repeats every two samples. So now >>> I'm out of ideas. For now I think I >>> > can leave with the penalty of the error (in the end it just halves the >>> usable bandwidth), but I'm very >>> > interested if someone comes with a theory or a possible test to debug >>> the phenomenon. >>> > >>> > Franco >>> > >>> > On Wed, Apr 3, 2019 at 7:09 PM David MacMahon >>> wrote: >>> > The adc16 scripts that you are using will work with the >>> adc16_test design (all adc16 designs >>> > really). The adc16 yellow block includes built-in snapshot >>> functionality so all adc16 >>> > designs can get ADC snapshots using the built-in snapshot >>> functionality. The adc16_test >>> > design has an extra (much larger) snapshot block, but you don't >>> have to use it. >>> > HTH, >>> > Dave >>> > >>> > On Apr 3, 2019, at 14:27, Franco >>> wrote: >>> > >>> > Yes, it happens in the 16 inputs. Unfortunately, I don't have another >>> adc board. I have >>> > another ROACH2 but it is used for the moment. I'll try testing in the >>> other ROACH2 when it >>> > gets available. >>> > I notice that there is a sample compiled bof in: >>> > https://casper.ssl.berkeley.edu/wiki/ADC16x250-8_coax_rev_2 , maybe I >>> could try testing that >>> > model to see if it is a problem with my compilation tools, but I >>> haven't found the script >>> > that performs the data acquisition to the pc. Does such script exists? >>> > >>> > Thanks, >>> > >>> > Franco >>> > >>> > On Wed, Apr 3, 2019 at 4:52 PM David MacMahon >>> wrote: >>> > Does this symptom appear on all 16 inputs? Do you have another >>> adc16x250-8 card >>> > and/or another ROACH2 you could try instead? >>> > Dave >>> > >>> > On Apr 3, 2019, at 11:51, Franco >>> wrote: >>> > >&
Re: [casper] adc16x250-8 duplicated samples
Hi Matt, I'm not sure what you mean by 'ADC IC test pattern'. I'm looking into using the ADC in the different demux modes by following this guide: https://casper.ssl.berkeley.edu/wiki/images/4/4c/ADC16_user_guide.txt For what I understand, I have to make a new model and change the "User IP clock Rate", and certain 'demux factor' parameter: > > For the ADC16 yellow block one must specify the "User IP Clock Rate" > as shown above *and demux factor in the XSG block*. "adc0_clk" must be > selected as the "User IP Clock Source". The demux factor is due to > how the Hittite ADC chip supplies the data to the FPGA as a function > of the number of analog inputs to sample. I don't have that option in my XSG block (and I find it weird that that option would be in that block). Was that parameter developed in a different branch of the mlib_devel library? Thanks, Franco On Thu, Apr 4, 2019 at 8:20 PM Matt Dexter wrote: > What happens when the ADC IC test pattern modes are used? > This includes the fixed value patterns. > > What happens when the higher bandwidth modes of > 2 channel/ADC IC and/or 1 channel/ADC IC are used ? > (as Dave has already warned, the correct clock rate for the mode > must be used) > > On Thu, 4 Apr 2019, Franco wrote: > > > Date: Thu, 4 Apr 2019 20:12:00 -0300 > > From: Franco > > Reply-To: casper@lists.berkeley.edu > > To: Casper Lists > > Subject: Re: [casper] adc16x250-8 duplicated samples > > > > Thanks for the info! I tried using the design from the CASPER page and > got the same results using the > > adc16_plot_chans.rb script. I even print (puts) the snapshot data to > verify it wasn't a visual effect of > > the plot, and effectively the data repeats every two samples. So now I'm > out of ideas. For now I think I > > can leave with the penalty of the error (in the end it just halves the > usable bandwidth), but I'm very > > interested if someone comes with a theory or a possible test to debug > the phenomenon. > > > > Franco > > > > On Wed, Apr 3, 2019 at 7:09 PM David MacMahon > wrote: > > The adc16 scripts that you are using will work with the adc16_test > design (all adc16 designs > > really). The adc16 yellow block includes built-in snapshot > functionality so all adc16 > > designs can get ADC snapshots using the built-in snapshot > functionality. The adc16_test > > design has an extra (much larger) snapshot block, but you don't > have to use it. > > HTH, > > Dave > > > > On Apr 3, 2019, at 14:27, Franco wrote: > > > > Yes, it happens in the 16 inputs. Unfortunately, I don't have another > adc board. I have > > another ROACH2 but it is used for the moment. I'll try testing in the > other ROACH2 when it > > gets available. > > I notice that there is a sample compiled bof in: > > https://casper.ssl.berkeley.edu/wiki/ADC16x250-8_coax_rev_2 , maybe I > could try testing that > > model to see if it is a problem with my compilation tools, but I haven't > found the script > > that performs the data acquisition to the pc. Does such script exists? > > > > Thanks, > > > > Franco > > > > On Wed, Apr 3, 2019 at 4:52 PM David MacMahon > wrote: > > Does this symptom appear on all 16 inputs? Do you have another > adc16x250-8 card > > and/or another ROACH2 you could try instead? > > Dave > > > > On Apr 3, 2019, at 11:51, Franco wrote: > > > > Hi Jack, > > > > To answer your questions: > > - Yes I'm using the latest version of mlib_devel, roach2 branch. > > - No, the initialization script doesn't suggest any error. Here is the > script > > output: > > > > Connecting to 192.168.1.13... > > Programming 192.168.1.13 with adc16snap.bof.gz... > > Design built for ROACH2 rev2 with 4 ADCs (ZDOK rev2) > > Gateware supports demux modes (using demux by 1) > > Resetting ADC, power cycling ADC, and reprogramming FPGA... > > ZDOK0 clock OK > > Calibrating SERDES blocks...ABCD > > SERDES calibration successful. > > Selecting analog inputs... > > Using default digital gain of 1... > > Done! > > > > - I plotted the adc output with adc16_plot_chans.rb, and it seems to > present the > > same data duplication. Here is an image of the plot: > > > > > > - Yes, the User IP Clock is correctly set to adc0_clk. > > > > I also tried with a different model and a different clock rate > (200MHz/MSPS), and > > using the initialization code from here: > > http://w.astro.berkeley.edu/~davidm/gems/ and
Re: [casper] adc16x250-8 duplicated samples
Thanks for the info! I tried using the design from the CASPER page and got the same results using the adc16_plot_chans.rb script. I even print (puts) the snapshot data to verify it wasn't a visual effect of the plot, and effectively the data repeats every two samples. So now I'm out of ideas. For now I think I can leave with the penalty of the error (in the end it just halves the usable bandwidth), but I'm very interested if someone comes with a theory or a possible test to debug the phenomenon. Franco On Wed, Apr 3, 2019 at 7:09 PM David MacMahon wrote: > The adc16 scripts that you are using will work with the adc16_test design > (all adc16 designs really). The adc16 yellow block includes built-in > snapshot functionality so all adc16 designs can get ADC snapshots using the > built-in snapshot functionality. The adc16_test design has an extra (much > larger) snapshot block, but you don't have to use it. > > HTH, > Dave > > On Apr 3, 2019, at 14:27, Franco wrote: > > Yes, it happens in the 16 inputs. Unfortunately, I don't have another adc > board. I have another ROACH2 but it is used for the moment. I'll try > testing in the other ROACH2 when it gets available. > I notice that there is a sample compiled bof in: > https://casper.ssl.berkeley.edu/wiki/ADC16x250-8_coax_rev_2 , maybe I > could try testing that model to see if it is a problem with my compilation > tools, but I haven't found the script that performs the data acquisition to > the pc. Does such script exists? > > Thanks, > > Franco > > On Wed, Apr 3, 2019 at 4:52 PM David MacMahon wrote: > >> Does this symptom appear on all 16 inputs? Do you have another >> adc16x250-8 card and/or another ROACH2 you could try instead? >> >> Dave >> >> On Apr 3, 2019, at 11:51, Franco wrote: >> >> Hi Jack, >> >> To answer your questions: >> - Yes I'm using the latest version of mlib_devel, roach2 branch. >> - No, the initialization script doesn't suggest any error. Here is the >> script output: >> >> Connecting to 192.168.1.13... >> Programming 192.168.1.13 with adc16snap.bof.gz... >> Design built for ROACH2 rev2 with 4 ADCs (ZDOK rev2) >> Gateware supports demux modes (using demux by 1) >> Resetting ADC, power cycling ADC, and reprogramming FPGA... >> ZDOK0 clock OK >> Calibrating SERDES blocks...ABCD >> SERDES calibration successful. >> Selecting analog inputs... >> Using default digital gain of 1... >> Done! >> >> - I plotted the adc output with adc16_plot_chans.rb, and it seems to >> present the same data duplication. Here is an image of the plot: >> >> >> - Yes, the User IP Clock is correctly set to adc0_clk. >> >> I also tried with a different model and a different clock rate >> (200MHz/MSPS), and using the initialization code from here: >> http://w.astro.berkeley.edu/~davidm/gems/ and I had the same result. It >> seems the I stumbled into some mysterious behavior of the ADC board. Has >> anybody else experienced this behavior? >> >> Thanks, >> >> Franco >> >> >> On Wed, Apr 3, 2019 at 2:02 PM Jack Hickish >> wrote: >> >>> Hi Franco, >>> >>> Sorry, I missed your note in your first email where you already said you >>> used the ruby init code with demux 1. This is correct for the 16-input >>> configuration you are using. In this configuration, the FPGA and ADC should >>> both run at the same clock rate. >>> If you put in a 140MHz clock and est_brd_clk() returns ~140 that is a >>> good sign. >>> I assume you're using the latest roach2 branch on >>> github.com/casper-astro/mlib_devel? >>> Does the ruby initialization script suggest anything is wrong in the >>> initialization? >>> In the same repository as the adc16_init script, there is also a script >>> to plot adc outputs -- adc16_plot_chans.rb . Does this give the same sample >>> duplication you see in your snapshots? >>> I assume that the User IP Clock source in your design is correctly set >>> to adc0? (not user_clk/sys_clk?) >>> >>> >>> Thats all I can think to check right now... >>> >>> Good luck! >>> Jack >>> >>> On Wed, 3 Apr 2019 at 16:57, Franco wrote: >>> >>>> Hi David and Jack, >>>> >>>> Interesting. Yes I'm using a 140MHz clock (I'm injecting a 140MHz tone >>>> into the adc clock input). I'm sure the FPGA is running at 140MHz because I >>>> checked it with fpga.est_brd_clk(). Also, the data duplication occurs for >>>> all 16 input
Re: [casper] adc16x250-8 duplicated samples
Yes, it happens in the 16 inputs. Unfortunately, I don't have another adc board. I have another ROACH2 but it is used for the moment. I'll try testing in the other ROACH2 when it gets available. I notice that there is a sample compiled bof in: https://casper.ssl.berkeley.edu/wiki/ADC16x250-8_coax_rev_2 , maybe I could try testing that model to see if it is a problem with my compilation tools, but I haven't found the script that performs the data acquisition to the pc. Does such script exists? Thanks, Franco On Wed, Apr 3, 2019 at 4:52 PM David MacMahon wrote: > Does this symptom appear on all 16 inputs? Do you have another > adc16x250-8 card and/or another ROACH2 you could try instead? > > Dave > > On Apr 3, 2019, at 11:51, Franco wrote: > > Hi Jack, > > To answer your questions: > - Yes I'm using the latest version of mlib_devel, roach2 branch. > - No, the initialization script doesn't suggest any error. Here is the > script output: > > Connecting to 192.168.1.13... > Programming 192.168.1.13 with adc16snap.bof.gz... > Design built for ROACH2 rev2 with 4 ADCs (ZDOK rev2) > Gateware supports demux modes (using demux by 1) > Resetting ADC, power cycling ADC, and reprogramming FPGA... > ZDOK0 clock OK > Calibrating SERDES blocks...ABCD > SERDES calibration successful. > Selecting analog inputs... > Using default digital gain of 1... > Done! > > - I plotted the adc output with adc16_plot_chans.rb, and it seems to > present the same data duplication. Here is an image of the plot: > > > - Yes, the User IP Clock is correctly set to adc0_clk. > > I also tried with a different model and a different clock rate > (200MHz/MSPS), and using the initialization code from here: > http://w.astro.berkeley.edu/~davidm/gems/ and I had the same result. It > seems the I stumbled into some mysterious behavior of the ADC board. Has > anybody else experienced this behavior? > > Thanks, > > Franco > > > On Wed, Apr 3, 2019 at 2:02 PM Jack Hickish wrote: > >> Hi Franco, >> >> Sorry, I missed your note in your first email where you already said you >> used the ruby init code with demux 1. This is correct for the 16-input >> configuration you are using. In this configuration, the FPGA and ADC should >> both run at the same clock rate. >> If you put in a 140MHz clock and est_brd_clk() returns ~140 that is a >> good sign. >> I assume you're using the latest roach2 branch on >> github.com/casper-astro/mlib_devel? >> Does the ruby initialization script suggest anything is wrong in the >> initialization? >> In the same repository as the adc16_init script, there is also a script >> to plot adc outputs -- adc16_plot_chans.rb . Does this give the same sample >> duplication you see in your snapshots? >> I assume that the User IP Clock source in your design is correctly set to >> adc0? (not user_clk/sys_clk?) >> >> >> Thats all I can think to check right now... >> >> Good luck! >> Jack >> >> On Wed, 3 Apr 2019 at 16:57, Franco wrote: >> >>> Hi David and Jack, >>> >>> Interesting. Yes I'm using a 140MHz clock (I'm injecting a 140MHz tone >>> into the adc clock input). I'm sure the FPGA is running at 140MHz because I >>> checked it with fpga.est_brd_clk(). Also, the data duplication occurs for >>> all 16 inputs, so my guess is that is a problem at the adc board level. I'm >>> using the adc_init.rb code with the '--demux 1' flag (I understand that >>> this is the 16 in mode), however I copied this code from someone else, so >>> maybe is an old version. I'll try to use the latest version to see if that >>> is the problem. I'll also try a different (valid) sampling frequency. >>> >>> Thanks for the suggestions, >>> >>> Franco >>> >>> On Wed, Apr 3, 2019 at 9:07 AM Jack Hickish >>> wrote: >>> >>>> Hi Franco, >>>> >>>> In addition to Dave's advice-- how are you configuring your board? >>>> After programming the FPGA, you'll need to appropriately configure the ADC >>>> to operate in the right mode. The code seems to be linked here -- >>>> https://casper.ssl.berkeley.edu/wiki/ADC16x250-8_coax_rev_2 >>>> >>>> Cheers >>>> Jack >>>> >>>> On Wed, 3 Apr 2019 at 00:53, Franco wrote: >>>> >>>>> Hi Casperites, >>>>> >>>>> I'm working in some project that uses a ROACH2 and an adc16x250-8 ADC >>>>> board. When I check the raw data from the ADC using a snapshot block I see >>>>> this weird ef
Re: [casper] adc16x250-8 duplicated samples
Hi Jack, To answer your questions: - Yes I'm using the latest version of mlib_devel, roach2 branch. - No, the initialization script doesn't suggest any error. Here is the script output: Connecting to 192.168.1.13... Programming 192.168.1.13 with adc16snap.bof.gz... Design built for ROACH2 rev2 with 4 ADCs (ZDOK rev2) Gateware supports demux modes (using demux by 1) Resetting ADC, power cycling ADC, and reprogramming FPGA... ZDOK0 clock OK Calibrating SERDES blocks...ABCD SERDES calibration successful. Selecting analog inputs... Using default digital gain of 1... Done! - I plotted the adc output with adc16_plot_chans.rb, and it seems to present the same data duplication. Here is an image of the plot: [image: Screenshot from 2019-04-03 15-11-28.png] - Yes, the User IP Clock is correctly set to adc0_clk. I also tried with a different model and a different clock rate (200MHz/MSPS), and using the initialization code from here: http://w.astro.berkeley.edu/~davidm/gems/ and I had the same result. It seems the I stumbled into some mysterious behavior of the ADC board. Has anybody else experienced this behavior? Thanks, Franco On Wed, Apr 3, 2019 at 2:02 PM Jack Hickish wrote: > Hi Franco, > > Sorry, I missed your note in your first email where you already said you > used the ruby init code with demux 1. This is correct for the 16-input > configuration you are using. In this configuration, the FPGA and ADC should > both run at the same clock rate. > If you put in a 140MHz clock and est_brd_clk() returns ~140 that is a good > sign. > I assume you're using the latest roach2 branch on > github.com/casper-astro/mlib_devel? > Does the ruby initialization script suggest anything is wrong in the > initialization? > In the same repository as the adc16_init script, there is also a script to > plot adc outputs -- adc16_plot_chans.rb . Does this give the same sample > duplication you see in your snapshots? > I assume that the User IP Clock source in your design is correctly set to > adc0? (not user_clk/sys_clk?) > > > Thats all I can think to check right now... > > Good luck! > Jack > > On Wed, 3 Apr 2019 at 16:57, Franco wrote: > >> Hi David and Jack, >> >> Interesting. Yes I'm using a 140MHz clock (I'm injecting a 140MHz tone >> into the adc clock input). I'm sure the FPGA is running at 140MHz because I >> checked it with fpga.est_brd_clk(). Also, the data duplication occurs for >> all 16 inputs, so my guess is that is a problem at the adc board level. I'm >> using the adc_init.rb code with the '--demux 1' flag (I understand that >> this is the 16 in mode), however I copied this code from someone else, so >> maybe is an old version. I'll try to use the latest version to see if that >> is the problem. I'll also try a different (valid) sampling frequency. >> >> Thanks for the suggestions, >> >> Franco >> >> On Wed, Apr 3, 2019 at 9:07 AM Jack Hickish >> wrote: >> >>> Hi Franco, >>> >>> In addition to Dave's advice-- how are you configuring your board? After >>> programming the FPGA, you'll need to appropriately configure the ADC to >>> operate in the right mode. The code seems to be linked here -- >>> https://casper.ssl.berkeley.edu/wiki/ADC16x250-8_coax_rev_2 >>> >>> Cheers >>> Jack >>> >>> On Wed, 3 Apr 2019 at 00:53, Franco wrote: >>> >>>> Hi Casperites, >>>> >>>> I'm working in some project that uses a ROACH2 and an adc16x250-8 ADC >>>> board. When I check the raw data from the ADC using a snapshot block I see >>>> this weird effect where two consecutive samples have always the same value, >>>> as shown in this image: >>>> >>>> https://my.pcloud.com/publink/show?code=XZMRx67Zpj7XjnkE5PypVuuDCB9Mhu8IJJ37 >>>> >>>> According to an ex-coworker, this is the expected behavior of the >>>> adc16x250-8 board in 16 input mode, because of some constraints in the >>>> communication between the ADC and the FPGA, the FPGA must run at twice the >>>> speed to correctly receive the sampled data. However, couldn't find any >>>> explicit mention of this phenomenon in the CASPER website or mailing list. >>>> Can someone confirm this is the correct behavior so I can get peace of mind >>>> :)? >>>> >>>> Some info of my test: >>>> - Board: ROACH2-rev2 >>>> - ADC: ADC16x250-8 coax rev2 >>>> - ADC mode: 16 inputs (demux 1, using David Macmahon initalization code) >>>> - User IP Clock Rate: 140 MHz >>>> - Actual clock frequency used in the adc board: 140MHz >>&
Re: [casper] adc16x250-8 duplicated samples
Hi David and Jack, Interesting. Yes I'm using a 140MHz clock (I'm injecting a 140MHz tone into the adc clock input). I'm sure the FPGA is running at 140MHz because I checked it with fpga.est_brd_clk(). Also, the data duplication occurs for all 16 inputs, so my guess is that is a problem at the adc board level. I'm using the adc_init.rb code with the '--demux 1' flag (I understand that this is the 16 in mode), however I copied this code from someone else, so maybe is an old version. I'll try to use the latest version to see if that is the problem. I'll also try a different (valid) sampling frequency. Thanks for the suggestions, Franco On Wed, Apr 3, 2019 at 9:07 AM Jack Hickish wrote: > Hi Franco, > > In addition to Dave's advice-- how are you configuring your board? After > programming the FPGA, you'll need to appropriately configure the ADC to > operate in the right mode. The code seems to be linked here -- > https://casper.ssl.berkeley.edu/wiki/ADC16x250-8_coax_rev_2 > > Cheers > Jack > > On Wed, 3 Apr 2019 at 00:53, Franco wrote: > >> Hi Casperites, >> >> I'm working in some project that uses a ROACH2 and an adc16x250-8 ADC >> board. When I check the raw data from the ADC using a snapshot block I see >> this weird effect where two consecutive samples have always the same value, >> as shown in this image: >> >> https://my.pcloud.com/publink/show?code=XZMRx67Zpj7XjnkE5PypVuuDCB9Mhu8IJJ37 >> >> According to an ex-coworker, this is the expected behavior of the >> adc16x250-8 board in 16 input mode, because of some constraints in the >> communication between the ADC and the FPGA, the FPGA must run at twice the >> speed to correctly receive the sampled data. However, couldn't find any >> explicit mention of this phenomenon in the CASPER website or mailing list. >> Can someone confirm this is the correct behavior so I can get peace of mind >> :)? >> >> Some info of my test: >> - Board: ROACH2-rev2 >> - ADC: ADC16x250-8 coax rev2 >> - ADC mode: 16 inputs (demux 1, using David Macmahon initalization code) >> - User IP Clock Rate: 140 MHz >> - Actual clock frequency used in the adc board: 140MHz >> >> Thanks, >> >> Franco Curotto >> >> -- >> You received this message because you are subscribed to the Google Groups >> "casper@lists.berkeley.edu" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to casper+unsubscr...@lists.berkeley.edu. >> To post to this group, send email to casper@lists.berkeley.edu. >> > -- > You received this message because you are subscribed to the Google Groups " > casper@lists.berkeley.edu" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to casper+unsubscr...@lists.berkeley.edu. > To post to this group, send email to casper@lists.berkeley.edu. > -- You received this message because you are subscribed to the Google Groups "casper@lists.berkeley.edu" group. To unsubscribe from this group and stop receiving emails from it, send an email to casper+unsubscr...@lists.berkeley.edu. To post to this group, send email to casper@lists.berkeley.edu.
[casper] adc16x250-8 duplicated samples
Hi Casperites, I'm working in some project that uses a ROACH2 and an adc16x250-8 ADC board. When I check the raw data from the ADC using a snapshot block I see this weird effect where two consecutive samples have always the same value, as shown in this image: https://my.pcloud.com/publink/show?code=XZMRx67Zpj7XjnkE5PypVuuDCB9Mhu8IJJ37 According to an ex-coworker, this is the expected behavior of the adc16x250-8 board in 16 input mode, because of some constraints in the communication between the ADC and the FPGA, the FPGA must run at twice the speed to correctly receive the sampled data. However, couldn't find any explicit mention of this phenomenon in the CASPER website or mailing list. Can someone confirm this is the correct behavior so I can get peace of mind :)? Some info of my test: - Board: ROACH2-rev2 - ADC: ADC16x250-8 coax rev2 - ADC mode: 16 inputs (demux 1, using David Macmahon initalization code) - User IP Clock Rate: 140 MHz - Actual clock frequency used in the adc board: 140MHz Thanks, Franco Curotto -- You received this message because you are subscribed to the Google Groups "casper@lists.berkeley.edu" group. To unsubscribe from this group and stop receiving emails from it, send an email to casper+unsubscr...@lists.berkeley.edu. To post to this group, send email to casper@lists.berkeley.edu.
Re: [casper] Timestamp in ROACH2 and PTP
Hi David, Dan, Thanks for the explanation, my English failed me this time around (problems of a non-native speaker ¯\_(ツ)_/¯ ) Regards, Franco On Mon, Mar 11, 2019 at 1:19 PM Dan Werthimer wrote: > > hi franco, > > > i think we picked the word "arm" because it's similar to arming a gun, > getting it ready to fire, but not firing it. > > "arm" is not the signal that directly resets the elapsed time counter. > the arm signal is a software command that says: > on the next 1 PPS, the elapsed time counter should be reset. > > "arm" is a fpga register bit that is set by a software command, > perhaps at 23:59.59.5 (roughly 1/2 second before midnight). > > after the arm signal is set by the computer, then a very accurate external > 1 PPS pulse, > (perhaps from a gps disciplined time/frequency standard, accurate to a few > ns wrt to UTC) > resets the elapsed time counter. the elapsed time counter then is > embedded in the ethernet > packets with the spectral or voltage data, so that each packet is > accurately time stamped > to a few ns accuracy. > > best wishes, > > dan > > > > On Mon, Mar 11, 2019 at 7:37 AM Franco wrote: > >> Hi, >> >> Yes! Very clear. Thank you very much James, Jack and Dan. Just the last >> little question, why you call "ARM" the signal/register that resets the >> time-tracking counter? >> >> Thanks, >> >> Franco >> >> >> >> On Mon, Mar 11, 2019 at 4:27 AM James Smith wrote: >> >>> Hello Franco, >>> >>> Jack's email explained more explicitly what I tried to convey. Did it >>> make it clear? >>> >>> Regards, >>> James >>> >>> >>> On Sat, Mar 9, 2019 at 12:44 AM Jack Hickish >>> wrote: >>> >>>> Hi Franco, >>>> >>>> The general principle is generally this -- >>>> >>>> We assume that the system has >>>> 1. A CPU-based control computer (a laptop / desktop / posh server / >>>> whatever) which has a standard NTP client running. NTP allows this computer >>>> to know the time good to some number of milliseconds. >>>> 2. FPGAs in the system have an GPS pulse-per-second (PPS) input, which >>>> sends a pulse on each UTC second, good to 10s of nanoseconds. >>>> 3. Some firmware on your FPGAs which allows an arm signal to be >>>> generated by software, causing some internal counter to be generated from >>>> the next PPS pulse edge. >>>> >>>> You then do the following: >>>> >>>> On your control computer you sleep until a second boundary passes. Then >>>> you issue an arm of the FPGA boards. You don't know exactly when this arm >>>> arrives -- NTP isn't that accurate, and the latency of issuing an FPGA >>>> write is unknown -- this is why you can't use this signal alone for >>>> defining timing. But... you *do* know the next second boundary that will >>>> follow the arm. On this second, a PPS (which is good to <100us) triggers >>>> the reset of your FPGA's counter logic. You can then use this counter to >>>> indicate time in FPGA cycles since reset. Since you know the reset time, if >>>> you use this counter to stamp data packets you can figure out the time >>>> associated with the data in these packets. >>>> >>>> You can probably do something in python like: >>>> from time import * >>>> sleep(1 - (time() % 1)) # Sleep until the next second boundary >>>> sleep(0.1) # sleep until 100ms past this second >>>> my_fpga.arm() # Arm the sync generator logic >>>> arm_time = int(time()) + 1 # The next second tick will pass at this >>>> time and reset your boards >>>> # write the arm_time somewhere, so that when you get a packet >>>> timestamped with some counter, you can do >>>> # time_of_this_packet = arm_time + (counter_value / >>>> counter_ticks_per_second) >>>> >>>> Maybe that was helpful. Maybe it will add to your confusion. Probably >>>> the above pseudo code doesn't work in real life :) >>>> >>>> Cheers >>>> Jack >>>> >>>> On Fri, 8 Mar 2019 at 10:50, Franco wrote: >>>> >>>>> Hi James, >>>>> >>>>> Thank you for your answer. Yes, I use and ADC for data acquisition. I >>>>> understand the general idea of your system. What I don't understand is >>>>
Re: [casper] Timestamp in ROACH2 and PTP
Hi, Yes! Very clear. Thank you very much James, Jack and Dan. Just the last little question, why you call "ARM" the signal/register that resets the time-tracking counter? Thanks, Franco On Mon, Mar 11, 2019 at 4:27 AM James Smith wrote: > Hello Franco, > > Jack's email explained more explicitly what I tried to convey. Did it make > it clear? > > Regards, > James > > > On Sat, Mar 9, 2019 at 12:44 AM Jack Hickish > wrote: > >> Hi Franco, >> >> The general principle is generally this -- >> >> We assume that the system has >> 1. A CPU-based control computer (a laptop / desktop / posh server / >> whatever) which has a standard NTP client running. NTP allows this computer >> to know the time good to some number of milliseconds. >> 2. FPGAs in the system have an GPS pulse-per-second (PPS) input, which >> sends a pulse on each UTC second, good to 10s of nanoseconds. >> 3. Some firmware on your FPGAs which allows an arm signal to be generated >> by software, causing some internal counter to be generated from the next >> PPS pulse edge. >> >> You then do the following: >> >> On your control computer you sleep until a second boundary passes. Then >> you issue an arm of the FPGA boards. You don't know exactly when this arm >> arrives -- NTP isn't that accurate, and the latency of issuing an FPGA >> write is unknown -- this is why you can't use this signal alone for >> defining timing. But... you *do* know the next second boundary that will >> follow the arm. On this second, a PPS (which is good to <100us) triggers >> the reset of your FPGA's counter logic. You can then use this counter to >> indicate time in FPGA cycles since reset. Since you know the reset time, if >> you use this counter to stamp data packets you can figure out the time >> associated with the data in these packets. >> >> You can probably do something in python like: >> from time import * >> sleep(1 - (time() % 1)) # Sleep until the next second boundary >> sleep(0.1) # sleep until 100ms past this second >> my_fpga.arm() # Arm the sync generator logic >> arm_time = int(time()) + 1 # The next second tick will pass at this time >> and reset your boards >> # write the arm_time somewhere, so that when you get a packet timestamped >> with some counter, you can do >> # time_of_this_packet = arm_time + (counter_value / >> counter_ticks_per_second) >> >> Maybe that was helpful. Maybe it will add to your confusion. Probably the >> above pseudo code doesn't work in real life :) >> >> Cheers >> Jack >> >> On Fri, 8 Mar 2019 at 10:50, Franco wrote: >> >>> Hi James, >>> >>> Thank you for your answer. Yes, I use and ADC for data acquisition. I >>> understand the general idea of your system. What I don't understand is >>> where you get the start time of the ROACH2. Is generated by the TRF? Is >>> there a different system that initialize all the synchronized devices and >>> that record the start time? Sorry if it is basic question. >>> >>> Thanks, >>> >>> Franco >>> >>> On Thu, Mar 7, 2019 at 3:52 AM James Smith wrote: >>> >>>> Hello Franco, >>>> >>>> As I understand it, PTP wasn't terribly useful in our application >>>> (though I wasn't involved with this directly). You can probably sync the >>>> little Linux instance that runs on the ROACH2, but getting the time >>>> information onto your FPGA may prove somewhat tricky. >>>> >>>> Are you using an ADC card in the ROACH2? Or is the data digitised >>>> separately? >>>> >>>> What we've done with ROACH and ROACH2 designs in the past is more or >>>> less this: >>>> >>>>- FPGA's clock comes from a timing & frequency reference (TFR). >>>>- ROACH2 gets a 1PPS input from the same TFR. >>>>- In the FPGA logic there's a counter which is reset as part of the >>>>initialisation, and some logic that starts the counter going after a set >>>>number of 1PPS pulses (two to three, I forget exactly now). >>>>- The output of this counter is pipelined along with the data and >>>>then sent out as part of the SPEAD data on the 10GbE network. >>>> >>>> The idea here being that you know with a fairly high degree of >>>> precision which pulse your ROACH was initialised on. The counter that comes >>>> through on the SPEAD packet counts in FPGA clock cycles (or
Re: [casper] Timestamp in ROACH2 and PTP
Hi John, Thank you for the answer. I see, so reading the network packages directly from FPGA using the GBE core, would be the way to go if using PTP or NTP. Thanks, Franco On Thu, Mar 7, 2019 at 10:11 AM John Ford wrote: > Hi Franco. > > We have normally time-stamped the data using a hardware 1 Pulse per Second > digital input as a sync source, which gives us << 1 microsecond timing > precision. PTP requires hardware support in the LAN hardware, and I don't > recall for sure but I don't think it's in the PHY/MAC on the PPC, so the > direct answer to your question, I think, is no. But you probably need to > time-stamp the data in the FPGA anyway if you need really precise timing. > You could use an FPGA Ethernet core to handle the PTP chores. But I don't > think anyone has done that yet. The Xilinx tri-mode Ethernet core has PTP > support in it, but I don't know what core the 1G yellow block uses. > > > On Wed, Mar 6, 2019 at 10:41 AM Franco wrote: > >> Dear Casperiites, >> >> I was given the task of timestamping ROACH2 spectral data in a telescope >> that uses PTP (precision time protocol) as a synchronization protocol. I >> understand that ROACH's BORPH come preloaded with NTP (network time >> protocol) libraries/daemos, but PTP is preferred because is already in use >> in the telescope, and it achieves greater time precision. >> >> Does somebody know if it is feasible to compile/install PTP libraries in >> BORPH? >> >> Alternatively, we have though of sending the ROACH the current time >> through a GPIO pin using IRIG-B timecode standard. Has anybody done >> something similar in the past? >> >> Thanks, >> >> Franco >> >> -- >> You received this message because you are subscribed to the Google Groups >> "casper@lists.berkeley.edu" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to casper+unsubscr...@lists.berkeley.edu. >> To post to this group, send email to casper@lists.berkeley.edu. >> > -- > You received this message because you are subscribed to the Google Groups " > casper@lists.berkeley.edu" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to casper+unsubscr...@lists.berkeley.edu. > To post to this group, send email to casper@lists.berkeley.edu. > -- 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] Timestamp in ROACH2 and PTP
Hi James, Thank you for your answer. Yes, I use and ADC for data acquisition. I understand the general idea of your system. What I don't understand is where you get the start time of the ROACH2. Is generated by the TRF? Is there a different system that initialize all the synchronized devices and that record the start time? Sorry if it is basic question. Thanks, Franco On Thu, Mar 7, 2019 at 3:52 AM James Smith wrote: > Hello Franco, > > As I understand it, PTP wasn't terribly useful in our application (though > I wasn't involved with this directly). You can probably sync the little > Linux instance that runs on the ROACH2, but getting the time information > onto your FPGA may prove somewhat tricky. > > Are you using an ADC card in the ROACH2? Or is the data digitised > separately? > > What we've done with ROACH and ROACH2 designs in the past is more or less > this: > >- FPGA's clock comes from a timing & frequency reference (TFR). >- ROACH2 gets a 1PPS input from the same TFR. >- In the FPGA logic there's a counter which is reset as part of the >initialisation, and some logic that starts the counter going after a set >number of 1PPS pulses (two to three, I forget exactly now). >- The output of this counter is pipelined along with the data and then >sent out as part of the SPEAD data on the 10GbE network. > > The idea here being that you know with a fairly high degree of precision > which pulse your ROACH was initialised on. The counter that comes through > on the SPEAD packet counts in FPGA clock cycles (or multiples thereof, > perhaps you might want to count in spectra), and then you can use the start > time to calculate the timestamp of each packet (Unix time, MJD, whichever > your preferred reference is). > > Hope that helps. > > Regards, > James > > > On Wed, Mar 6, 2019 at 7:41 PM Franco wrote: > >> Dear Casperiites, >> >> I was given the task of timestamping ROACH2 spectral data in a telescope >> that uses PTP (precision time protocol) as a synchronization protocol. I >> understand that ROACH's BORPH come preloaded with NTP (network time >> protocol) libraries/daemos, but PTP is preferred because is already in use >> in the telescope, and it achieves greater time precision. >> >> Does somebody know if it is feasible to compile/install PTP libraries in >> BORPH? >> >> Alternatively, we have though of sending the ROACH the current time >> through a GPIO pin using IRIG-B timecode standard. Has anybody done >> something similar in the past? >> >> Thanks, >> >> Franco >> >> -- >> You received this message because you are subscribed to the Google Groups >> "casper@lists.berkeley.edu" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to casper+unsubscr...@lists.berkeley.edu. >> To post to this group, send email to casper@lists.berkeley.edu. >> > -- > You received this message because you are subscribed to the Google Groups " > casper@lists.berkeley.edu" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to casper+unsubscr...@lists.berkeley.edu. > To post to this group, send email to casper@lists.berkeley.edu. > -- 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] ROACH2 compile error
I'm not sure but did you make the modifications required post-installation: https://github.com/casper-astro/tutorials_devel/wiki#modifications-to-be-run-after-installs ? I remember having a similar error for not having the make -> gmake link. Franco On Tue, Mar 5, 2019 at 10:24 AM Heystek Grobler wrote: > Good day CASPERites > > I am trying to compile a deign for a ROACH2 but I get the following error: > > NGDBUILD Design Results Summary: > Number of errors: 2 > Number of warnings: 10272 > > Total REAL time to NGDBUILD completion: 2 min 48 sec > Total CPU time to NGDBUILD completion: 2 min 41 sec > > One or more errors were found during NGDBUILD. No NGD file will be > written. > > Writing NGDBUILD log file "system.bld"... > ERROR:Xflow - Program ngdbuild returned error code 2. 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 688) > XPS failed. > > Does anyone perhaps know how to fix it? > > Thanks for the help > > Heystek > > > > -- > 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] Timestamp in ROACH2 and PTP
Dear Casperiites, I was given the task of timestamping ROACH2 spectral data in a telescope that uses PTP (precision time protocol) as a synchronization protocol. I understand that ROACH's BORPH come preloaded with NTP (network time protocol) libraries/daemos, but PTP is preferred because is already in use in the telescope, and it achieves greater time precision. Does somebody know if it is feasible to compile/install PTP libraries in BORPH? Alternatively, we have though of sending the ROACH the current time through a GPIO pin using IRIG-B timecode standard. Has anybody done something similar in the past? Thanks, Franco -- You received this message because you are subscribed to the Google Groups "casper@lists.berkeley.edu" group. To unsubscribe from this group and stop receiving emails from it, send an email to casper+unsubscr...@lists.berkeley.edu. To post to this group, send email to casper@lists.berkeley.edu.
Re: [casper] Broken links to CASPER Memos
Nice, all memos seems to work now. Thanks! Franco On Mon, Jan 7, 2019 at 4:42 PM Jack Hickish wrote: > Hi Franco, > > Good catch, thanks -- try now. > > Cheers > > Jack > > On Mon, 7 Jan 2019 at 10:02 Franco wrote: > >> Hi all, >> >> I was searching for some memos in the CASPER wiki ( >> https://casper.ssl.berkeley.edu/wiki/Memos) and I noticed that some of >> the links are broken (they give me 404 Not Found Error). Here are some >> examples: >> >> https://casper.berkeley.edu/memos/sync_memo_v1.pdf >> https://casper.berkeley.edu/memos/cabletestmemo.pdf >> >> Were the memos migrated to other location/URL? >> >> Thanks, >> >> Franco Curotto >> >> -- >> You received this message because you are subscribed to the Google Groups >> "casper@lists.berkeley.edu" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to casper+unsubscr...@lists.berkeley.edu. >> To post to this group, send email to casper@lists.berkeley.edu. >> > -- > You received this message because you are subscribed to the Google Groups " > casper@lists.berkeley.edu" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to casper+unsubscr...@lists.berkeley.edu. > To post to this group, send email to casper@lists.berkeley.edu. > -- You received this message because you are subscribed to the Google Groups "casper@lists.berkeley.edu" group. To unsubscribe from this group and stop receiving emails from it, send an email to casper+unsubscr...@lists.berkeley.edu. To post to this group, send email to casper@lists.berkeley.edu.
[casper] Broken links to CASPER Memos
Hi all, I was searching for some memos in the CASPER wiki ( https://casper.ssl.berkeley.edu/wiki/Memos) and I noticed that some of the links are broken (they give me 404 Not Found Error). Here are some examples: https://casper.berkeley.edu/memos/sync_memo_v1.pdf https://casper.berkeley.edu/memos/cabletestmemo.pdf Were the memos migrated to other location/URL? Thanks, Franco Curotto -- You received this message because you are subscribed to the Google Groups "casper@lists.berkeley.edu" group. To unsubscribe from this group and stop receiving emails from it, send an email to casper+unsubscr...@lists.berkeley.edu. To post to this group, send email to casper@lists.berkeley.edu.
[casper] Getting a new ROACH2 board
Dear Casperites, I was assigned to get a new ROACH2 for the lab. Since this is the first time I have to do this I am unfamiliar with the process. What is the current method to purchase a ROACH2 board? Are complete ROACH2 boards in production or I have to assemble/build it myself? Regards, Franco Curotto Electrical Engineer Millimeter-Wave Laboratory University of Chile -- You received this message because you are subscribed to the Google Groups "casper@lists.berkeley.edu" group. To unsubscribe from this group and stop receiving emails from it, send an email to casper+unsubscr...@lists.berkeley.edu. To post to this group, send email to casper@lists.berkeley.edu.
Re: [casper] CASPER paper library on ADS
HI Danny, This is a bit late but I have some algorithms implemented in CASPER tools (ROACH ROACH2) to contribute: Digital sideband separation: https://arxiv.org/abs/1806.04053 https://arxiv.org/abs/1805.06389 RFI mitigation: https://arxiv.org/abs/1805.06376 Unfortunately they are all from arxiv, but I hope they are useful. Franco Curotto On Tue, Oct 23, 2018 at 12:43 AM Danny Price wrote: > Hi all, > > As I mentioned at the CASPER workshop, I’ve put together an ADS public > library papers that details CASPER instruments: > > https://ui.adsabs.harvard.edu/#/public-libraries/7mm5XbqlRiW5FN-Si0l7oA > > It would be fantastic to have a near-complete list of CASPER instrument > papers; if your paper is missing, can you please send me an ADS link to the > paper? For example, here is the CASPER overview paper from 2016: > https://ui.adsabs.harvard.edu/#abs/2016JAI…..541001H/abstract > > Papers on algorithm development using CASPER, library optimisations, etc, > are also welcome -- anything CASPER-related with a focus on instrumentation. > > Unfortunately there is no way to add papers that are not indexed by ADS at > the moment, but send those along too and we can figure out how to make them > accessible later. > > Regards, > > Danny > > -- > 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] Dealing with extreme RFI
Hi all, I know this is an old thread, but I wanted to report that me and my team have been working in an RFI mitigation technique for ROACH2, based in frequency domain adaptive filter. This requires a reference antenna no measure the RFI in the environment, I understand that there have been FPGA implementations of this before, but I've never seen an implementation and results in CASPER hardware. Here is the paper for everyone interested: https://arxiv.org/abs/1805.06376. We are currently trying to test the filter in China's Five hundred meter Aperture Spherical Telescope (FAST), and we expect to have results soon. Thanks, Franco On Tue, Dec 12, 2017 at 9:55 PM, Dan Werthimer <d...@ssl.berkeley.edu> wrote: > > hi xavier, > > it sounds like you are switching between two signal sources, > one is a reference load with a very small signal level, > and the other is a signal from the sky with strong RFI? > > if that's the case, can you turn up the signal level on your reference > level? > it would be best if the RMS is around 10 on a scale of -128 to +127 > for both signal sources. (so that neither source saturates the adc, > and neither source has too small a signal level where you degrade the SNR > from finite quantization). > > if you are not switching between two sources, and you have a very weak > astronomical > signal buried in RFI and noise, then that's fine - the weak astronomical > signal can be much > lower than a single bit on the ADC and you can recover it from integration > in your spectrometer. > just don't let your ADC saturate too often as that splatters power around > the spectrum. > (or if the ADC is saturating from impulsive RFI, then use one of the > casper libraries that detects > this saturation and replaces it with noise). > > best wishes, > > dan > > > > > On Tue, Dec 12, 2017 at 4:36 PM, Xavier Bosch <bruixa.aburrid...@gmail.com > > wrote: > >> Hi Bob, >> >> Thank you for your answer. >> Yes, calibrating the 8-bit 5-GSPS ASIAA ADC is a must! I worked on that >> some time ago. >> I always make sure that the 4-cores OGP and IODELAYS calibration residual >> error is within a acceptable range before starting any data acquisition. >> >> We also have checked the whole LNA chain linearity and it is fine, there >> is no harmonic distortion. So, we narrowed down the problem to the fact >> that we do not have enough dynamic range in the ADC to accommodate the RFI, >> avoiding clipping, and simultaneously having enough bits (>2) when looking >> to a clean reference load. >> >> Thank you again, >> XB >> >> >> On Mon, Dec 11, 2017 at 2:16 PM Wilson, Robert <rwil...@cfa.harvard.edu> >> wrote: >> >>> Hi Xavier, >>> >>> One problem with the the 8-bit 5-GSPS ASIAA ADC board is that the ADC >>> has four cores and if they are not exactly aligned, a strong RFI signal >>> will be modulated by and mix with the periodic errors producing a number of >>> artifacts. >>> >>> Bob Wilson >>> >>> On Thu, Dec 7, 2017 at 5:10 PM, Xavier Bosch < >>> bruixa.aburrid...@gmail.com> wrote: >>> >>>> Hi CASPERites, >>>> >>>> >>>> >>>> We are developing a wideband spectrometer (~1.6 GHz ) in a band that >>>> has a lot of RFI. Currently we are using the 8-bit 5-GSPS ASIAA ADC board >>>> and the ROACH2, and the ADC resolution appears to be inadequate for our >>>> extreme RFI environment. >>>> >>>> >>>> >>>> We would like to move over to a higher resolution ADC (12 to 14 bits), >>>> probably with a JESD204B interface, and a Xilinx development kit. We are >>>> considering something like this evaluation board KCU105 >>>> <https://www.xilinx.com/products/boards-and-kits/kcu105.html#hardware>and >>>> something like FMC217 >>>> <https://www.vadatech.com/product.php?product=528_prev=0_now=0> >>>> as a digitizer. >>>> >>>> >>>> Has anyone been in a similar situation dealing with RFI? >>>> >>>> Has anyone ported CASPER library to Xilinx development kits and >>>> JESD204B ADCs? >>>> >>>> >>>> Thank you, >>>> >>>> XB >>>> >>>> -- >>>> >>> 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 >>>&
[casper] Unable to run SmartXplorer inside CASPER toolflow
Dear all, I'm trying to use the new SmartXplorer function in the XPS compilation window from the roach2 branch of casper-astro/mlib_devel. I ticked the smartxplorer box in the window, select 3 threads, and start a compilation, but even though the 'finished successfully' window pop up, the binary files I got are corrupted (the .bof.gz is 0 bytes and the .fpg is 35kB for a model that shoud be ~MB). I found the 'XPS_ROACH2_base/run_smartxplorer.sh' script and try to run SmartXplorer from there but i got 'Failed map' for every strategy before a minute of the strategy running. Does someone knows what's going on? I'm not using SmartXplorer correctly? Thanks, Franco Curotto -- You received this message because you are subscribed to the Google Groups "casper@lists.berkeley.edu" group. To unsubscribe from this group and stop receiving emails from it, send an email to casper+unsubscr...@lists.berkeley.edu. To post to this group, send email to casper@lists.berkeley.edu.
[casper] Snapshot block and trigger
Dear all,
I'm having the following issue with the snapshot block: I'm trying to
control the snapshot using a trigger, so that bram is only overwritten
when the trigger has a rising edge. For this I put the snapshot block in
circular capture mode, and I connect a register to the 'trig' and 'stop'
inputs, with the stop signal one clock delayed. As I understand the
block, when I trigger the register the snapshot should start writing in
memory, because I'm activating stop right after, the memory should be
written only once. However when I test my model I get different data
every time I read the snapshot. This is a minimal example of what I want
to do:
import corr, time
import numpy as np
import matplotlib.pyplot as plt
fpga = corr.katcp_wrapper.FpgaClient('192.168.1.12')
time.sleep(1)
fpga.progdev('adc_sync.bof.gz')
fpga.write_int('snap_trig', 0)
fpga.write_int('snap_trig', 1)
fpga.write_int('snap_trig', 0) # trigger the snapshot once
for _ in range(3): # read the data three times
snap_data0 = np.fromstring(fpga.snapshot_get('adcsnap0',
man_trig=True)['data'], dtype='>i1')[:400]
plt.plot(snap_data0)
plt.show() # <- should show three overlaping lines, instead I get three
different lines
My only guess is that the snapshot_get function is actually triggering
the snapshot block, so is getting new data. Anyone have some idea of
what is going on?
Franco Curotto
--
You received this message because you are subscribed to the Google Groups
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to casper+unsubscr...@lists.berkeley.edu.
To post to this group, send email to casper@lists.berkeley.edu.
Re: [casper] adc5g Compilation Frequencies
Ok, thanks for the advice.
Franco
On 12/09/17 18:28, John Ford wrote:
Hi Franco.
No, it does not work if you ignore these warnings. It sort of works.
Which is worse, IMO...
You should dither your sampling rate until you find something thta
works and design the system to work with that.
John
On Tue, Sep 12, 2017 at 2:09 PM, Franco <francocuro...@gmail.com
<mailto:francocuro...@gmail.com>> wrote:
Interesting, thanks for the info. Do you know if it is safe to
operate the ADC outside does assigned constraints, assuming the
model meets timing closure?
Franco
On 12/09/17 17:34, David MacMahon wrote:
Hi, Franco,
I'm not extensively familiar with the inner workings of the
AGC5G yellow block, but I suspect the limitation is caused by
the somewhat obscure constraints imposed by the MMCM in the
Virtex 6. This limitation also affects the ADC16 yellow
block. More details can be found here:
https://casper.berkeley.edu/wiki/ADC16x250-8#ADC16_Sample_Rate_vs_Virtex-6_MMCM_Limitations
<https://casper.berkeley.edu/wiki/ADC16x250-8#ADC16_Sample_Rate_vs_Virtex-6_MMCM_Limitations>
Hope this helps,
Dave
On Sep 12, 2017, at 14:37, Franco <francocuro...@gmail.com
<mailto:francocuro...@gmail.com>> wrote:
Dear Casperites,
Recently I've been testing adc5g block for different
compilation frequency, I figured that the block can be
compiled at [540, 960] U [1080, 2500] MHz, for every other
frequency it gives you a "An optimum PLL solution is not
available!" error. This restrictions come from the Matlab
script 'xps_adc5g.m' that generates the block. The block
does some computation I don't understand to to set the PLL
parameters (or fails to do). Does someone has information
about why this block has that particular behavior? I want
to compile a model at 1000MHz, and I wonder if it is possible.
Many Thanks,
Franco Curotto
--
You received this message because you are subscribed to
the Google Groups "casper@lists.berkeley.edu
<mailto: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
<mailto:casper%2bunsubscr...@lists.berkeley.edu>.
To post to this group, send email to
casper@lists.berkeley.edu <mailto:casper@lists.berkeley.edu>.
--
You received this message because you are subscribed to the Google
Groups "casper@lists.berkeley.edu
<mailto: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
<mailto:casper%2bunsubscr...@lists.berkeley.edu>.
To post to this group, send email to casper@lists.berkeley.edu
<mailto:casper@lists.berkeley.edu>.
--
You received this message because you are subscribed to the Google Groups
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to casper+unsubscr...@lists.berkeley.edu.
To post to this group, send email to casper@lists.berkeley.edu.
Re: [casper] adc5g Compilation Frequencies
Interesting, thanks for the info. Do you know if it is safe to operate the ADC outside does assigned constraints, assuming the model meets timing closure? Franco On 12/09/17 17:34, David MacMahon wrote: Hi, Franco, I'm not extensively familiar with the inner workings of the AGC5G yellow block, but I suspect the limitation is caused by the somewhat obscure constraints imposed by the MMCM in the Virtex 6. This limitation also affects the ADC16 yellow block. More details can be found here: https://casper.berkeley.edu/wiki/ADC16x250-8#ADC16_Sample_Rate_vs_Virtex-6_MMCM_Limitations Hope this helps, Dave On Sep 12, 2017, at 14:37, Franco <francocuro...@gmail.com> wrote: Dear Casperites, Recently I've been testing adc5g block for different compilation frequency, I figured that the block can be compiled at [540, 960] U [1080, 2500] MHz, for every other frequency it gives you a "An optimum PLL solution is not available!" error. This restrictions come from the Matlab script 'xps_adc5g.m' that generates the block. The block does some computation I don't understand to to set the PLL parameters (or fails to do). Does someone has information about why this block has that particular behavior? I want to compile a model at 1000MHz, and I wonder if it is possible. Many Thanks, Franco Curotto -- You received this message because you are subscribed to the Google Groups "casper@lists.berkeley.edu" group. To unsubscribe from this group and stop receiving emails from it, send an email to casper+unsubscr...@lists.berkeley.edu. To post to this group, send email to casper@lists.berkeley.edu. -- You received this message because you are subscribed to the Google Groups "casper@lists.berkeley.edu" group. To unsubscribe from this group and stop receiving emails from it, send an email to casper+unsubscr...@lists.berkeley.edu. To post to this group, send email to casper@lists.berkeley.edu.
[casper] adc5g Compilation Frequencies
Dear Casperites, Recently I've been testing adc5g block for different compilation frequency, I figured that the block can be compiled at [540, 960] U [1080, 2500] MHz, for every other frequency it gives you a "An optimum PLL solution is not available!" error. This restrictions come from the Matlab script 'xps_adc5g.m' that generates the block. The block does some computation I don't understand to to set the PLL parameters (or fails to do). Does someone has information about why this block has that particular behavior? I want to compile a model at 1000MHz, and I wonder if it is possible. Many Thanks, Franco Curotto -- You received this message because you are subscribed to the Google Groups "casper@lists.berkeley.edu" group. To unsubscribe from this group and stop receiving emails from it, send an email to casper+unsubscr...@lists.berkeley.edu. To post to this group, send email to casper@lists.berkeley.edu.
[casper] SmartXplorer is supported only on 32-bit or 64-bit Linux platforms
Dear all, Had anyone deal with this problem in SmartXplorer? I think is because of I'm using a newer version of linux (Debian Stretch): WARNING: Unsupported platform on remote host franco-machine. SmartXplorer is supported only on 32-bit or 64-bit Linux platforms. Removing host from hostlist. ERROR: No hosts available to run remote jobs. Ensure that remote commands can be launched using rsh or ssh on the hosts specified in the hostlist file. Please refer to SmartXplorer documentation on configuring these hosts for running remote commands. Franco -- You received this message because you are subscribed to the Google Groups "casper@lists.berkeley.edu" group. To unsubscribe from this group and stop receiving emails from it, send an email to casper+unsubscr...@lists.berkeley.edu. To post to this group, send email to casper@lists.berkeley.edu.
Re: [casper] Help with PlanAhead
I actually didn't know that tool existed! I am trying to meet timing constraints, and I'm actually very close to do so, so I'm definitely gonna try smartxplorer. Thanks for the advise! Franco On 25/05/17 15:24, Michael D'Cruze wrote: Hi Franco, Just curious, but have you considered using SmartXplorer to assist in getting your design to meet timing, if this is the eventual goal? Usually I find that with a medium or large design, if I can adjust the latencies in Simulink to get within a timing score of, say, 1, then running smartxplorer on those netlist files usually finishes off the job. It can take a very, very long time though since it is a brute-force method. Most jobs for me complete within about 24hrs, however the largest design I ever tried took a full week... Good luck Michael -Original Message- From: Franco [mailto:francocuro...@gmail.com] Sent: 23 May 2017 20:59 To: Casper Lists Subject: [casper] Help with PlanAhead Dear Casper community, I seek your wisdom once again. I was doing floorplanning to my model when I noticed something interesting. My model has 40 vector accumulator blocks (simple_bram_vacc). When I opened my model in PlanAhead, I noticed that all the BRAMs of every vacc were sharing the same single counter implementation for addressing, instead of each vacc having its independent counter. I understand that these two implementations are equivalent because all the counters are equivalent and can be replaced by a single one addressing all the BRAMs, but it makes me wonder: 1) Why this substitution happened? Was the Xilinx/EDK tools that tried to do some optimization? Or it has something to do with the simple_bram_vacc block implementation? 2) Isn't this implementation detrimental for routing proposes? I mean a single counter must address 40 different BRAMs across the FPGA. (My critical paths don't involve the counter, but they do involve a lot of vacc BRAMs with other components). 3) What would you recommend me to increase the speed of my model? Force every vacc to implement their own counter (if that's even possible)? Group my BRAMs around or near the lonely counter? Something else? As always, many thanks, Franco Curotto -- You received this message because you are subscribed to the Google Groups "casper@lists.berkeley.edu" group. To unsubscribe from this group and stop receiving emails from it, send an email to casper+unsubscr...@lists.berkeley.edu. To post to this group, send email to casper@lists.berkeley.edu.
Re: [casper] Help with PlanAhead
Thanks for the feedback Jack! On 25/05/17 13:46, Jack Hickish wrote: Hi Franco, 1) Yes, this is an optimization the tools have performed. If you dig into the Xilinx manuals you can probably find some options / UCF entries to turn off this type of optimization, or at least make it less aggressive. I don't use these enough to know exactly which ones you want, but I'd start with reading about the "KEEP" and "DONT_TOUCH" attributes. 2) In my opinion this probably is detrimental, though you should keep in mind that having more "stuff" in your design is generally unhelpful too. 3) I believe if you set the vacc counters to use either DSP or fabric cores, rather than behavioural HDL (see the "implementation" tab of the counter block) this might prevent the merging of all the blocks. It's not a bad move to make large counters DSPs anyway, if you have lots of them to spare in your design. I might also be inclined to make a pblock for each vacc, with each one containing the brams and dsps associated with that accumulator. Personally, I rarely bother to constrain soft logic. Floorplanning is a bit of a dark art, and everyone has their own recipe, but if you eventually meet timing and have made notes on your methods the wiki would be a great place for them. Good luck! Jack On Tue, 23 May 2017 at 12:59 Franco <francocuro...@gmail.com <mailto:francocuro...@gmail.com>> wrote: Dear Casper community, I seek your wisdom once again. I was doing floorplanning to my model when I noticed something interesting. My model has 40 vector accumulator blocks (simple_bram_vacc). When I opened my model in PlanAhead, I noticed that all the BRAMs of every vacc were sharing the same single counter implementation for addressing, instead of each vacc having its independent counter. I understand that these two implementations are equivalent because all the counters are equivalent and can be replaced by a single one addressing all the BRAMs, but it makes me wonder: 1) Why this substitution happened? Was the Xilinx/EDK tools that tried to do some optimization? Or it has something to do with the simple_bram_vacc block implementation? 2) Isn't this implementation detrimental for routing proposes? I mean a single counter must address 40 different BRAMs across the FPGA. (My critical paths don't involve the counter, but they do involve a lot of vacc BRAMs with other components). 3) What would you recommend me to increase the speed of my model? Force every vacc to implement their own counter (if that's even possible)? Group my BRAMs around or near the lonely counter? Something else? As always, many thanks, Franco Curotto -- You received this message because you are subscribed to the Google Groups "casper@lists.berkeley.edu <mailto: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 <mailto:casper%2bunsubscr...@lists.berkeley.edu>. To post to this group, send email to casper@lists.berkeley.edu <mailto: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] Help with PlanAhead
Dear Casper community, I seek your wisdom once again. I was doing floorplanning to my model when I noticed something interesting. My model has 40 vector accumulator blocks (simple_bram_vacc). When I opened my model in PlanAhead, I noticed that all the BRAMs of every vacc were sharing the same single counter implementation for addressing, instead of each vacc having its independent counter. I understand that these two implementations are equivalent because all the counters are equivalent and can be replaced by a single one addressing all the BRAMs, but it makes me wonder: 1) Why this substitution happened? Was the Xilinx/EDK tools that tried to do some optimization? Or it has something to do with the simple_bram_vacc block implementation? 2) Isn't this implementation detrimental for routing proposes? I mean a single counter must address 40 different BRAMs across the FPGA. (My critical paths don't involve the counter, but they do involve a lot of vacc BRAMs with other components). 3) What would you recommend me to increase the speed of my model? Force every vacc to implement their own counter (if that's even possible)? Group my BRAMs around or near the lonely counter? Something else? As always, many thanks, Franco Curotto -- You received this message because you are subscribed to the Google Groups "casper@lists.berkeley.edu" group. To unsubscribe from this group and stop receiving emails from it, send an email to casper+unsubscr...@lists.berkeley.edu. To post to this group, send email to casper@lists.berkeley.edu.
Re: [casper] PlanAhead Import Error
Ah, interesting, didn't thought of that. I'll try to figure it out a bit more, and if I get nowhere I'll use your approach. Thanks! Franco Jack Hickish wrote >Hi Franco, > > >I've had this error before. To be honest, since ISE compiled my design fine >and I could see no issues in hardware when comparing digital noise sent >through multiple FFT channels, I just ignored the problem. That is, I used >planahead to generate constraints/pblocks, but compiled these with casper_xps >using the UCF yellow block. > >If you get to the bottom of this I'd be interested in what you learn. > > >Cheers > >Jack > > >On Thu, 11 May 2017 at 12:52 Franco <francocuro...@gmail.com> wrote: > >Dear Casperites, > >I, once again, need your wisdom. I'm trying to do floorplanning on a >model, but whenever I create a new project with Xilinx Planahead the >model fails to load. Just to be sure I'm not doing something wrong I'll >detail my workflow: > >1. I compile a Simulink model using Matlab/casper_xps. The model >compiles successfully. > >2. I open PlanAhead with: "source setting64.sh && sudo planAhead" in the >Xilinx installation folder. > >3. "Create a new project" -> "Import ISE & Place and Route Results" > >4. In add netlist source list: "Add File" -> >"/XPS_ROACH2_base/implementation/system.ngc", "Import >Directories" -> "/XPS_ROACH2_base/implementation/" > >5. In add constraints: "Add File" -> >"/XPS_ROACH2_base/implementation/system.ucf" > >6. In default part I choose: "xc6vsx475tff1759-1" > >7. In import ISE implementation results: "Placement file" -> >"/XPS_ROACH2_base/implementation/system_map.ncd", "Import >timing" -> "/XPS_ROACH2_base/implementation/system.twx" > >8. After doing this, the project starts loading the files and I get this >error: > >ERROR: [Designutils 20-662] Internal error: 'Cannot place carry chain >instance >kestfilt_4096ch_600mhz1_XSG_core_config/kestfilt_4096ch_600mhz1_XSG_core_config/kestfilt_4096ch_600mhz1_x0/fft_wideband_real0_3bb28f4f1a/fft_direct_2a29a9ae17/butterfly2_0_74870afb03/bus_convert_a7eae3d1b2/conv2_4beea44e63/convert_8b81baa718/adder/comp9.core_instance9/blk0001/blk002c >at (SLICE_X107Y155): Could not legally place instance >kestfilt_4096ch_600mhz1_XSG_core_config/kestfilt_4096ch_600mhz1_XSG_core_config/kestfilt_4096ch_600mhz1_x0/fft_wideband_real0_3bb28f4f1a/fft_direct_2a29a9ae17/butterfly2_0_74870afb03/bus_convert_a7eae3d1b2/conv2_4beea44e63/convert_8b81baa718/adder/comp9.core_instance9/blk0001/blk002c >at SLICE_X107Y155 since it belongs to a shape containing instance >kestfilt_4096ch_600mhz1_XSG_core_config/kestfilt_4096ch_600mhz1_XSG_core_config/kestfilt_4096ch_600mhz1_x0/fft_wideband_real0_3bb28f4f1a/fft_direct_2a29a9ae17/butterfly2_0_74870afb03/bus_convert_a7eae3d1b2/conv2_4beea44e63/convert_8b81baa718/adder/comp9.core_instance9/blk0001/blk001b. >The shape requires relative placement between >kestfilt_4096ch_600mhz1_XSG_core_config/kestfilt_4096ch_600mhz1_XSG_core_config/kestfilt_4096ch_600mhz1_x0/fft_wideband_real0_3bb28f4f1a/fft_direct_2a29a9ae17/butterfly2_0_74870afb03/bus_convert_a7eae3d1b2/conv2_4beea44e63/convert_8b81baa718/adder/comp9.core_instance9/blk0001/blk002c >and >kestfilt_4096ch_600mhz1_XSG_core_config/kestfilt_4096ch_600mhz1_XSG_core_config/kestfilt_4096ch_600mhz1_x0/fft_wideband_real0_3bb28f4f1a/fft_direct_2a29a9ae17/butterfly2_0_74870afb03/bus_convert_a7eae3d1b2/conv2_4beea44e63/convert_8b81baa718/adder/comp9.core_instance9/blk0001/blk001b >that cannnot be honored because it would result in an invalid location >for >kestfilt_4096ch_600mhz1_XSG_core_config/kestfilt_4096ch_600mhz1_XSG_core_config/kestfilt_4096ch_600mhz1_x0/fft_wideband_real0_3bb28f4f1a/fft_direct_2a29a9ae17/butterfly2_0_74870afb03/bus_convert_a7eae3d1b2/conv2_4beea44e63/convert_8b81baa718/adder/comp9.core_instance9/blk0001/blk001b.' > >And four other similar errors. > >I'm using Matlab 2013a, Xilinx ISE Design Suite 14.7, and the latest >version of casper-astro/mlib_devel from github in Debian Stretch. I'm >really confused by this error, it seems to be a placement error, but it >doesn't make sense because I could successfully compiled with >casper_xps. Googling the problem I only found this link: >https://forums.xilinx.com/t5/Synthesis/Planahead-Cannot-place-carry-chain-instance/td-p/742833 >which didn't helped me too much. > >Has anyone encountered this same problem? > >Franco > >-- >You received this message because you are subscribed to the Google Groups >"casper@lists.berkeley.edu" group. >T
[casper] PlanAhead Import Error
Dear Casperites, I, once again, need your wisdom. I'm trying to do floorplanning on a model, but whenever I create a new project with Xilinx Planahead the model fails to load. Just to be sure I'm not doing something wrong I'll detail my workflow: 1. I compile a Simulink model using Matlab/casper_xps. The model compiles successfully. 2. I open PlanAhead with: "source setting64.sh && sudo planAhead" in the Xilinx installation folder. 3. "Create a new project" -> "Import ISE & Place and Route Results" 4. In add netlist source list: "Add File" -> "/XPS_ROACH2_base/implementation/system.ngc", "Import Directories" -> "/XPS_ROACH2_base/implementation/" 5. In add constraints: "Add File" -> "/XPS_ROACH2_base/implementation/system.ucf" 6. In default part I choose: "xc6vsx475tff1759-1" 7. In import ISE implementation results: "Placement file" -> "/XPS_ROACH2_base/implementation/system_map.ncd", "Import timing" -> "/XPS_ROACH2_base/implementation/system.twx" 8. After doing this, the project starts loading the files and I get this error: ERROR: [Designutils 20-662] Internal error: 'Cannot place carry chain instance kestfilt_4096ch_600mhz1_XSG_core_config/kestfilt_4096ch_600mhz1_XSG_core_config/kestfilt_4096ch_600mhz1_x0/fft_wideband_real0_3bb28f4f1a/fft_direct_2a29a9ae17/butterfly2_0_74870afb03/bus_convert_a7eae3d1b2/conv2_4beea44e63/convert_8b81baa718/adder/comp9.core_instance9/blk0001/blk002c at (SLICE_X107Y155): Could not legally place instance kestfilt_4096ch_600mhz1_XSG_core_config/kestfilt_4096ch_600mhz1_XSG_core_config/kestfilt_4096ch_600mhz1_x0/fft_wideband_real0_3bb28f4f1a/fft_direct_2a29a9ae17/butterfly2_0_74870afb03/bus_convert_a7eae3d1b2/conv2_4beea44e63/convert_8b81baa718/adder/comp9.core_instance9/blk0001/blk002c at SLICE_X107Y155 since it belongs to a shape containing instance kestfilt_4096ch_600mhz1_XSG_core_config/kestfilt_4096ch_600mhz1_XSG_core_config/kestfilt_4096ch_600mhz1_x0/fft_wideband_real0_3bb28f4f1a/fft_direct_2a29a9ae17/butterfly2_0_74870afb03/bus_convert_a7eae3d1b2/conv2_4beea44e63/convert_8b81baa718/adder/comp9.core_instance9/blk0001/blk001b. The shape requires relative placement between kestfilt_4096ch_600mhz1_XSG_core_config/kestfilt_4096ch_600mhz1_XSG_core_config/kestfilt_4096ch_600mhz1_x0/fft_wideband_real0_3bb28f4f1a/fft_direct_2a29a9ae17/butterfly2_0_74870afb03/bus_convert_a7eae3d1b2/conv2_4beea44e63/convert_8b81baa718/adder/comp9.core_instance9/blk0001/blk002c and kestfilt_4096ch_600mhz1_XSG_core_config/kestfilt_4096ch_600mhz1_XSG_core_config/kestfilt_4096ch_600mhz1_x0/fft_wideband_real0_3bb28f4f1a/fft_direct_2a29a9ae17/butterfly2_0_74870afb03/bus_convert_a7eae3d1b2/conv2_4beea44e63/convert_8b81baa718/adder/comp9.core_instance9/blk0001/blk001b that cannnot be honored because it would result in an invalid location for kestfilt_4096ch_600mhz1_XSG_core_config/kestfilt_4096ch_600mhz1_XSG_core_config/kestfilt_4096ch_600mhz1_x0/fft_wideband_real0_3bb28f4f1a/fft_direct_2a29a9ae17/butterfly2_0_74870afb03/bus_convert_a7eae3d1b2/conv2_4beea44e63/convert_8b81baa718/adder/comp9.core_instance9/blk0001/blk001b.' And four other similar errors. I'm using Matlab 2013a, Xilinx ISE Design Suite 14.7, and the latest version of casper-astro/mlib_devel from github in Debian Stretch. I'm really confused by this error, it seems to be a placement error, but it doesn't make sense because I could successfully compiled with casper_xps. Googling the problem I only found this link: https://forums.xilinx.com/t5/Synthesis/Planahead-Cannot-place-carry-chain-instance/td-p/742833 which didn't helped me too much. Has anyone encountered this same problem? Franco -- You received this message because you are subscribed to the Google Groups "casper@lists.berkeley.edu" group. To unsubscribe from this group and stop receiving emails from it, send an email to casper+unsubscr...@lists.berkeley.edu. To post to this group, send email to casper@lists.berkeley.edu.
[casper] MATLAB startup error
Dear all, I tried to load MATLAB today as I do everyday when I suddenly got this error: Reading local definitions from './startsg.local' Using MATLAB_PATH=/home/franco/Software/STEM/MATLAB-R2013a Using XILINX_PATH=/home/franco/Software/STEM/Xilinx-ISE/14.7/ISE_DS Using XILINX_PLATFORM=lin64 Using MLIB_DEVEL_PATH=/home/franco/Software/Workspace/Calan/mlib_devel_calan awk: symbol lookup error: awk: undefined symbol: mpfr_z_sub Internal error 2: Could not determine the path of the MATLAB root directory. original command path = /home/franco/Software/STEM/MATLAB-R2013a/bin/matlab current command path = /home/franco/Software/STEM/MATLAB-R2013a/bin/matlab Please contact: MathWorks Technical Support for further assistance. I did what is suggested in this previous answer: https://www.mail-archive.com/casper@lists.berkeley.edu/msg06619.html, but it didn't worked. Does anyone has any other idea? Thanks, Franco -- You received this message because you are subscribed to the Google Groups "casper@lists.berkeley.edu" group. To unsubscribe from this group and stop receiving emails from it, send an email to casper+unsubscr...@lists.berkeley.edu. To post to this group, send email to casper@lists.berkeley.edu.
[casper] sync_gen parameters questions
Dear Casper Community, I was playing with the sync_gen block, and I have some question regarding its parameters. I read the syn_gen memo (https://casper.berkeley.edu/memos/sync_memo_v1.pdf) but it didn't help much: - Simulation Accumulation Length: how do you set this parameter when you can change accumulation length dynamically? Does this value matter only for simulation?(Is the simulation word that is throwing me off). - Reorder Orders: In the updated library the Reorder Orders parameter get initialized with the code: getfield( getfield( get_param( gcb,'UserData' ), 'parameters'),'reorder_vec'), does this mean that the block get the orders automatically and I don't have to care about it? - Scale: I don't understand what is this parameter used for. Why would you want to use a scale other than 1? My apologies if this questions have been answer already, and I wasn't able to find them. Thanks, Franco -- You received this message because you are subscribed to the Google Groups "casper@lists.berkeley.edu" group. To unsubscribe from this group and stop receiving emails from it, send an email to casper+unsubscr...@lists.berkeley.edu. To post to this group, send email to casper@lists.berkeley.edu.
[casper] ADC5G out of range
Hi all, Is there an easy way to check if the ADC5G in ROACH2 is out of range? I noticed there is and out-of-range output in the EV8AQ160 QUAD ADC chip (according to the datasheet), but is not implemented in the asiaa_adc5g yellow block. Thanks, Franco -- You received this message because you are subscribed to the Google Groups "casper@lists.berkeley.edu" group. To unsubscribe from this group and stop receiving emails from it, send an email to casper+unsubscr...@lists.berkeley.edu. To post to this group, send email to casper@lists.berkeley.edu.
Re: [casper] Minimum Clock Frequency (ROACH2)
Ok, thanks for the suggestion, I'll try it out.
Franco
On 04/04/17 09:50, James Smith wrote:
Hello Franco,
If you're only using 1 sample at a time, you needn't use a CASPER FFT,
the Xilinx ones do the trick nicely. You can use an asynchronous
1-input PFB if you want to as well.
You would probably need to rework your down-stream stuff though.
Regards,
James
On Tue, Apr 4, 2017 at 2:48 PM, Franco <francocuro...@gmail.com
<mailto:francocuro...@gmail.com>> wrote:
Hi Jack,
I though of that, but the thing is, if I only take 1 sample per
clock cycle, I'm not sure how to use a 8 input FFT and still keep
the same number of output channels. Maybe I could implement
serial-to-parallel block, and read the FFT every 8 cycles, but I
don't know if that's an adequate (or easy to implement) solution.
I get not very informative errors when I try to compile models
below 600MHz (I tried, 100MHz, 200MHz, ... , 500MHz):
Creating block object: xps_adc5g
Problem with block: test/asiaa_adc5g
: An optimum PLL solution is not available!
Backtrace 1: xps_adc5g:177
Backtrace 2: gen_xps_files:229
Backtrace 3: run_Callback:155
Backtrace 4: casper_xps:86
Backtrace 5:
@(hObject,eventdata)casper_xps('run_Callback',hObject,eventdata,guidata(hObject)):0
Error using gen_xps_files (line 242)
Error found during Object creation.
Thanks,
Franco
On 03/04/17 23:39, Jack Hickish wrote:
Hi Franco,
I don't know the low frequency limit, but for what it's worth,
you could always run the adc at 320 MHz and just use 1 of the 8
outputs, which also has the benefit of avoiding and inter-core
mismatch issues, since you'd effectively only be using 1 core. Or
run faster and only use every Nth sample.
What error do you get when you clock below 600 MHz ADC clock?
Cheers
Jack
On Mon, 3 Apr 2017, 19:22 Franco, <francocuro...@gmail.com
<mailto:francocuro...@gmail.com>> wrote:
Hi All,
I'm working in an application where I need high frequency
resolution (~10kHz). For my model this means I need to run my
ADC at ~40MHz (and the FPGA at 5MHz). I'm not using an
special memory block, just brams. I'm using ROACH2, and ADC5G
(https://casper.berkeley.edu/wiki/ADC1x5000-8
<https://casper.berkeley.edu/wiki/ADC1x5000-8>). It is
possible to run the ADC at such low frequency? What is the
minimum acceptable frequency? I tried to find this
information in the ADC datasheet, but I haven't been
successful. Also tried compiling simple models at low
frequencies, but everything below 600MHz failed.
Thanks,
Franco
--
You received this message because you are subscribed to the
Google Groups "casper@lists.berkeley.edu
<mailto: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
<mailto:casper+unsubscr...@lists.berkeley.edu>.
To post to this group, send email to
casper@lists.berkeley.edu <mailto:casper@lists.berkeley.edu>.
--
You received this message because you are subscribed to the Google
Groups "casper@lists.berkeley.edu
<mailto: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
<mailto:casper+unsubscr...@lists.berkeley.edu>.
To post to this group, send email to casper@lists.berkeley.edu
<mailto: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] Minimum Clock Frequency (ROACH2)
Oh, that may be exactly what I need, I'll try it out. Thanks! Franco On 04/04/17 03:14, Andrew Martens wrote: Hey Franco Many of the CASPER blocks were updated a while ago so that you can use them asynchronously i.e data does not need to be fed to the blocks on every clock cycle. You can then run your FPGA at a higher clock rate than the input data rate. Regards Andrew On Tue, Apr 4, 2017 at 4:22 AM, Franco <francocuro...@gmail.com <mailto:francocuro...@gmail.com>> wrote: Hi All, I'm working in an application where I need high frequency resolution (~10kHz). For my model this means I need to run my ADC at ~40MHz (and the FPGA at 5MHz). I'm not using an special memory block, just brams. I'm using ROACH2, and ADC5G (https://casper.berkeley.edu/wiki/ADC1x5000-8 <https://casper.berkeley.edu/wiki/ADC1x5000-8>). It is possible to run the ADC at such low frequency? What is the minimum acceptable frequency? I tried to find this information in the ADC datasheet, but I haven't been successful. Also tried compiling simple models at low frequencies, but everything below 600MHz failed. Thanks, Franco -- You received this message because you are subscribed to the Google Groups "casper@lists.berkeley.edu <mailto: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 <mailto:casper+unsubscr...@lists.berkeley.edu>. To post to this group, send email to casper@lists.berkeley.edu <mailto: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] Minimum Clock Frequency (ROACH2)
Hi Jack,
I though of that, but the thing is, if I only take 1 sample per clock
cycle, I'm not sure how to use a 8 input FFT and still keep the same
number of output channels. Maybe I could implement serial-to-parallel
block, and read the FFT every 8 cycles, but I don't know if that's an
adequate (or easy to implement) solution.
I get not very informative errors when I try to compile models below
600MHz (I tried, 100MHz, 200MHz, ... , 500MHz):
Creating block object: xps_adc5g
Problem with block: test/asiaa_adc5g
: An optimum PLL solution is not available!
Backtrace 1: xps_adc5g:177
Backtrace 2: gen_xps_files:229
Backtrace 3: run_Callback:155
Backtrace 4: casper_xps:86
Backtrace 5:
@(hObject,eventdata)casper_xps('run_Callback',hObject,eventdata,guidata(hObject)):0
Error using gen_xps_files (line 242)
Error found during Object creation.
Thanks,
Franco
On 03/04/17 23:39, Jack Hickish wrote:
Hi Franco,
I don't know the low frequency limit, but for what it's worth, you
could always run the adc at 320 MHz and just use 1 of the 8 outputs,
which also has the benefit of avoiding and inter-core mismatch issues,
since you'd effectively only be using 1 core. Or run faster and only
use every Nth sample.
What error do you get when you clock below 600 MHz ADC clock?
Cheers
Jack
On Mon, 3 Apr 2017, 19:22 Franco, <francocuro...@gmail.com
<mailto:francocuro...@gmail.com>> wrote:
Hi All,
I'm working in an application where I need high frequency
resolution (~10kHz). For my model this means I need to run my ADC
at ~40MHz (and the FPGA at 5MHz). I'm not using an special memory
block, just brams. I'm using ROACH2, and ADC5G
(https://casper.berkeley.edu/wiki/ADC1x5000-8). It is possible to
run the ADC at such low frequency? What is the minimum acceptable
frequency? I tried to find this information in the ADC datasheet,
but I haven't been successful. Also tried compiling simple models
at low frequencies, but everything below 600MHz failed.
Thanks,
Franco
--
You received this message because you are subscribed to the Google
Groups "casper@lists.berkeley.edu
<mailto: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
<mailto:casper+unsubscr...@lists.berkeley.edu>.
To post to this group, send email to casper@lists.berkeley.edu
<mailto: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] Minimum Clock Frequency (ROACH2)
Hi All, I'm working in an application where I need high frequency resolution (~10kHz). For my model this means I need to run my ADC at ~40MHz (and the FPGA at 5MHz). I'm not using an special memory block, just brams. I'm using ROACH2, and ADC5G (https://casper.berkeley.edu/wiki/ADC1x5000-8). It is possible to run the ADC at such low frequency? What is the minimum acceptable frequency? I tried to find this information in the ADC datasheet, but I haven't been successful. Also tried compiling simple models at low frequencies, but everything below 600MHz failed. Thanks, Franco -- You received this message because you are subscribed to the Google Groups "casper@lists.berkeley.edu" group. To unsubscribe from this group and stop receiving emails from it, send an email to casper+unsubscr...@lists.berkeley.edu. To post to this group, send email to casper@lists.berkeley.edu.
Re: [casper] progdev fail
Thanks Jack, I'll check into the project but it seems to have what I've
been looking for.
Franco
On 15/12/16 07:28, Jack Hickish wrote:
More broadly speaking, has anyone ever used the DDR powerPC interface
on ROACH2? Is it actually know to work with code as-provided in the
mlib_devel / katcp repos?
Franco -- perhaps this project --
https://github.com/argonnexraydetector/RoachFirmPy -- which I found
linked on the DDR page of the CASPER wiki, might be interesting to you.
Cheers
Jack
On Thu, 15 Dec 2016 at 07:31 Marc Welz <m...@ska.ac.za
<mailto:m...@ska.ac.za>> wrote:
The fpga<->ppc interface is limited in size - if you want to see huge
memory areas, you will need some sort of windowing/offset scheme
regards
marc
On Wed, Dec 14, 2016 at 1:43 PM, Franco <francocuro...@gmail.com
<mailto:francocuro...@gmail.com>> wrote:
> Doing some more testing, I realize the progdev works when I
remove the DRAM
> block from the model. What could this mean??
>
> Franco
>
>
>
> On 14/12/16 10:13, Franco wrote:
>>
>> Dear Casperites,
>>
>> I'm trying to progdev a model to ROACH2 and I get the following
error:
>>
>> ?progdev cntr_dram2_2016_Dec_13_1558.bof
>> #log info 1019840342915 raw
>> attempting\_to\_program\_cntr_dram2_2016_Dec_13_1558.bof
>> #log info 1019840343002 raw
>>
attempting\_to\_program\_bitstream\_of\_19586188\_bytes\_to\_device\_/dev/roach/config
>> #fpga loaded
>> #log warn 1019840343887 raw
>> requesting\_to\_map\_a\_rather\_large\_area\_of\_0x8000
>> #log error 1019840343887 raw
>> unable\_to\_map\_file\_/dev/roach/mem:\_Cannot\_allocate\_memory
>> #log error 1019840343890 raw
>>
unable\_to\_program\_bit\_stream\_from\_cntr_dram2_2016_Dec_13_1558.bof
>> !progdev fail
>>
>> Anyone has any idea what's the problem? I can program other
models fine,
>> but this is the first model I compiled using the SKA fork library.
>>
>> Thanks,
>>
>> Franco
>>
>
>
Re: [casper] Problem reading DRAM in ROACH2
Ok, so I updated the libraries and I'm having the same problem, however I notice that now I have two new registers: 'ddr3_ctrl', 'ddr3_mem'. I suppose those are the registers that I'm missing changed names. There was a name changing in the library so that it make incompatible with the katcp_wrapper script? thanks, Franco On 02/12/16 12:42, Franco wrote: No, I'm using the tutorial version. That might be the problem. However I'm reluctant to update since this might cause incompatibilities with my previous models. I suppose that if I what to use the DRAM I don't have other choice. Do you have any suggestions? Many thanks, Franco Jason Manley wrote Are you running the latest version of the toolflow? Earlier versions did not include the CPU interface to the DRAM. Jason On 02 Dec 2016, at 15:30, Franco <francocuro...@gmail.com <mailto:francocuro...@gmail.com>> wrote: > The register is not present in the bitstream. I thought that the register was inside the dram yellow block though. I have to add it manually or something? > > Here is the listdev just in case: > > ['acc_len', > 'adc5g_controller', > 'cnt_rst', > 'dout0_0', > 'dout0_1', > 'dout0_2', > 'dout0_3', > 'dout1_0', > 'dout1_1', > 'dout1_2', > 'dout1_3', > 'dout2_0', > 'dout2_1', > 'dout2_2', > 'dout2_3', > 'filter_gain', > 'filter_on', > 'snapshot0_bram', > 'snapshot0_ctrl', > 'snapshot0_status', > 'snapshot0_trig_offset', > 'snapshot1_bram', > 'snapshot1_ctrl', > 'snapshot1_status', > 'snapshot1_trig_offset', > 'sync_gen_sync', > 'sync_gen_sync_period_sel', > 'sync_gen_sync_period_var', > 'sys_board_id', > 'sys_clkcounter', > 'sys_rev', > 'sys_rev_rcs', > 'sys_scratchpad', > 'write_done'] > > thanks, > > Franco > > > On 02/12/16 10:02, Marc Welz wrote: >> Then there is no bitstream programmed or the particular bitstream >> doesn't contain that register. Type >> >> ?listdev >> >> on that connection to find out >> >> regards >> >> marc >> >> >> On Fri, Dec 2, 2016 at 12:52 PM, Franco <francocuro...@gmail.com <mailto:francocuro...@gmail.com>> wrote: >>> It says: #log error 1018802834854 raw >>> register\_dram_controller\_not\_defined >>> >>> >>> Franco >>> >>> >>> >>> On 02/12/16 04:32, Marc Welz wrote: >>>> telnet to the roach on port 7147 while repeating the operation - what >>>> do the #log messages say ? >>>> >>>> On Thu, Dec 1, 2016 at 3:43 PM, Franco <francocuro...@gmail.com <mailto:francocuro...@gmail.com>> wrote: >>>>> Hi! >>>>> >>>>> I tried to test the dram of ROACH2 by porting an example model I had for >>>>> ROACH1. >>>>> >>>>> However when I tried to read the dram I got the following error: >>>>> >>>>> RuntimeError: Request write failed. >>>>>Request: ?write dram_controller 0 \0\0\0\0 >>>>>Reply: !write fail. >>>>> >>>>> Someone knows what's the problem? >>>>> >>>>> >>>>> thanks, >>>>> >>>>> Franco Curotto >>>>> >>>>> > >
Re: [casper] progdev fail
Doing some more testing, I realize the progdev works when I remove the DRAM block from the model. What could this mean?? Franco On 14/12/16 10:13, Franco wrote: Dear Casperites, I'm trying to progdev a model to ROACH2 and I get the following error: ?progdev cntr_dram2_2016_Dec_13_1558.bof #log info 1019840342915 raw attempting\_to\_program\_cntr_dram2_2016_Dec_13_1558.bof #log info 1019840343002 raw attempting\_to\_program\_bitstream\_of\_19586188\_bytes\_to\_device\_/dev/roach/config #fpga loaded #log warn 1019840343887 raw requesting\_to\_map\_a\_rather\_large\_area\_of\_0x8000 #log error 1019840343887 raw unable\_to\_map\_file\_/dev/roach/mem:\_Cannot\_allocate\_memory #log error 1019840343890 raw unable\_to\_program\_bit\_stream\_from\_cntr_dram2_2016_Dec_13_1558.bof !progdev fail Anyone has any idea what's the problem? I can program other models fine, but this is the first model I compiled using the SKA fork library. Thanks, Franco
[casper] progdev fail
Dear Casperites, I'm trying to progdev a model to ROACH2 and I get the following error: ?progdev cntr_dram2_2016_Dec_13_1558.bof #log info 1019840342915 raw attempting\_to\_program\_cntr_dram2_2016_Dec_13_1558.bof #log info 1019840343002 raw attempting\_to\_program\_bitstream\_of\_19586188\_bytes\_to\_device\_/dev/roach/config #fpga loaded #log warn 1019840343887 raw requesting\_to\_map\_a\_rather\_large\_area\_of\_0x8000 #log error 1019840343887 raw unable\_to\_map\_file\_/dev/roach/mem:\_Cannot\_allocate\_memory #log error 1019840343890 raw unable\_to\_program\_bit\_stream\_from\_cntr_dram2_2016_Dec_13_1558.bof !progdev fail Anyone has any idea what's the problem? I can program other models fine, but this is the first model I compiled using the SKA fork library. Thanks, Franco
Re: [casper] Problem reading DRAM in ROACH2
No, I'm using the tutorial version. That might be the problem. However I'm reluctant to update since this might cause incompatibilities with my previous models. I suppose that if I what to use the DRAM I don't have other choice. Do you have any suggestions? Many thanks, Franco Jason Manley wrote >Are you running the latest version of the toolflow? Earlier versions did not >include the CPU interface to the DRAM. > >Jason > > >On 02 Dec 2016, at 15:30, Franco <francocuro...@gmail.com> wrote: > >> The register is not present in the bitstream. I thought that the register >> was inside the dram yellow block though. I have to add it manually or >> something? >> >> Here is the listdev just in case: >> >> ['acc_len', >> 'adc5g_controller', >> 'cnt_rst', >> 'dout0_0', >> 'dout0_1', >> 'dout0_2', >> 'dout0_3', >> 'dout1_0', >> 'dout1_1', >> 'dout1_2', >> 'dout1_3', >> 'dout2_0', >> 'dout2_1', >> 'dout2_2', >> 'dout2_3', >> 'filter_gain', >> 'filter_on', >> 'snapshot0_bram', >> 'snapshot0_ctrl', >> 'snapshot0_status', >> 'snapshot0_trig_offset', >> 'snapshot1_bram', >> 'snapshot1_ctrl', >> 'snapshot1_status', >> 'snapshot1_trig_offset', >> 'sync_gen_sync', >> 'sync_gen_sync_period_sel', >> 'sync_gen_sync_period_var', >> 'sys_board_id', >> 'sys_clkcounter', >> 'sys_rev', >> 'sys_rev_rcs', >> 'sys_scratchpad', >> 'write_done'] >> >> thanks, >> >> Franco >> >> >> On 02/12/16 10:02, Marc Welz wrote: >>> Then there is no bitstream programmed or the particular bitstream >>> doesn't contain that register. Type >>> >>> ?listdev >>> >>> on that connection to find out >>> >>> regards >>> >>> marc >>> >>> >>> On Fri, Dec 2, 2016 at 12:52 PM, Franco <francocuro...@gmail.com> wrote: >>>> It says: #log error 1018802834854 raw >>>> register\_dram_controller\_not\_defined >>>> >>>> >>>> Franco >>>> >>>> >>>> >>>> On 02/12/16 04:32, Marc Welz wrote: >>>>> telnet to the roach on port 7147 while repeating the operation - what >>>>> do the #log messages say ? >>>>> >>>>> On Thu, Dec 1, 2016 at 3:43 PM, Franco <francocuro...@gmail.com> wrote: >>>>>> Hi! >>>>>> >>>>>> I tried to test the dram of ROACH2 by porting an example model I had for >>>>>> ROACH1. >>>>>> >>>>>> However when I tried to read the dram I got the following error: >>>>>> >>>>>> RuntimeError: Request write failed. >>>>>>Request: ?write dram_controller 0 \0\0\0\0 >>>>>>Reply: !write fail. >>>>>> >>>>>> Someone knows what's the problem? >>>>>> >>>>>> >>>>>> thanks, >>>>>> >>>>>> Franco Curotto >>>>>> >>>>>> >> >> >
Re: [casper] Problem reading DRAM in ROACH2
The register is not present in the bitstream. I thought that the register was inside the dram yellow block though. I have to add it manually or something? Here is the listdev just in case: ['acc_len', 'adc5g_controller', 'cnt_rst', 'dout0_0', 'dout0_1', 'dout0_2', 'dout0_3', 'dout1_0', 'dout1_1', 'dout1_2', 'dout1_3', 'dout2_0', 'dout2_1', 'dout2_2', 'dout2_3', 'filter_gain', 'filter_on', 'snapshot0_bram', 'snapshot0_ctrl', 'snapshot0_status', 'snapshot0_trig_offset', 'snapshot1_bram', 'snapshot1_ctrl', 'snapshot1_status', 'snapshot1_trig_offset', 'sync_gen_sync', 'sync_gen_sync_period_sel', 'sync_gen_sync_period_var', 'sys_board_id', 'sys_clkcounter', 'sys_rev', 'sys_rev_rcs', 'sys_scratchpad', 'write_done'] thanks, Franco On 02/12/16 10:02, Marc Welz wrote: Then there is no bitstream programmed or the particular bitstream doesn't contain that register. Type ?listdev on that connection to find out regards marc On Fri, Dec 2, 2016 at 12:52 PM, Franco <francocuro...@gmail.com> wrote: It says: #log error 1018802834854 raw register\_dram_controller\_not\_defined Franco On 02/12/16 04:32, Marc Welz wrote: telnet to the roach on port 7147 while repeating the operation - what do the #log messages say ? On Thu, Dec 1, 2016 at 3:43 PM, Franco <francocuro...@gmail.com> wrote: Hi! I tried to test the dram of ROACH2 by porting an example model I had for ROACH1. However when I tried to read the dram I got the following error: RuntimeError: Request write failed. Request: ?write dram_controller 0 \0\0\0\0 Reply: !write fail. Someone knows what's the problem? thanks, Franco Curotto
[casper] Problem reading DRAM in ROACH2
Hi! I tried to test the dram of ROACH2 by porting an example model I had for ROACH1. However when I tried to read the dram I got the following error: RuntimeError: Request write failed. Request: ?write dram_controller 0 \0\0\0\0 Reply: !write fail. Someone knows what's the problem? thanks, Franco Curotto
Re: [casper] Question about complex_addsub block
Thanks! That's a relief, for a moment there I doubted my high school math knowledge. Just out of curiosity, how do you check if a block is used by another block in the library? Franco On 10/03/2016 06:14 PM, David MacMahon wrote: Hi, Franco, I can understand your confusion! This block is very unusual. In all fairness, that bock does what it says it will do, but it is unclear what it’s intended purpose is. I think it really computes "a+(b*)" and "-i(a-(b*))". It does not appear to be used by any other blocks in the CASPER library. I think this block should be removed from the library (or modified to match the expectations from its name) unless anyone can justify its continued existence in its current state. Hope this helps, Dave On Oct 3, 2016, at 10:44, Franco <francocuro...@gmail.com <mailto:francocuro...@gmail.com>> wrote: Hi Well I feel a little bit stupid asking this, but from the addsub block: Adds and subtracts the complex inputs. If a = w + ix, b = y + iz then a+b = (w+y)/2 + i(x-z)/2 and a-b = (x+z)/2 + i(y-w)/2 Why it does it like this? Shouldn't it be simply: a+b = w+y + i(x+z) a-b = w-y + i(x-z) I could understand the division by two as a way to avoid overflow, but not the rest of the changes. Franco
[casper] Question about complex_addsub block
Hi Well I feel a little bit stupid asking this, but from the addsub block: Adds and subtracts the complex inputs. If a = w + ix, b = y + iz then a+b = (w+y)/2 + i(x-z)/2 and a-b = (x+z)/2 + i(y-w)/2 Why it does it like this? Shouldn't it be simply: a+b = w+y + i(x+z) a-b = w-y + i(x-z) I could understand the division by two as a way to avoid overflow, but not the rest of the changes. Franco
[casper] Question about complex_addsub block
Hi Well I feel a little bit stupid asking this, but from the addsub block: Adds and subtracts the complex inputs. If a = w + ix, b = y + iz then a+b = (w+y)/2 + i(x-z)/2 and a-b = (x+z)/2 + i(y-w)/2 Why it does it like this? Shouldn't it be simply: a+b = w+y + i(x+z) a-b = w-y + i(x-z) I could understand the division by two as a way to avoid overflow, but not the rest of the changes. Franco
Re: [casper] Snapshot block and DRAM
Thank you Jason, Do you know if the "read_dram()" function would work as well, or should I stick to read()? Franco On 02/08/16 05:46, Jason Manley wrote: Hi Franco You've uncovered a weirdness with the tools: unlike most other blocks, for QDR and DRAM the memory names are static, regardless of design hierarchy or block names. And as you've discovered, the standard snapshot function expects to retrieve the captured data from a contained bram memory. For now, you'll probably want to manually read the dram memory with the normal read() function. And you'll have to unpack it manually. One possible (better) long-term solution might be to have the dram snapshot block be identified with a different xps tag. Then casperfpga can tell it apart and do this automatically for you. Jason On 01 Aug 2016, at 23:43, Franco Curotto <francocuro...@gmail.com> wrote: Dear Casper Community, I'm trying to use the snapshot block with the DRAM as storage medium to save "instantaneous" spectra (in ROACH I). I'm running into troubles when I try to read the snapshot, I used the function "get_snapshot()", but I get an error when the snapshot tries to read the memory as: "?read snapshot_bram 0 8192". So apparently with that function I can only read the bram version of the snapshot: then what is the correct way to read the data from DRAM-snapshot? Sorry if this question is too basic. Thanks, Franco.
[casper] Snapshot block and DRAM
Dear Casper Community, I'm trying to use the snapshot block with the DRAM as storage medium to save "instantaneous" spectra (in ROACH I). I'm running into troubles when I try to read the snapshot, I used the function "get_snapshot()", but I get an error when the snapshot tries to read the memory as: "?read snapshot_bram 0 8192". So apparently with that function I can only read the bram version of the snapshot: then what is the correct way to read the data from DRAM-snapshot? Sorry if this question is too basic. Thanks, Franco.
[casper] ADCs synchronization in ROACH2
Hi all, A few week ago I asked for a way to synchronize the ADCs in ROACH2, so that both ADC take samples in the same instant of time. Jack Hickish suggested using a pulse per second signal in the sync inputs of the ADCs. However I was wondering if there exist a more automated solution. For example has someone programed a Simulink block that has the option to synchronize both ADC in ROACH2, like the ADC083000 block for ROACH1. Any information is welcome! Regards, Franco Curotto -- Franco Curotto Estudiante de Ingeniería Civil Eléctrica Facultad de Ciencias Físicas y Matemáticas Universidad de Chile
[casper] sync ADCs in ROACH2
Hi CASPER community, I'm working with ROACH 2 and I need to synchronize the two ADC so that both take samples at the same instant of time. Does anybody know how can I achieve this synchronization? I've noticed that that the Simulink block model for these ADCs (adc5g), doesn't have the option of using them in interleave mode in the block parameters, contrary to ROACH1 ADC blocks (adc_083000x2). I've also noticed that the ADC boards have a SYNC input, but I don't know how to use it. Thanks, Franco -- Franco Curotto Estudiante de Ingeniería Civil Eléctrica Facultad de Ciencias Físicas y Matemáticas Universidad de Chile
