Re: [casper] ROACH2 sync_out

[Charles Copley]

Hi Michael

I too have used a ROACH 1 gpio to drive a phase switch at KHz rates. Our
system used an optical isolated driver circuit between the GPIO and noise
diode. I'm sure suitable parts could be purchased from an arduino reseller
for next to nothing.

The importance of matching the driver circuit to 50ohms will depend on
where you physically  locate the driver circuit and how fast you need to
drive the noise diode.

On Thu, May 11, 2017 at 11:30 PM, Danny Price  wrote:

> Hi Michael
>
> In the HIPSR system (https://arxiv.org/abs/1702.00443) we use the GPIO on
> a ROACH1 to control the noise diode on the Parkes 64m, so definitely not a
> bad venture! 0.5 Hz should not pose any difficulties.
>
> I would expect to measure closer to 5V (50 ohm terminated), but haven't
> used the ROACH2 GPIO.
>
> Cheers
> Danny
>
> On Thu, May 11, 2017 at 11:10 AM, Michael D'Cruze <
> michael.dcr...@postgrad.manchester.ac.uk> wrote:
>
>> Dear all,
>>
>>
>>
>> I’m planning to use a 0.5Hz square wave, generated from the FPGA and
>> output via sync_out, to eventually fire our cal diode (via much cabling). A
>> quick hardware test today shows the sync_out port driving at circa 7V (!).
>> This is a bit higher than I was expecting. Does this venture as a whole
>> seem like a particularly bad idea to anyone with experience using sync_out?
>> Is this output voltage roughly as expected?
>>
>>
>>
>> Thanks a lot,
>>
>> Michael
>>
>> --
>> 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.
>>
>
>
>
> --
> Danny Price | dan...@berkeley.edu | +1 617-386-3700 <(617)%20386-3700>
>
> --
> 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] Problem in FFT initialisation: coeff_gen_init Library must be saved before creating new library links

[Charles Copley]

Hi all,

If I put a new FFT into the design, I encounter a problem running the
initialisation script with the error message below:

Simulink:Commands:AddBlockUnsavedLibrary: Library must be saved before
creating new library links
Backtrace 1: reuse_block:51
Backtrace 2: coeff_gen_init:410
Backtrace 3: ToggleModelParamAndUpdateCB:486


I see Glen had a similar issue on 8 November 2013, but the final solution
wasn't posted to the mail archive.

I've stepped through the code, and it appears to come from line 51 in
reuse_block.m

add_block(refblk, [blk, '/',name], .

Are there any suggestions as to what I can do to fix this?

Thanks,




http://www.mail-archive.com/search?l=casper@lists.berkeley.eduq=from:%22G+Jones%22
http://www.mail-archive.com/search?l=casper@lists.berkeley.eduq=date:20131118

Charles Copley

Cell: +27 (0) 84 430 1160
 ---

Re: [casper] Operands to the || and operators must be convertible to logical scalar values

[Charles Copley]

Hi Dave, John,

Thanks for the replies. I don't think it was a boolean problem (I initially
suspected this and double checked things with the port update).

Just after I sent the email, I replaced the yellow block register with a
Xilinx constant, and it seemed to compile. I've now replaced the Xilinx
constant with a yellow block register, and now that seems to compile fine-
I may have changed a few things (like the counter output bitwidth), but
nothing major. And I did check that I hadn't accidentally instantiated the
Register  as a 'To Processor' rather than 'From Processor'.

So all in all it is now (pretty bizarrely) working. I have had this happen
before so next time I will look at the sysgen log files as you suggest and
add to this email chain. I'm busy trying to get a version of the file to
repeat the problem.

Thanks for your help!

Charles Copley

Cell: +27 (0) 84 430 1160
 ---


On 9 March 2015 at 18:54, David MacMahon dav...@astro.berkeley.edu wrote:

 Hi, Charles,

 Is it when you click OK on a block's mask dialog or when you run update
 diagram or ???

 Maybe you can find additional details in the model_sysgen.log or
 model_sysgen_warning.log or model_sysgen_error.log files?  It would
 really help to know which block or file is causing this error.

 Thanks,
 Dave


 On Mar 9, 2015, at 6:24 AM, Charles Copley wrote:

  Hi all,
 
  I have a strange error that arises after a small change to a design:
 
  I have used the sync pulse to reset a counter, that in turn (together
 with a comparator coupled to a register) produces a higher frequency pulse
 for use in snap blocks i.e. to write the snap block data more frequently
 than simply using the sync pulse for synchronizing the data to the FFT
 windows.
 
  As soon as I do this I get the error in the subject line:
  Operands to the || and  operators must be convertible to logical
 scalar values
 
  This does not happen if I use the sync pulse directly, without the
 counter.
 
  All the data types are identical after a port update.
 
  Does anyone have this problem with the 2014 July Casper toolflow?
 
  Thanks in advance...
 
 
  Charles Copley
 
  Cell: +27 (0) 84 430 1160
 
 ---
 

[casper] Operands to the || and operators must be convertible to logical scalar values

[Charles Copley]

Hi all,

I have a strange error that arises after a small change to a design:

I have used the sync pulse to reset a counter, that in turn (together with
a comparator coupled to a register) produces a higher frequency pulse for
use in snap blocks i.e. to write the snap block data more frequently than
simply using the sync pulse for synchronizing the data to the FFT windows.

As soon as I do this I get the error in the subject line:
Operands to the || and  operators must be convertible to logical scalar
values

This does not happen if I use the sync pulse directly, without the counter.

All the data types are identical after a port update.

Does anyone have this problem with the 2014 July Casper toolflow?

Thanks in advance...


Charles Copley

Cell: +27 (0) 84 430 1160
 ---

[casper] Simulink freezing after moving blocks

[Charles Copley]

Hi all,

Is anyone else having a problem with Simulink freezing (and remaining
permanently in that state) after dragging/moving something in the design?

I am having this problem using the following configuration:

1) mlib_devel_casper
commit 4c7ba5efb421fda1cec0640cf0e3b830a9987640
Author: David MacMahon dav...@astro.berkeley.edu
Date:   Fri Jul 11 13:35:54 2014 -0700

2) Xilinx version 14.7

3) Matlab 2012b

4) This is running on Ubuntu (which may be the problem?)

Any thoughts/commiseration?

Cheers,




Charles Copley

Cell: +27 (0) 84 430 1160
 ---

Re: [casper] latest mlib_devel wideband FFT on ROACH1 problems

[Charles Copley]

Hi Dave,

Thanks for the reply! Tut3 is now working so now to try the other design.
The update_casper_blocks is a much better solution than it used to be last
I used the toolflow.

Also nice FFT test.

The commit hash for the mlib_devel I was using was the casper-astro
#4c7ba5efb421fda1cec0640cf0e3b830a9987640.





Charles Copley

Cell: +27 (0) 84 430 1160
 ---


On 13 November 2014 10:12, David MacMahon dav...@astro.berkeley.edu wrote:

 Hi, Charles,

 The first thing to do after updating mlib_devel is to run
 update_casper_blocks(bdroot) at the Matlab prompt with your model open
 (so that bdroot returns your model name).  That replaces all of the
 casper blocks with new version from the new mlib_devel.  This usually works
 OK, but if the mlib_devel versions are too different then it might not.

 Another type of problem that can happen is sometimes the latency through
 CASPER blocks changes between different mlib_devel versions.  This is rare,
 but it has happened.  If parts of your design expect other parts to have a
 certain latency and then those other parts end up with a different latency,
 then all kind of things can go wrong.

 If you suspect that the FFT is broken, the best thing to do would be to
 compile a small test model that has just the FFT and some gateway in/out
 blocks.  Feed in a sync pulse and a known input and then see if you get the
 expected output.  For FFT testing, I like to feed in all zeros except for a
 single sample where I feed in 0.5 amplitude impulse.  The output of the FFT
 should be a nice smooth complex sinusoid whose frequency depends on how far
 the input impulse is from the sync.  Putting it two samples after the sync
 should produce a half cycle (for real input FFTs) of a sinusoid.  Putting
 the impulse N samples after the sync should produce (N-1)/2 cycles of a
 complex sinusoid on the (real input) FFT output.  For complex input FFTs,
 putting the impulse N samples after the sync pulse should produce (N-1)
 cycles of a complex sinusoid.

 Which version of mlib_devel are you using now?

 Hope this helps,
 Dave

 On Nov 12, 2014, at 12:29 AM, Charles Copley wrote:

  Hi all,
 
  I've recently (after a long CASPER hiatus) tried to recompile a design
 from 2012 using the latest mlib_devel (from casper-astro git repo), Xilinx
 14.7 and Matlab 2012b.
 
  I find I get very strange results from the PFB/ wideband real FFT.  I
 would describe this vaguely as a lot of zeros, with a very large value
 every 4 channels (FFT size=9). An identical design compiled in 2012 works
 fine.
 
  For a sanity check, I have compiled the tut3 wideband spectrometer
 (using KAT-ADC rather than iADC) and find similar issues (although here the
 pattern is different likely due to the larger FFT size=12?).  A bof file
 from some time ago (also using a KAT-ADC - thanks Jack!) works fine using
 an identical initialization script.
 
  Pretty scruffy power spectrum plots of the old (working) tut3 compile
 with a tone injected (using valon synth 2 at 100MHz) are here :
 http://goo.gl/moqmcs while the new (non-working) compile produces a power
 spectrum shown here : http://goo.gl/4m24p5
 
  I have replaced the PFB/FFTs using the latest versions (with appropriate
 instantiation), and have updated all the register yellow blocks.
 
  Anyone have any suggestions as to what else could be wrong?
 
  Many thanks!!
 
 
 
  Charles Copley
 
  Cell: +27 (0) 84 430 1160
 
 ---
 

[casper] latest mlib_devel wideband FFT on ROACH1 problems

[Charles Copley]

Hi all,

I've recently (after a long CASPER hiatus) tried to recompile a design from
2012 using the latest mlib_devel (from casper-astro git repo), Xilinx 14.7
and Matlab 2012b.

I find I get very strange results from the PFB/ wideband real FFT.  I would
describe this vaguely as a lot of zeros, with a very large value every 4
channels (FFT size=9). An identical design compiled in 2012 works fine.

For a sanity check, I have compiled the tut3 wideband spectrometer (using
KAT-ADC rather than iADC) and find similar issues (although here the
pattern is different likely due to the larger FFT size=12?).  A bof file
from some time ago (also using a KAT-ADC - thanks Jack!) works fine using
an identical initialization script.

Pretty scruffy power spectrum plots of the old (working) tut3 compile with
a tone injected (using valon synth 2 at 100MHz) are here :
http://goo.gl/moqmcs while the new (non-working) compile produces a power
spectrum shown here : http://goo.gl/4m24p5

I have replaced the PFB/FFTs using the latest versions (with appropriate
instantiation), and have updated all the register yellow blocks.

Anyone have any suggestions as to what else could be wrong?

Many thanks!!



Charles Copley

Cell: +27 (0) 84 430 1160
 ---

[casper] C API

[Charles Copley]

Hi all,

We are integrating a ROACH into a C/C++ control framework.

Up to now I have been using the Corr python library for control/monitoring,
however it would be very useful to integrate this directly into the C/C++
library.

Is there any similar C API out there?

-- 
Charles Copley
Oxford Astrophysics
Department of Physics
Denys Wilkinson Building
Keble Road
Oxford, OX1 3RH
Cell: +44 (0) 794 711 1597
Office : +44 (0) 1865 273 348

 ---

[casper] valon linux drivers

[Charles Copley]

Hi all,

There was talk previously about the development of linux drivers for the
Valon 5007 synthesizer boards-

Has there been any progress on this front? It would be most useful to be
able to control the second output for use as a test source-

-- 
Charles Copley
Oxford Astrophysics
Department of Physics
Denys Wilkinson Building
Keble Road
Oxford, OX1 3RH
Cell: +44 (0) 794 711 1597
Office : +44 (0) 1865 273 348

 ---