Re: [casper] Roach2 Tutorial 4 Troubles (Can't Compile .slx or Upload .fpg)

[Jack Hickish]

Hi Alec,

I'm sorry to say I've kinda run out of suggestions. I can't recreate your
problem with my installation. As per my previous email --  with MATLAB
2012b, Xilinx 14.7, and mlib_devel commit 4c7ba5efb4 -- after running
update_casper_blocks everything seems to Just Work.

For what it's worth, I'm running Ubuntu 12.04.4, and my startsg.local file
looks like:

#!/bin/bash
### User to edit these accordingly ##
export MATLAB_PATH=/opt/MATLAB/R2012b
PLATFORM=lin64
export XILINX_PATH=/opt/Xilinx/14.7/ISE_DS
export XILINX_PLATFORM=lin64
export MLIB_DEVEL_PATH=/home/jackh/github/mlib_devel2/mlib_devel
export TMP=/home/jackh/tmp
export TEMP=/home/jackh/tmp
export DSP_CACHE_DIR=/home/jackh/tmp
#

Cheers
Jack



On Fri, 2 Dec 2016 at 12:26 Alec Josaitis  wrote:

> Dear Jack,
>
> I just wanted to follow-up with my last message, about the broken "shared
> bram" connections. Any new suggestions? I hope we're close to resolve this
> issue, as there are no other errors displayed by MATLAB. Thanks for all the
> help you've given, and any more that you may be able to provide!
>
> Best,
> Alec
>
> On Mon, Nov 21, 2016 at 4:31 PM, Alec Josaitis  wrote:
>
> Dear Jack,
>
> Yes, I ran update_casper_blocks(bdroot), which did not resolve the broken
> connections. When I grab a shared bram block directly from my library, the
> connections are also broken., same with the sim_munge connections inside
> the mem block of each shared bram block (shared bram -> mem ). Further, in
> that mem block, there is text which states: "undo data manipulation on way
> in and redo on way out for simulated data". I thought about trying to undo
> and redo connections as prescribed by this message, but I didn't because I
> found a way to resolve all the broken connections, which is described
> below.
>
> Interestingly, I can resolve all of these broken connections (the
> shared_bram connections and the mem connections) by literally dragging a
> new shared bram library block from my library onto the model diagram
> showing the red broken connections, not connecting this just-dragged block
> to anything, and then immediately deleting this just-dragged block. After
> doing that drag-and-delete step, the previous broken links of the model
> become connected.
>
> Unfortunately, even after performing this drag-and-delete operation by
> hand for every shared bram block in either dir_x, I receive the same "||
> and && operator" error described above.
>
> Any new suggestions?
>
> Best,
> Alec
>
> On Sat, Nov 19, 2016 at 4:15 PM, Jack Hickish 
> wrote:
>
> Hi Alec,
>
> And you ran update_casper_blocks(bdroot) after opening your model?
> If you grab a new shared bram block from the library, does that really
> have the same broken connections?
>
> Cheers
> Jack
>
> On Fri, 18 Nov 2016 at 13:40 G Jones  wrote:
>
> The broken connections between blocks are causing your problem. Often that
> happens when the ports on a block change between versions. You will likely
> have to figure out how to connect them back up (perhaps by looking at how
> they're connected before you run the casper_update_blocks script. Not sure
> exactly why they're breaking in your case, but I'd suggest trying to follow
> exactly what Jack did (i.e. using exactly the same model etc.)
>
> Glenn
>
> On Fri, Nov 18, 2016 at 1:05 PM, A. T. Josaitis 
> wrote:
>
> Dear Jack (and the rest of the Casper family),
>
> I just wanted to follow-up with my last message, and see if anyone had
> recommendations for how to correct the shared BRAM errors I'm receiving in
> tutorial 4 (see last message in this thread). The blocks are updated, and
> I've also tried replacing them by hand with the correct blocks in the
> library. Neither updating nor replacing the blocks solves the errors. Other
> thoughts?
>
> Best,
> Alec
>
> On Nov 16, 2016, at 2:41 PM, Alec Josaitis  wrote:
>
> Dear Jack,
>
> So, first of all, my apologies for giving you the wrong file: I was
> actually using poco_wide_r316_new.mdl, because the github says that newer
> file was specificially intended to be used with MATLAB 2012b. You are
> right, poco_wide_12_r316.mdl does not have the black box. However, when I
> update the block diagram for this model, I receive many errors related to
> the shared_bram block; I've attached the error log below. Did you receive
> these errors when you updated your block diagram? I assume not because I
> tried compiling the design via casper_xps and quickly received an error.
>
> I've included a screenshot of the first error, "Error 0001: Undriven input
> port Block: 'poco_wide_12_r316/dir_x0/aa/Shared BRAM/convert_din1'". I
> think this convert_din1 error occured in every instance of the shared BRAM
> blocks in dir_x0 and dir_x1, and you will notice in the screenshot that the
> error appears because of a disconnection between 

Re: [casper] Roach2 Tutorial 4 Troubles (Can't Compile .slx or Upload .fpg)

[Alec Josaitis]

Dear Jack,

I just wanted to follow-up with my last message, about the broken "shared
bram" connections. Any new suggestions? I hope we're close to resolve this
issue, as there are no other errors displayed by MATLAB. Thanks for all the
help you've given, and any more that you may be able to provide!

Best,
Alec

On Mon, Nov 21, 2016 at 4:31 PM, Alec Josaitis  wrote:

> Dear Jack,
>
> Yes, I ran update_casper_blocks(bdroot), which did not resolve the broken
> connections. When I grab a shared bram block directly from my library, the
> connections are also broken., same with the sim_munge connections inside
> the mem block of each shared bram block (shared bram -> mem ). Further, in
> that mem block, there is text which states: "undo data manipulation on way
> in and redo on way out for simulated data". I thought about trying to undo
> and redo connections as prescribed by this message, but I didn't because I
> found a way to resolve all the broken connections, which is described
> below.
>
> Interestingly, I can resolve all of these broken connections (the
> shared_bram connections and the mem connections) by literally dragging a
> new shared bram library block from my library onto the model diagram
> showing the red broken connections, not connecting this just-dragged block
> to anything, and then immediately deleting this just-dragged block. After
> doing that drag-and-delete step, the previous broken links of the model
> become connected.
>
> Unfortunately, even after performing this drag-and-delete operation by
> hand for every shared bram block in either dir_x, I receive the same "||
> and && operator" error described above.
>
> Any new suggestions?
>
> Best,
> Alec
>
> On Sat, Nov 19, 2016 at 4:15 PM, Jack Hickish 
> wrote:
>
>> Hi Alec,
>>
>> And you ran update_casper_blocks(bdroot) after opening your model?
>> If you grab a new shared bram block from the library, does that really
>> have the same broken connections?
>>
>> Cheers
>> Jack
>>
>> On Fri, 18 Nov 2016 at 13:40 G Jones  wrote:
>>
>>> The broken connections between blocks are causing your problem. Often
>>> that happens when the ports on a block change between versions. You will
>>> likely have to figure out how to connect them back up (perhaps by looking
>>> at how they're connected before you run the casper_update_blocks script.
>>> Not sure exactly why they're breaking in your case, but I'd suggest trying
>>> to follow exactly what Jack did (i.e. using exactly the same model etc.)
>>>
>>> Glenn
>>>
>>> On Fri, Nov 18, 2016 at 1:05 PM, A. T. Josaitis 
>>> wrote:
>>>
>>> Dear Jack (and the rest of the Casper family),
>>>
>>> I just wanted to follow-up with my last message, and see if anyone had
>>> recommendations for how to correct the shared BRAM errors I'm receiving in
>>> tutorial 4 (see last message in this thread). The blocks are updated, and
>>> I've also tried replacing them by hand with the correct blocks in the
>>> library. Neither updating nor replacing the blocks solves the errors. Other
>>> thoughts?
>>>
>>> Best,
>>> Alec
>>>
>>> On Nov 16, 2016, at 2:41 PM, Alec Josaitis  wrote:
>>>
>>> Dear Jack,
>>>
>>> So, first of all, my apologies for giving you the wrong file: I was
>>> actually using poco_wide_r316_new.mdl, because the github says that newer
>>> file was specificially intended to be used with MATLAB 2012b. You are
>>> right, poco_wide_12_r316.mdl does not have the black box. However, when I
>>> update the block diagram for this model, I receive many errors related to
>>> the shared_bram block; I've attached the error log below. Did you receive
>>> these errors when you updated your block diagram? I assume not because I
>>> tried compiling the design via casper_xps and quickly received an error.
>>>
>>> I've included a screenshot of the first error, "Error 0001: Undriven
>>> input port Block: 'poco_wide_12_r316/dir_x0/aa/Shared
>>> BRAM/convert_din1'". I think this convert_din1 error occured in every
>>> instance of the shared BRAM blocks in dir_x0 and dir_x1, and you will
>>> notice in the screenshot that the error appears because of a disconnection
>>> between munge_in and convert_din1. Should those blocks really be
>>> disconnected? Do you know why they came disconnected in model?
>>>
>>> Best,
>>> Alec
>>>
>>> On Mon, Nov 14, 2016 at 10:29 PM, Jack Hickish 
>>> wrote:
>>>
>>> Hi Alec,
>>>
>>>
>>> So I have MATLAB 2012b, Xilinx 14.7, and mlib_devel commit
>>> 4c7ba5efb4.
>>>
>>> I cloned the tutorials from github.com/casper-astro/tutorials_devel.git,
>>> and unzipped poco_wide_12_r316.mdl.gz. This model doesn't seem to have any
>>> black boxes in it. I ran update_casper_blocks(bdroot) and some 115 blocks
>>> are found and updated. After that a block diagram update completes OK, with
>>> a few warnings. I'm currently compiling the design via the casper_xps gui,
>>> and so far 

Re: [casper] Roach2 Tutorial 4 Troubles (Can't Compile .slx or Upload .fpg)

[Alec Josaitis]

Dear Jack,

Yes, I ran update_casper_blocks(bdroot), which did not resolve the broken
connections. When I grab a shared bram block directly from my library, the
connections are also broken., same with the sim_munge connections inside
the mem block of each shared bram block (shared bram -> mem ). Further, in
that mem block, there is text which states: "undo data manipulation on way
in and redo on way out for simulated data". I thought about trying to undo
and redo connections as prescribed by this message, but I didn't because I
found a way to resolve all the broken connections, which is described
below.

Interestingly, I can resolve all of these broken connections (the
shared_bram connections and the mem connections) by literally dragging a
new shared bram library block from my library onto the model diagram
showing the red broken connections, not connecting this just-dragged block
to anything, and then immediately deleting this just-dragged block. After
doing that drag-and-delete step, the previous broken links of the model
become connected.

Unfortunately, even after performing this drag-and-delete operation by hand
for every shared bram block in either dir_x, I receive the same "|| and &&
operator" error described above.

Any new suggestions?

Best,
Alec

On Sat, Nov 19, 2016 at 4:15 PM, Jack Hickish  wrote:

> Hi Alec,
>
> And you ran update_casper_blocks(bdroot) after opening your model?
> If you grab a new shared bram block from the library, does that really
> have the same broken connections?
>
> Cheers
> Jack
>
> On Fri, 18 Nov 2016 at 13:40 G Jones  wrote:
>
>> The broken connections between blocks are causing your problem. Often
>> that happens when the ports on a block change between versions. You will
>> likely have to figure out how to connect them back up (perhaps by looking
>> at how they're connected before you run the casper_update_blocks script.
>> Not sure exactly why they're breaking in your case, but I'd suggest trying
>> to follow exactly what Jack did (i.e. using exactly the same model etc.)
>>
>> Glenn
>>
>> On Fri, Nov 18, 2016 at 1:05 PM, A. T. Josaitis 
>> wrote:
>>
>> Dear Jack (and the rest of the Casper family),
>>
>> I just wanted to follow-up with my last message, and see if anyone had
>> recommendations for how to correct the shared BRAM errors I'm receiving in
>> tutorial 4 (see last message in this thread). The blocks are updated, and
>> I've also tried replacing them by hand with the correct blocks in the
>> library. Neither updating nor replacing the blocks solves the errors. Other
>> thoughts?
>>
>> Best,
>> Alec
>>
>> On Nov 16, 2016, at 2:41 PM, Alec Josaitis  wrote:
>>
>> Dear Jack,
>>
>> So, first of all, my apologies for giving you the wrong file: I was
>> actually using poco_wide_r316_new.mdl, because the github says that newer
>> file was specificially intended to be used with MATLAB 2012b. You are
>> right, poco_wide_12_r316.mdl does not have the black box. However, when I
>> update the block diagram for this model, I receive many errors related to
>> the shared_bram block; I've attached the error log below. Did you receive
>> these errors when you updated your block diagram? I assume not because I
>> tried compiling the design via casper_xps and quickly received an error.
>>
>> I've included a screenshot of the first error, "Error 0001: Undriven
>> input port Block: 'poco_wide_12_r316/dir_x0/aa/Shared
>> BRAM/convert_din1'". I think this convert_din1 error occured in every
>> instance of the shared BRAM blocks in dir_x0 and dir_x1, and you will
>> notice in the screenshot that the error appears because of a disconnection
>> between munge_in and convert_din1. Should those blocks really be
>> disconnected? Do you know why they came disconnected in model?
>>
>> Best,
>> Alec
>>
>> On Mon, Nov 14, 2016 at 10:29 PM, Jack Hickish 
>> wrote:
>>
>> Hi Alec,
>>
>>
>> So I have MATLAB 2012b, Xilinx 14.7, and mlib_devel commit 4c7ba5efb4.
>>
>> I cloned the tutorials from github.com/casper-astro/tutorials_devel.git,
>> and unzipped poco_wide_12_r316.mdl.gz. This model doesn't seem to have any
>> black boxes in it. I ran update_casper_blocks(bdroot) and some 115 blocks
>> are found and updated. After that a block diagram update completes OK, with
>> a few warnings. I'm currently compiling the design via the casper_xps gui,
>> and so far nothing seems amiss.
>>
>> Cheers
>> Jack
>>
>> On Mon, 14 Nov 2016 at 17:43 Alec Josaitis  wrote:
>>
>> Dear Jack,
>>
>> Yup, I was working with  poco_wide_12_r316.mdl. The only substantive
>> change I can recall is replacing the Xilinx Black Box version of the 
>> pfb_fir_generic
>> to the one in the DSP blockset, programmed as specified in the tutorial
>> .
>> (because, a fellow Casperite thought the reason I was facing previous XSG

Re: [casper] Roach2 Tutorial 4 Troubles (Can't Compile .slx or Upload .fpg)

[G Jones]

The broken connections between blocks are causing your problem. Often that
happens when the ports on a block change between versions. You will likely
have to figure out how to connect them back up (perhaps by looking at how
they're connected before you run the casper_update_blocks script. Not sure
exactly why they're breaking in your case, but I'd suggest trying to follow
exactly what Jack did (i.e. using exactly the same model etc.)

Glenn

On Fri, Nov 18, 2016 at 1:05 PM, A. T. Josaitis  wrote:

> Dear Jack (and the rest of the Casper family),
>
> I just wanted to follow-up with my last message, and see if anyone had
> recommendations for how to correct the shared BRAM errors I'm receiving in
> tutorial 4 (see last message in this thread). The blocks are updated, and
> I've also tried replacing them by hand with the correct blocks in the
> library. Neither updating nor replacing the blocks solves the errors. Other
> thoughts?
>
> Best,
> Alec
>
> On Nov 16, 2016, at 2:41 PM, Alec Josaitis  wrote:
>
> Dear Jack,
>
> So, first of all, my apologies for giving you the wrong file: I was
> actually using poco_wide_r316_new.mdl, because the github says that newer
> file was specificially intended to be used with MATLAB 2012b. You are
> right, poco_wide_12_r316.mdl does not have the black box. However, when I
> update the block diagram for this model, I receive many errors related to
> the shared_bram block; I've attached the error log below. Did you receive
> these errors when you updated your block diagram? I assume not because I
> tried compiling the design via casper_xps and quickly received an error.
>
> I've included a screenshot of the first error, "Error 0001: Undriven input
> port Block: 'poco_wide_12_r316/dir_x0/aa/Shared BRAM/convert_din1'". I
> think this convert_din1 error occured in every instance of the shared BRAM
> blocks in dir_x0 and dir_x1, and you will notice in the screenshot that the
> error appears because of a disconnection between munge_in and convert_din1.
> Should those blocks really be disconnected? Do you know why they came
> disconnected in model?
>
> Best,
> Alec
>
> On Mon, Nov 14, 2016 at 10:29 PM, Jack Hickish 
> wrote:
>
>> Hi Alec,
>>
>>
>> So I have MATLAB 2012b, Xilinx 14.7, and mlib_devel commit 4c7ba5efb4.
>>
>> I cloned the tutorials from github.com/casper-astro/tutorials_devel.git,
>> and unzipped poco_wide_12_r316.mdl.gz. This model doesn't seem to have any
>> black boxes in it. I ran update_casper_blocks(bdroot) and some 115 blocks
>> are found and updated. After that a block diagram update completes OK, with
>> a few warnings. I'm currently compiling the design via the casper_xps gui,
>> and so far nothing seems amiss.
>>
>> Cheers
>> Jack
>>
>> On Mon, 14 Nov 2016 at 17:43 Alec Josaitis  wrote:
>>
>>> Dear Jack,
>>>
>>> Yup, I was working with  poco_wide_12_r316.mdl. The only substantive
>>> change I can recall is replacing the Xilinx Black Box version of the 
>>> pfb_fir_generic
>>> to the one in the DSP blockset, programmed as specified in the tutorial
>>> .
>>> (because, a fellow Casperite thought the reason I was facing previous XSG
>>> config errors was due to this black box).
>>>
>>>
>>> Thanks for the help with recreating this problem! For reference, I'm
>>> using the mlib_devel git commit 4c7ba5efb4
>>> 
>>> .
>>>
>>>
>>> Best,
>>> Alec
>>>
>>> On Mon, Nov 14, 2016 at 7:52 PM, Jack Hickish 
>>> wrote:
>>>
>>> Hi Alec,
>>>
>>> That's a fun one. Is this the vanilla tut4 design after running
>>> update_casper_blocks? I can try and recreate the problem here
>>>
>>> Cheers
>>> Jack
>>>
>>> On Mon, 14 Nov 2016 at 16:35 Alec Josaitis  wrote:
>>>
>>> Dear Dave and Glenn,
>>>
>>> You were both correct, my MLIB_DEVEL_PATH returned any empty string; the
>>> variable was never set. I'm amazed I got to tutorial 4 without that mistake
>>> making itself present! I am now able to implement the green blocks as
>>> expected, and when I run the Simulation -> Update Diagram command, I do not
>>> receive any errors in a .log file. Indeed no error.log is even generated
>>> (as they had previously). However, I am still unable to compile the .slx
>>> file because of the following error:
>>>
>>> Operands to the || and && operators must be convertible to logical
>>> scalar values.
>>>
>>>
>>>
>>> I've checked the Casper Archive and noticed someone else having a
>>> similar problem
>>> ,
>>> but there wasn't a clear resolution and I'm not quite sure how to fix this. 
>>> This
>>> link
>>> 
>>> provides the warning statements 

Re: [casper] Roach2 Tutorial 4 Troubles (Can't Compile .slx or Upload .fpg)

[A. T. Josaitis]

Dear Jack (and the rest of the Casper family), 

I just wanted to follow-up with my last message, and see if anyone had 
recommendations for how to correct the shared BRAM errors I'm receiving in 
tutorial 4 (see last message in this thread). The blocks are updated, and I've 
also tried replacing them by hand with the correct blocks in the library. 
Neither updating nor replacing the blocks solves the errors. Other thoughts?

Best, 
Alec

> On Nov 16, 2016, at 2:41 PM, Alec Josaitis  wrote:
> 
> Dear Jack,
> 
> So, first of all, my apologies for giving you the wrong file: I was actually 
> using poco_wide_r316_new.mdl, because the github says that newer file was 
> specificially intended to be used with MATLAB 2012b. You are right, 
> poco_wide_12_r316.mdl does not have the black box. However, when I update the 
> block diagram for this model, I receive many errors related to the 
> shared_bram block; I've attached the error log below. Did you receive these 
> errors when you updated your block diagram? I assume not because I tried 
> compiling the design via casper_xps and quickly received an error. 
> 
> I've included a screenshot of the first error, "Error 0001: Undriven input 
> port Block: 'poco_wide_12_r316/dir_x0/aa/Shared BRAM/convert_din1'". I think 
> this convert_din1 error occured in every instance of the shared BRAM blocks 
> in dir_x0 and dir_x1, and you will notice in the screenshot that the error 
> appears because of a disconnection between munge_in and convert_din1. Should 
> those blocks really be disconnected? Do you know why they came disconnected 
> in model?  
> 
> Best,
> Alec
> 
>> On Mon, Nov 14, 2016 at 10:29 PM, Jack Hickish  wrote:
>> Hi Alec,
>> 
>> 
>> So I have MATLAB 2012b, Xilinx 14.7, and mlib_devel commit 4c7ba5efb4.
>> 
>> I cloned the tutorials from github.com/casper-astro/tutorials_devel.git, and 
>> unzipped poco_wide_12_r316.mdl.gz. This model doesn't seem to have any black 
>> boxes in it. I ran update_casper_blocks(bdroot) and some 115 blocks are 
>> found and updated. After that a block diagram update completes OK, with a 
>> few warnings. I'm currently compiling the design via the casper_xps gui, and 
>> so far nothing seems amiss.
>> 
>> Cheers
>> Jack
>> 
>>> On Mon, 14 Nov 2016 at 17:43 Alec Josaitis  wrote:
>>> Dear Jack,
>>> 
>>> Yup, I was working with  poco_wide_12_r316.mdl. The only substantive change 
>>> I can recall is replacing the Xilinx Black Box version of the 
>>> pfb_fir_generic to the one in the DSP blockset, programmed as specified in 
>>> the tutorial. (because, a fellow Casperite thought the reason I was facing 
>>> previous XSG config errors was due to this black box). 
>>> 
>>> 
>>> Thanks for the help with recreating this problem! For reference, I'm using 
>>> the mlib_devel git commit 4c7ba5efb4.
>>> 
>>> 
>>> Best,
>>> Alec
>>> 
>>> On Mon, Nov 14, 2016 at 7:52 PM, Jack Hickish  wrote:
>>> Hi Alec,
>>> 
>>> That's a fun one. Is this the vanilla tut4 design after running 
>>> update_casper_blocks? I can try and recreate the problem here
>>> 
>>> Cheers
>>> Jack
>>> 
>>> On Mon, 14 Nov 2016 at 16:35 Alec Josaitis  wrote:
>>> Dear Dave and Glenn,
>>> 
>>> You were both correct, my MLIB_DEVEL_PATH returned any empty string; the 
>>> variable was never set. I'm amazed I got to tutorial 4 without that mistake 
>>> making itself present! I am now able to implement the green blocks as 
>>> expected, and when I run the Simulation -> Update Diagram command, I do not 
>>> receive any errors in a .log file. Indeed no error.log is even generated 
>>> (as they had previously). However, I am still unable to compile the .slx 
>>> file because of the following error: 
>>> 
>>> Operands to the || and && operators must be convertible to logical scalar 
>>> values.
>>> 
>>> 
>>> I've checked the Casper Archive and noticed someone else having a similar 
>>> problem, but there wasn't a clear resolution and I'm not quite sure how to 
>>> fix this. This link provides the warning statements offered by MATLAB while 
>>> running System -> Update Diagram (and again, this is all I have because no 
>>> error log file was created). Do you have a suggestion on what could be 
>>> causing this issue? 
>>> 
>>> Thank you all again for your recent and productive help!
>>> 
>>> Best,
>>> Alec
>>> 
>>> 
>>> On Thu, Nov 10, 2016 at 5:12 PM, David MacMahon  wrote:
>>> Hi, Alec,
>>> 
>>> I suspect your MLIB_DEVEL_PATH environment variable is not getting set.  
>>> This error message...
>>> 
 An error or warning occurred during a callback while saving 
 '/casper_library/casper_library_bus.slx'.
>>> 
>>> …shows that matlab is trying to save the casper_library_bus.slx file in 
>>> "/casper_library" (i.e. one level down from the root directory).  I suspect 
>>> that’s not really where you’re mlib_devel lives.  The matlab code that 
>>> 

Re: [casper] Roach2 Tutorial 4 Troubles (Can't Compile .slx or Upload .fpg)

[Jack Hickish]

Hi Alec,


So I have MATLAB 2012b, Xilinx 14.7, and mlib_devel commit 4c7ba5efb4.

I cloned the tutorials from github.com/casper-astro/tutorials_devel.git,
and unzipped poco_wide_12_r316.mdl.gz. This model doesn't seem to have any
black boxes in it. I ran update_casper_blocks(bdroot) and some 115 blocks
are found and updated. After that a block diagram update completes OK, with
a few warnings. I'm currently compiling the design via the casper_xps gui,
and so far nothing seems amiss.

Cheers
Jack

On Mon, 14 Nov 2016 at 17:43 Alec Josaitis  wrote:

> Dear Jack,
>
> Yup, I was working with  poco_wide_12_r316.mdl. The only substantive
> change I can recall is replacing the Xilinx Black Box version of the 
> pfb_fir_generic
> to the one in the DSP blockset, programmed as specified in the tutorial
> .
> (because, a fellow Casperite thought the reason I was facing previous XSG
> config errors was due to this black box).
>
>
> Thanks for the help with recreating this problem! For reference, I'm using
> the mlib_devel git commit 4c7ba5efb4
> 
> .
>
>
> Best,
> Alec
>
> On Mon, Nov 14, 2016 at 7:52 PM, Jack Hickish 
> wrote:
>
> Hi Alec,
>
> That's a fun one. Is this the vanilla tut4 design after running
> update_casper_blocks? I can try and recreate the problem here
>
> Cheers
> Jack
>
> On Mon, 14 Nov 2016 at 16:35 Alec Josaitis  wrote:
>
> Dear Dave and Glenn,
>
> You were both correct, my MLIB_DEVEL_PATH returned any empty string; the
> variable was never set. I'm amazed I got to tutorial 4 without that mistake
> making itself present! I am now able to implement the green blocks as
> expected, and when I run the Simulation -> Update Diagram command, I do not
> receive any errors in a .log file. Indeed no error.log is even generated
> (as they had previously). However, I am still unable to compile the .slx
> file because of the following error:
>
> Operands to the || and && operators must be convertible to logical scalar
> values.
>
>
>
> I've checked the Casper Archive and noticed someone else having a similar
> problem
> ,
> but there wasn't a clear resolution and I'm not quite sure how to fix this. 
> This
> link
> 
> provides the warning statements offered by MATLAB while running System ->
> Update Diagram (and again, this is all I have because no error log file was
> created). Do you have a suggestion on what could be causing this issue?
>
>
> Thank you all again for your recent and productive help!
>
>
> Best,
>
> Alec
>
>
>
> On Thu, Nov 10, 2016 at 5:12 PM, David MacMahon 
> wrote:
>
> Hi, Alec,
>
> I suspect your MLIB_DEVEL_PATH environment variable is not getting set.
> This error message...
>
> An error or warning occurred during a callback while saving
> '/casper_library/casper_library_bus.slx'.
>
>
> …shows that matlab is trying to save the casper_library_bus.slx file in
> "/casper_library" (i.e. one level down from the root directory).  I suspect
> that’s not really where you’re mlib_devel lives.  The matlab code that
> writes this file is shown in this part of the error message...
>
> Error in casper_library_bus_init (line 285)
> filename = save_system(mdl,[getenv('MLIB_DEVEL_PATH'),
> '/casper_library/', 'casper_library_bus']);
>
>
> As you can see, if "getenv('MLIB_DEVEL_PATH')" returns an empty string,
> the the file name which will be used is
> "/casper_library/casper_library_bus" (plus any extension that gets added by
> matlab/simulink).  This is the path that is being used (see previous error
> message) so that indicates that MLIB_DEVEL_PATH is not being set in your
> environment (or maybe set but not "exported").  I think this is supposed to
> happen automatically as part of the "startsg" script.
>
> HTH,
> Dave
>
>
>
>

Re: [casper] Roach2 Tutorial 4 Troubles (Can't Compile .slx or Upload .fpg)

[Alec Josaitis]

Dear Jack,

Yup, I was working with  poco_wide_12_r316.mdl. The only substantive change
I can recall is replacing the Xilinx Black Box version of the pfb_fir_generic
to the one in the DSP blockset, programmed as specified in the tutorial
.
(because, a fellow Casperite thought the reason I was facing previous XSG
config errors was due to this black box).


Thanks for the help with recreating this problem! For reference, I'm using
the mlib_devel git commit 4c7ba5efb4

.


Best,
Alec

On Mon, Nov 14, 2016 at 7:52 PM, Jack Hickish  wrote:

> Hi Alec,
>
> That's a fun one. Is this the vanilla tut4 design after running
> update_casper_blocks? I can try and recreate the problem here
>
> Cheers
> Jack
>
> On Mon, 14 Nov 2016 at 16:35 Alec Josaitis  wrote:
>
> Dear Dave and Glenn,
>
> You were both correct, my MLIB_DEVEL_PATH returned any empty string; the
> variable was never set. I'm amazed I got to tutorial 4 without that mistake
> making itself present! I am now able to implement the green blocks as
> expected, and when I run the Simulation -> Update Diagram command, I do not
> receive any errors in a .log file. Indeed no error.log is even generated
> (as they had previously). However, I am still unable to compile the .slx
> file because of the following error:
>
> Operands to the || and && operators must be convertible to logical scalar
> values.
>
>
>
> I've checked the Casper Archive and noticed someone else having a similar
> problem
> ,
> but there wasn't a clear resolution and I'm not quite sure how to fix this. 
> This
> link
> 
> provides the warning statements offered by MATLAB while running System ->
> Update Diagram (and again, this is all I have because no error log file was
> created). Do you have a suggestion on what could be causing this issue?
>
>
> Thank you all again for your recent and productive help!
>
>
> Best,
>
> Alec
>
>
>
> On Thu, Nov 10, 2016 at 5:12 PM, David MacMahon 
> wrote:
>
> Hi, Alec,
>
> I suspect your MLIB_DEVEL_PATH environment variable is not getting set.
> This error message...
>
> An error or warning occurred during a callback while saving
> '/casper_library/casper_library_bus.slx'.
>
>
> …shows that matlab is trying to save the casper_library_bus.slx file in
> "/casper_library" (i.e. one level down from the root directory).  I suspect
> that’s not really where you’re mlib_devel lives.  The matlab code that
> writes this file is shown in this part of the error message...
>
> Error in casper_library_bus_init (line 285)
> filename = save_system(mdl,[getenv('MLIB_DEVEL_PATH'),
> '/casper_library/', 'casper_library_bus']);
>
>
> As you can see, if "getenv('MLIB_DEVEL_PATH')" returns an empty string,
> the the file name which will be used is "/casper_library/casper_library_bus"
> (plus any extension that gets added by matlab/simulink).  This is the path
> that is being used (see previous error message) so that indicates that
> MLIB_DEVEL_PATH is not being set in your environment (or maybe set but not
> "exported").  I think this is supposed to happen automatically as part of
> the "startsg" script.
>
> HTH,
> Dave
>
>
>

Re: [casper] Roach2 Tutorial 4 Troubles (Can't Compile .slx or Upload .fpg)

[Alec Josaitis]

Dear Dave and Glenn,

You were both correct, my MLIB_DEVEL_PATH returned any empty string; the
variable was never set. I'm amazed I got to tutorial 4 without that mistake
making itself present! I am now able to implement the green blocks as
expected, and when I run the Simulation -> Update Diagram command, I do not
receive any errors in a .log file. Indeed no error.log is even generated
(as they had previously). However, I am still unable to compile the .slx
file because of the following error:

Operands to the || and && operators must be convertible to logical scalar
values.



I've checked the Casper Archive and noticed someone else having a similar
problem
, but
there wasn't a clear resolution and I'm not quite sure how to fix this. This
link

provides the warning statements offered by MATLAB while running System ->
Update Diagram (and again, this is all I have because no error log file was
created). Do you have a suggestion on what could be causing this issue?


Thank you all again for your recent and productive help!


Best,

Alec



On Thu, Nov 10, 2016 at 5:12 PM, David MacMahon  wrote:

> Hi, Alec,
>
> I suspect your MLIB_DEVEL_PATH environment variable is not getting set.
> This error message...
>
> An error or warning occurred during a callback while saving
> '/casper_library/casper_library_bus.slx'.
>
>
> …shows that matlab is trying to save the casper_library_bus.slx file in
> "/casper_library" (i.e. one level down from the root directory).  I suspect
> that’s not really where you’re mlib_devel lives.  The matlab code that
> writes this file is shown in this part of the error message...
>
> Error in casper_library_bus_init (line 285)
> filename = save_system(mdl,[getenv('MLIB_DEVEL_PATH'),
> '/casper_library/', 'casper_library_bus']);
>
>
> As you can see, if "getenv('MLIB_DEVEL_PATH')" returns an empty string,
> the the file name which will be used is "/casper_library/casper_library_bus"
> (plus any extension that gets added by matlab/simulink).  This is the path
> that is being used (see previous error message) so that indicates that
> MLIB_DEVEL_PATH is not being set in your environment (or maybe set but not
> "exported").  I think this is supposed to happen automatically as part of
> the "startsg" script.
>
> HTH,
> Dave
>
>

Re: [casper] Roach2 Tutorial 4 Troubles (Can't Compile .slx or Upload .fpg)

[David MacMahon]

Hi, Alec,

I suspect your MLIB_DEVEL_PATH environment variable is not getting set.  This 
error message...

> An error or warning occurred during a callback while saving 
> '/casper_library/casper_library_bus.slx'.

…shows that matlab is trying to save the casper_library_bus.slx file in 
"/casper_library" (i.e. one level down from the root directory).  I suspect 
that’s not really where you’re mlib_devel lives.  The matlab code that writes 
this file is shown in this part of the error message...

> Error in casper_library_bus_init (line 285)
> filename = save_system(mdl,[getenv('MLIB_DEVEL_PATH'), 
> '/casper_library/', 'casper_library_bus']);

As you can see, if "getenv('MLIB_DEVEL_PATH')" returns an empty string, the the 
file name which will be used is "/casper_library/casper_library_bus" (plus any 
extension that gets added by matlab/simulink).  This is the path that is being 
used (see previous error message) so that indicates that MLIB_DEVEL_PATH is not 
being set in your environment (or maybe set but not "exported").  I think this 
is supposed to happen automatically as part of the "startsg" script.

HTH,
Dave

Re: [casper] Roach2 Tutorial 4 Troubles (Can't Compile .slx or Upload .fpg)

[G Jones]

You don't need to run the *_init.m files yourself, matlab does that for you.

Click the  "set path" button in matlab and make sure you see the directory
that will be something like .../mlib_devel/casper_library

I suspect that you don't have your startsg.local or startup.m

at the matlab prompt, what does
getenv('MLIB_DEVEL_PATH')
return?

It should point at your mlib_devel directory.

Glenn

On Thu, Nov 10, 2016 at 4:56 PM, Alec Josaitis  wrote:

> Dear Glenn,
>
> In trying to get to the root of this issue, I've started digging through
> the Casper Library files. In what seems to be the principle .mdl file,
> "casper_library.mdl", I notice that the first actions done are to load
> other .mdl files, such as "casper_library_ffts.mdl", and
> "casper_library_pfbs.mdl", and I assume that inside that inside these .mdl
> files are where the respective library blocks are instantiated. Inside the
> casper_library folder of my mlib_devel, I do indeed see the .dl files
> labelled ""casper_library_ffts". "casper_library_pfbs", etc. However, I do
> NOT see one labelled "casper_library_bus", but this is what is called in
> the "casper_library.mdl" file.
>
> I do see, however, a file called 'casper_library_bus_init.m'. This,
> according to the mlib_devel Github, is supposed to " Save auto-generated
> models as MDL files
> ".
> When I tried running this script in Matlab (not sure if I should do this,
> but I did...), I receive the following errors:
>
> >> casper_library_bus_init
> Warning: Error evaluating 'PreSaveFcn' callback of block_diagram
> 'casper_library_bus'.
> Warning: error opening '/casper_library/casper_library_bus_init'
> Error using save_system (line 38)
> An error or warning occurred during a callback while saving
> '/casper_library/casper_library_bus.slx'. The previously saved version of
> this file (if any) has not been
> changed
>
> Error in casper_library_bus_init (line 285)
> filename = save_system(mdl,[getenv('MLIB_DEVEL_PATH'),
> '/casper_library/', 'casper_library_bus']);
>
> Best,
> Alec
>
> On Thu, Nov 10, 2016 at 4:26 PM, Alec Josaitis  wrote:
>
>> Dear Glenn,
>>
>> I've never been able to easily browse the DSP blockset in the Simulink
>> library browser, like I can the XPS blockset. The photos below will explain
>> what I mean, but for posterity (in writing), I will say that the sidebar of
>> the Simulink browser easily allows me to peruse the XPS blocks, which
>> appear by name, but the DSP blockset never generates images, and Simulink
>> says the blockset contains "No blocks", but nevertheless I can open the DSP
>> blockset library and all of the blocks/sub-libraries (*except
>> "Downconverter" and "Bus") * are there, empty, but can still be
>> implemented into a model.  When I click on  the Casper DSP "Bus" library to
>> see what is inside, the following error appears:
>>
>> --> Error evaluating 'OpenFcn' callback of SubSystem block
>> 'casper_library/Bus'. -->Undefined function or variable
>> 'casper_library_bus'.
>> ​So, it looks as though I don't actually have access to the bus library.
>> Do you have suggestions on how to fix that, aside from re-downloading the
>> entire mlib_devel library?
>>
>> Best,
>> Alec​
>>
>> On Wed, Nov 9, 2016 at 10:03 PM, G Jones  wrote:
>>
>>> Hi Alec,
>>> I was working from memory and got it wrong: the library paths are in
>>> startup.m but shouldn't need to be modified. Are you running ./startsg in
>>> your casper toolflow git directory? When you open the simulink library
>>> browser, can you browse to CASPER DSP Blockset -> bus ?
>>> Glenn
>>>
>>> On Wed, Nov 9, 2016 at 6:08 PM, G Jones  wrote:
>>>
 Something is not quite right with your library path setup. Did you
 modify the startsg.sh local script to properly point to your casper
 libraries? You definitely should have the casper bus library if things are
 set up properly.

 Glenn
 On Nov 9, 2016 5:59 PM, "Alec Josaitis"  wrote:

> Dear Glenn,
>
> Yes, update_casper_blocks appears to run succesfully. First I ran it
> inasmuch as it said at the end "done updating  blocks in ",
> but it does issue warnings at some points. See below.
>
> First, I tried updating my library, and at some point received this:
> updating block xps_library/Shared BRAM/mem/sim_munge_in...
> Simulink:Libraries:RefModificationViolation: Attempt to modify block
> in a linked subsystem. This can only be done by the block or its parent
> through their mask initialization code
> Backtrace 1: reuse_block:51
> Backtrace 2: munge_init:131
> Backtrace 3: shared_bram_mask:119
> Backtrace 4: update_casper_block:161
> Backtrace 5: update_casper_blocks:107
>
> Now, after updating my library, I ran the script on the .slx file
> 

Re: [casper] Roach2 Tutorial 4 Troubles (Can't Compile .slx or Upload .fpg)

[G Jones]

Something is not quite right with your library path setup. Did you modify
the startsg.sh local script to properly point to your casper libraries? You
definitely should have the casper bus library if things are set up properly.

Glenn
On Nov 9, 2016 5:59 PM, "Alec Josaitis"  wrote:

> Dear Glenn,
>
> Yes, update_casper_blocks appears to run succesfully. First I ran it
> inasmuch as it said at the end "done updating  blocks in ",
> but it does issue warnings at some points. See below.
>
> First, I tried updating my library, and at some point received this:
> updating block xps_library/Shared BRAM/mem/sim_munge_in...
> Simulink:Libraries:RefModificationViolation: Attempt to modify block in a
> linked subsystem. This can only be done by the block or its parent through
> their mask initialization code
> Backtrace 1: reuse_block:51
> Backtrace 2: munge_init:131
> Backtrace 3: shared_bram_mask:119
> Backtrace 4: update_casper_block:161
> Backtrace 5: update_casper_blocks:107
>
> Now, after updating my library, I ran the script on the .slx file
> (poco_wide_12_r316_new); it also completes successfully but only after
> providing these warning messages:
> updating block poco_wide_12_r316_new/fft_wideband_real...
> loading library casper_library_ffts
> MATLAB:MException:MultipleErrors: Error due to multiple causes.
> Backtrace 1: reuse_block:51
> Backtrace 2: fft_stage_n_init:287
> Backtrace 3: reuse_block:51
> Backtrace 4: biplex_core_init:173
> Backtrace 5: reuse_block:51
> Backtrace 6: fft_biplex_real_4x_init:235
> Backtrace 7: reuse_block:51
> Backtrace 8: fft_wideband_real_init:257
> Backtrace 9: update_casper_block:161
> Backtrace 10: update_casper_blocks:107
>
> I then updated my system diagram as you recommended, and received the
> following errors:
>
> Error in 'poco_wide_12_r316_new/fft_wideband_real/fft_biplex_real_4x':
> Initialization commands cannot be evaluated.
>
> Caused by:
> Error in 'poco_wide_12_r316_new/fft_wideband_real/fft_biplex_real_
> 4x/biplex_core': Initialization commands cannot be evaluated.
> Error in 'poco_wide_12_r316_new/fft_wideband_real/fft_biplex_real_
> 4x/biplex_core/fft_stage_1': Initialization commands cannot be evaluated.
> Error due to multiple causes.
> Unable to load block diagram 'casper_library_bus'
> There is no block named 'casper_library_bus/bus_single_port_ram'
> Do you have a recommendation on how to fix this error?
>
>
> Best,
> Alec
>
> On Mon, Nov 7, 2016 at 10:03 PM, G Jones  wrote:
>
>> Hi Alec,
>> Before running casper_xps, update your system diagram (Simulation menu ->
>> Update Diagram).
>> That should pop up messages indicating where the errors are.
>> The error messages you copied sound like there is still some
>> incompatibility between the model and your libraries. Did
>> update_casper_blocks run successfully?
>>
>> Glenn
>>
>> On Mon, Nov 7, 2016 at 6:39 PM, Alec Josaitis  wrote:
>>
>>> Dear All,
>>>
>>> My apologies, above I meant to include the following hyperlink when I
>>> stated "...this .mdl
>>> ".
>>> Also, to clarify, I am indeed using the tutorial- recommended versions of
>>> software: Xilinx System Generator 14.7 and MATLAB 2012b.
>>>
>>> Best,
>>> Alec
>>>
>>> On Mon, Nov 7, 2016 at 6:34 PM, Alec Josaitis 
>>> wrote:
>>>
 Dear Glenn and Jack,

 Thanks for the response. I've re-cloned mlib_devel and checked-out the
 proper version ( 4c7ba5efb4
 ).
 I then re-downloaded, and un-tarred this .mdl, saved is as a .slx, and then
 opened it in matlab to run update_casper_blocks(bdroot).
 I've copied below the errors that appear. Also, I should note there are
 no .log files in any of the subdirectories inside the directory created by
 casper_xps.

 >> casper_xps
 Detected Linux OS
 #
 ##  System Update  ##
 #
 MATLAB:MException:MultipleErrors: Error due to multiple causes.
 Backtrace 1: reuse_block:51
 Backtrace 2: fft_stage_n_init:287
 Backtrace 3: reuse_block:138
 Backtrace 4: biplex_core_init:173
 Backtrace 5: reuse_block:138
 Backtrace 6: fft_biplex_real_4x_init:235
 Backtrace 7: gen_xps_files:203
 Backtrace 8: run_Callback:155
 Backtrace 9: casper_xps:88
 Backtrace 10: @(hObject,eventdata)casper_xps
 ('run_Callback',hObject,eventdata,guidata(hObject)):0
 Simulink:Masking:Bad_Init_Commands: Error in
 'poco_wide_12_r316_new/fft_wideband_real/fft_biplex_real_4x/biplex_core/fft_stage_1':
 Initialization commands cannot be evaluated.
 Backtrace 1: reuse_block:138
 Backtrace 2: biplex_core_init:173
 Backtrace 3: reuse_block:138
 Backtrace 4: fft_biplex_real_4x_init:235
 

Re: [casper] Roach2 Tutorial 4 Troubles (Can't Compile .slx or Upload .fpg)

[Alec Josaitis]

Dear Glenn,

Yes, update_casper_blocks appears to run succesfully. First I ran it
inasmuch as it said at the end "done updating  blocks in ",
but it does issue warnings at some points. See below.

First, I tried updating my library, and at some point received this:
updating block xps_library/Shared BRAM/mem/sim_munge_in...
Simulink:Libraries:RefModificationViolation: Attempt to modify block in a
linked subsystem. This can only be done by the block or its parent through
their mask initialization code
Backtrace 1: reuse_block:51
Backtrace 2: munge_init:131
Backtrace 3: shared_bram_mask:119
Backtrace 4: update_casper_block:161
Backtrace 5: update_casper_blocks:107

Now, after updating my library, I ran the script on the .slx file
(poco_wide_12_r316_new); it also completes successfully but only after
providing these warning messages:
updating block poco_wide_12_r316_new/fft_wideband_real...
loading library casper_library_ffts
MATLAB:MException:MultipleErrors: Error due to multiple causes.
Backtrace 1: reuse_block:51
Backtrace 2: fft_stage_n_init:287
Backtrace 3: reuse_block:51
Backtrace 4: biplex_core_init:173
Backtrace 5: reuse_block:51
Backtrace 6: fft_biplex_real_4x_init:235
Backtrace 7: reuse_block:51
Backtrace 8: fft_wideband_real_init:257
Backtrace 9: update_casper_block:161
Backtrace 10: update_casper_blocks:107

I then updated my system diagram as you recommended, and received the
following errors:

Error in 'poco_wide_12_r316_new/fft_wideband_real/fft_biplex_real_4x':
Initialization commands cannot be evaluated.

Caused by:
Error in '
poco_wide_12_r316_new/fft_wideband_real/fft_biplex_real_4x/biplex_core':
Initialization commands cannot be evaluated.
Error in '
poco_wide_12_r316_new/fft_wideband_real/fft_biplex_real_4x/biplex_core/fft_stage_1':
Initialization commands cannot be evaluated.
Error due to multiple causes.
Unable to load block diagram 'casper_library_bus'
There is no block named 'casper_library_bus/bus_single_port_ram'
Do you have a recommendation on how to fix this error?


Best,
Alec

On Mon, Nov 7, 2016 at 10:03 PM, G Jones  wrote:

> Hi Alec,
> Before running casper_xps, update your system diagram (Simulation menu ->
> Update Diagram).
> That should pop up messages indicating where the errors are.
> The error messages you copied sound like there is still some
> incompatibility between the model and your libraries. Did
> update_casper_blocks run successfully?
>
> Glenn
>
> On Mon, Nov 7, 2016 at 6:39 PM, Alec Josaitis  wrote:
>
>> Dear All,
>>
>> My apologies, above I meant to include the following hyperlink when I
>> stated "...this .mdl
>> ".
>> Also, to clarify, I am indeed using the tutorial- recommended versions of
>> software: Xilinx System Generator 14.7 and MATLAB 2012b.
>>
>> Best,
>> Alec
>>
>> On Mon, Nov 7, 2016 at 6:34 PM, Alec Josaitis  wrote:
>>
>>> Dear Glenn and Jack,
>>>
>>> Thanks for the response. I've re-cloned mlib_devel and checked-out the
>>> proper version ( 4c7ba5efb4
>>> ).
>>> I then re-downloaded, and un-tarred this .mdl, saved is as a .slx, and then
>>> opened it in matlab to run update_casper_blocks(bdroot).
>>> I've copied below the errors that appear. Also, I should note there are
>>> no .log files in any of the subdirectories inside the directory created by
>>> casper_xps.
>>>
>>> >> casper_xps
>>> Detected Linux OS
>>> #
>>> ##  System Update  ##
>>> #
>>> MATLAB:MException:MultipleErrors: Error due to multiple causes.
>>> Backtrace 1: reuse_block:51
>>> Backtrace 2: fft_stage_n_init:287
>>> Backtrace 3: reuse_block:138
>>> Backtrace 4: biplex_core_init:173
>>> Backtrace 5: reuse_block:138
>>> Backtrace 6: fft_biplex_real_4x_init:235
>>> Backtrace 7: gen_xps_files:203
>>> Backtrace 8: run_Callback:155
>>> Backtrace 9: casper_xps:88
>>> Backtrace 10: @(hObject,eventdata)casper_xps
>>> ('run_Callback',hObject,eventdata,guidata(hObject)):0
>>> Simulink:Masking:Bad_Init_Commands: Error in
>>> 'poco_wide_12_r316_new/fft_wideband_real/fft_biplex_real_4x/biplex_core/fft_stage_1':
>>> Initialization commands cannot be evaluated.
>>> Backtrace 1: reuse_block:138
>>> Backtrace 2: biplex_core_init:173
>>> Backtrace 3: reuse_block:138
>>> Backtrace 4: fft_biplex_real_4x_init:235
>>> Backtrace 5: gen_xps_files:203
>>> Backtrace 6: run_Callback:155
>>> Backtrace 7: casper_xps:88
>>> Backtrace 8: @(hObject,eventdata)casper_xps
>>> ('run_Callback',hObject,eventdata,guidata(hObject)):0
>>> MATLAB:MException:MultipleErrors: Error due to multiple causes.
>>> Backtrace 1: reuse_block:51
>>> Backtrace 2: fft_stage_n_init:287
>>> Backtrace 3: reuse_block:138
>>> Backtrace 4: biplex_core_init:173
>>> Backtrace 5: reuse_block:138
>>> Backtrace 6: 

Re: [casper] Roach2 Tutorial 4 Troubles (Can't Compile .slx or Upload .fpg)

[G Jones]

Hi Alec (ccing list for posterity),

I don't know if there's a .fpg for tutorial 4 for ROACH 2 but I would
assume one must be around somewhere.

The error message you're seeing is a bit misleading: 'fpga' is not defined
because of an error in setting it up, so the exit_fail function is being
overly optimistic and trying to clean up the fpga before exiting.

>From ipython try running the lines of poco_init_master.py to see where it's
failing. It looks like it might be having some issue connecting to your
board.

Glenn

On Mon, Nov 7, 2016 at 7:02 PM, Alec Josaitis  wrote:

> Dear Glenn,
>
> Regarding your .fpg solutions: I just realized that the .fpg listed in this
> directory
> 
> is programmed for a Roach, not Roach2! Is there a pre-compiled .fpg
> available for the roach2? The master branch of tutorial 4 is intended to
> run a .bof file, but when I try to run, using the proper .py script, I
> receive the following error:
>
> Connecting to server 192.168.4.20 on port 7147...  FAILURE DETECTED. Log
> entries:
> None
> Traceback (most recent call last):
>   File "poco_init_master.py", line 142, in 
> exit_fail()
>   File "poco_init_master.py", line 21, in exit_fail
> fpga.stop()
> NameError: global name 'fpga' is not defined
>
>
> I believe my katcp library is more-up-to-date than this script wants it to
> be, because my library works with .fpg files, rather than .bof. Is there an
> easy resolution to this which doesn't involve devolving my katcp library?
>
> Best,
> Alec
>
> On Mon, Nov 7, 2016 at 6:39 PM, Alec Josaitis  wrote:
>
>> Dear All,
>>
>> My apologies, above I meant to include the following hyperlink when I
>> stated "...this .mdl
>> ".
>> Also, to clarify, I am indeed using the tutorial- recommended versions of
>> software: Xilinx System Generator 14.7 and MATLAB 2012b.
>>
>> Best,
>> Alec
>>
>> On Mon, Nov 7, 2016 at 6:34 PM, Alec Josaitis  wrote:
>>
>>> Dear Glenn and Jack,
>>>
>>> Thanks for the response. I've re-cloned mlib_devel and checked-out the
>>> proper version ( 4c7ba5efb4
>>> ).
>>> I then re-downloaded, and un-tarred this .mdl, saved is as a .slx, and then
>>> opened it in matlab to run update_casper_blocks(bdroot).
>>> I've copied below the errors that appear. Also, I should note there are
>>> no .log files in any of the subdirectories inside the directory created by
>>> casper_xps.
>>>
>>> >> casper_xps
>>> Detected Linux OS
>>> #
>>> ##  System Update  ##
>>> #
>>> MATLAB:MException:MultipleErrors: Error due to multiple causes.
>>> Backtrace 1: reuse_block:51
>>> Backtrace 2: fft_stage_n_init:287
>>> Backtrace 3: reuse_block:138
>>> Backtrace 4: biplex_core_init:173
>>> Backtrace 5: reuse_block:138
>>> Backtrace 6: fft_biplex_real_4x_init:235
>>> Backtrace 7: gen_xps_files:203
>>> Backtrace 8: run_Callback:155
>>> Backtrace 9: casper_xps:88
>>> Backtrace 10: @(hObject,eventdata)casper_xps
>>> ('run_Callback',hObject,eventdata,guidata(hObject)):0
>>> Simulink:Masking:Bad_Init_Commands: Error in
>>> 'poco_wide_12_r316_new/fft_wideband_real/fft_biplex_real_4x/biplex_core/fft_stage_1':
>>> Initialization commands cannot be evaluated.
>>> Backtrace 1: reuse_block:138
>>> Backtrace 2: biplex_core_init:173
>>> Backtrace 3: reuse_block:138
>>> Backtrace 4: fft_biplex_real_4x_init:235
>>> Backtrace 5: gen_xps_files:203
>>> Backtrace 6: run_Callback:155
>>> Backtrace 7: casper_xps:88
>>> Backtrace 8: @(hObject,eventdata)casper_xps
>>> ('run_Callback',hObject,eventdata,guidata(hObject)):0
>>> MATLAB:MException:MultipleErrors: Error due to multiple causes.
>>> Backtrace 1: reuse_block:51
>>> Backtrace 2: fft_stage_n_init:287
>>> Backtrace 3: reuse_block:138
>>> Backtrace 4: biplex_core_init:173
>>> Backtrace 5: reuse_block:138
>>> Backtrace 6: fft_biplex_real_4x_init:235
>>> Backtrace 7: gen_xps_files:203
>>> Backtrace 8: run_Callback:155
>>> Backtrace 9: casper_xps:88
>>> Backtrace 10: @(hObject,eventdata)casper_xps
>>> ('run_Callback',hObject,eventdata,guidata(hObject)):0
>>> Simulink:Masking:Bad_Init_Commands: Error in
>>> 'poco_wide_12_r316_new/fft_wideband_real/fft_biplex_real_4x/biplex_core/fft_stage_1':
>>> Initialization commands cannot be evaluated.
>>> Backtrace 1: reuse_block:138
>>> Backtrace 2: biplex_core_init:173
>>> Backtrace 3: reuse_block:138
>>> Backtrace 4: fft_biplex_real_4x_init:235
>>> Backtrace 5: gen_xps_files:203
>>> Backtrace 6: run_Callback:155
>>> Backtrace 7: casper_xps:88
>>> Backtrace 8: @(hObject,eventdata)casper_xps
>>> ('run_Callback',hObject,eventdata,guidata(hObject)):0
>>> Simulink:Masking:Bad_Init_Commands: Error in
>>> 

Re: [casper] Roach2 Tutorial 4 Troubles (Can't Compile .slx or Upload .fpg)

[Alec Josaitis]

Dear Glenn and Jack,

Thanks for the response. I've re-cloned mlib_devel and checked-out the
proper version ( 4c7ba5efb4
).
I then re-downloaded, and un-tarred this .mdl, saved is as a .slx, and then
opened it in matlab to run update_casper_blocks(bdroot).
I've copied below the errors that appear. Also, I should note there are no
.log files in any of the subdirectories inside the directory created by
casper_xps.

>> casper_xps
Detected Linux OS
#
##  System Update  ##
#
MATLAB:MException:MultipleErrors: Error due to multiple causes.
Backtrace 1: reuse_block:51
Backtrace 2: fft_stage_n_init:287
Backtrace 3: reuse_block:138
Backtrace 4: biplex_core_init:173
Backtrace 5: reuse_block:138
Backtrace 6: fft_biplex_real_4x_init:235
Backtrace 7: gen_xps_files:203
Backtrace 8: run_Callback:155
Backtrace 9: casper_xps:88
Backtrace 10:
@(hObject,eventdata)casper_xps('run_Callback',hObject,eventdata,guidata(hObject)):0
Simulink:Masking:Bad_Init_Commands: Error in
'poco_wide_12_r316_new/fft_wideband_real/fft_biplex_real_4x/biplex_core/fft_stage_1':
Initialization commands cannot be evaluated.
Backtrace 1: reuse_block:138
Backtrace 2: biplex_core_init:173
Backtrace 3: reuse_block:138
Backtrace 4: fft_biplex_real_4x_init:235
Backtrace 5: gen_xps_files:203
Backtrace 6: run_Callback:155
Backtrace 7: casper_xps:88
Backtrace 8:
@(hObject,eventdata)casper_xps('run_Callback',hObject,eventdata,guidata(hObject)):0
MATLAB:MException:MultipleErrors: Error due to multiple causes.
Backtrace 1: reuse_block:51
Backtrace 2: fft_stage_n_init:287
Backtrace 3: reuse_block:138
Backtrace 4: biplex_core_init:173
Backtrace 5: reuse_block:138
Backtrace 6: fft_biplex_real_4x_init:235
Backtrace 7: gen_xps_files:203
Backtrace 8: run_Callback:155
Backtrace 9: casper_xps:88
Backtrace 10:
@(hObject,eventdata)casper_xps('run_Callback',hObject,eventdata,guidata(hObject)):0
Simulink:Masking:Bad_Init_Commands: Error in
'poco_wide_12_r316_new/fft_wideband_real/fft_biplex_real_4x/biplex_core/fft_stage_1':
Initialization commands cannot be evaluated.
Backtrace 1: reuse_block:138
Backtrace 2: biplex_core_init:173
Backtrace 3: reuse_block:138
Backtrace 4: fft_biplex_real_4x_init:235
Backtrace 5: gen_xps_files:203
Backtrace 6: run_Callback:155
Backtrace 7: casper_xps:88
Backtrace 8:
@(hObject,eventdata)casper_xps('run_Callback',hObject,eventdata,guidata(hObject)):0
Simulink:Masking:Bad_Init_Commands: Error in
'poco_wide_12_r316_new/fft_wideband_real/fft_biplex_real_4x/biplex_core':
Initialization commands cannot be evaluated.
Backtrace 1: reuse_block:138
Backtrace 2: fft_biplex_real_4x_init:235
Backtrace 3: gen_xps_files:203
Backtrace 4: run_Callback:155
Backtrace 5: casper_xps:88
Backtrace 6:
@(hObject,eventdata)casper_xps('run_Callback',hObject,eventdata,guidata(hObject)):0
Warning: did not properly cleanup after previous model terminationWarning:
sync_period_bits =

28

Error using gen_xps_files (line 203)
Error in 'poco_wide_12_r316_new/fft_wideband_real/fft_biplex_real_4x':
Initialization commands cannot be evaluated.
>>

On Fri, Nov 4, 2016 at 5:22 PM, Jack Hickish  wrote:

> Hi Alec,
>
> What version of the casper libraries are you using?
>
> The top of the tutorials page on the wiki states:
> """
>
> These tutorials were constructed using Xilinx System Generator 14.7 and
> MATLAB 2012b. Other mutually compatible versions of Xilinx and MATLAB tools
> may work correctly, but have not been tested.
>
> These tutorials use the casper-astro repository, specifically git commit
> 4c7ba5efb4
> 
>
> If you plan to use these tutorials on your own system, you are most likely
> to have success if you use these libraries. You can obtain them from github:
>
> git clone git://github.com/casper-astro/mlib_devel.git
>
> cd mlib_devel
>
> git checkout 4c7ba5efb4
> """
>
> I've no idea if this information is up to date, but is this what you did?
> If you're using a newer version of the libraries than the model was saved
> in, you can try opening the model and running, in the matlab prompt:
>
> update_casper_blocks(bdroot)
>
> This will [try to] update all the blocks in the model to the latest
> versions (the argument bdroot is a shortcut to the top level of your design
> heirarchy). It'll take a while. After this script has completed, you
> shouldn't have any broken links remaining.
>
> Cheers
> Jack
>
> On Tue, 4 Oct 2016 at 16:51 Alec Josaitis  wrote:
>
>> Dear Casperites,
>>
>> I've been trying to complete tutorial 4
>> 
>> for the Roach2, and have run into difficulty compiling either the .slx
>> 

Re: [casper] Roach2 Tutorial 4 Troubles (Can't Compile .slx or Upload .fpg)

[Jack Hickish]

Hi Alec,

What version of the casper libraries are you using?

The top of the tutorials page on the wiki states:
"""

These tutorials were constructed using Xilinx System Generator 14.7 and
MATLAB 2012b. Other mutually compatible versions of Xilinx and MATLAB tools
may work correctly, but have not been tested.

These tutorials use the casper-astro repository, specifically git commit
4c7ba5efb4


If you plan to use these tutorials on your own system, you are most likely
to have success if you use these libraries. You can obtain them from github:

git clone git://github.com/casper-astro/mlib_devel.git

cd mlib_devel

git checkout 4c7ba5efb4
"""

I've no idea if this information is up to date, but is this what you did?
If you're using a newer version of the libraries than the model was saved
in, you can try opening the model and running, in the matlab prompt:

update_casper_blocks(bdroot)

This will [try to] update all the blocks in the model to the latest
versions (the argument bdroot is a shortcut to the top level of your design
heirarchy). It'll take a while. After this script has completed, you
shouldn't have any broken links remaining.

Cheers
Jack

On Tue, 4 Oct 2016 at 16:51 Alec Josaitis  wrote:

> Dear Casperites,
>
> I've been trying to complete tutorial 4
> 
> for the Roach2, and have run into difficulty compiling either the .slx
> 
> or .mdl
> files
> given for the Roach 2, or uploading the precompoliled .fpg
> 
> file onto my Roach2 (using either the python scripts given or simply by
> command-line uploading the .fpg using ipython). My error messages are
> attached in this Google Drive document.
> 
>
> For tutorials 1-3 I have had no trouble compiling the .slx files and
> upload the corresponding .fpg files to my Roach2.
>
> I've made sure in the .slx I cite above (for tutorial 4) that the
> XSG_core_config block does not have a broken link and that the settings are
> as follows:
>
>
>- Hardware platform: Roach2:sx475t
>- User IP clock source: adc0_clk
>- User IP clock rate (MHz): 200, (and that the adc1 and adc0 are
>correspondingly clocked to 800 MHz)
>- Sample period: 1
>- Synthesis tool: XST
>
> Any advice on how I can complete tutorial 4?
>
>
> Best,
>
> Alec
>
>
>
>

Re: [casper] Roach2 Tutorial 4 Troubles (Can't Compile .slx or Upload .fpg)

[G Jones]

No, these warnings are almost always safe to ignore. You want to look for
error messages. You will always get lots of warning messages.

Glenn

On Fri, Nov 4, 2016 at 5:09 PM, Alec Josaitis  wrote:

> Dear Casperites,
>
> One other thing I should clarify, is that before the XSG generation fails,
> the following warning is given in Matlab, regarding inconsistent ADC time
> samples. Does this provide insight as to why my compilation fails?
>
>
> Warning: Inconsistent sample times. Sample time (0.25) of signal driving
> input port 1 of 'tut4_update/adc2/tut4_update_adc2_user_data_valid'
> differs from the expected
> sample time ([0, 0]) at this input port.
> > In 
> > /opt/Xilinx/14.7/ISE_DS/ISE/sysgen/bin/lin64/xlCompileGenerateMdl.p>xlCompileGenerateMdl
> at 203
>   In 
> /opt/Xilinx/14.7/ISE_DS/ISE/sysgen/bin/lin64/xlGenerateButton.p>xlGenerateButton
> at 302
>   In gen_xps_files at 323
>   In casper_xps>run_Callback at 158
>   In casper_xps at 88
>   In 
> @(hObject,eventdata)casper_xps('run_Callback',hObject,eventdata,guidata(hObject))
>
>
> On Fri, Nov 4, 2016 at 5:02 PM, Alec Josaitis  wrote:
>
>> Dear Glenn,
>>
>> Thanks for getting back to me. Unfortunately, the .log files don't reveal
>> any hints to this issue; below is a print-out of the entire .log file (it
>> is only five lines long). None of these lines refer to
>> 'fpga.is_connected()'.
>>
>> - Version Log
>> --
>> Version Path
>> System Generator/opt/Xilinx/14.7/ISE_DS/ISE/sy
>> sgen
>> Matlab 8.0.0.783 (R2012b)   /usr/local/Matlab/2012b
>> ISE /opt/Xilinx/14.7/ISE_DS/ISE
>>
>>
>> Do you have a copy of tutorial 4 that you were able to successfully
>> compile? Upon receiving it, did you have to update any casper_XPS library
>> blocks, or update the .mdl file in any way before attempting to compile it
>> with the casper_xps script in MATLAB?
>>
>> Best,
>> Alec
>>
>> On Wed, Nov 2, 2016 at 3:29 PM, G Jones  wrote:
>>
>>> Hi Alec,
>>> Your compilation error indicates that running system generator failed.
>>> You need to look in the directory created with the design name for the
>>> system generator logs to see where the error occurred. I can't remember the
>>> exact name but dig through the sub directories for .log files and the
>>> search for "error" to see if you can find an error message.
>>> I'm not familiar enough with the casper_fpga library to offer much
>>> advice. Does fpga.is_connected() return True?
>>>
>>> Does the .fpg file look the same as the ones that work for you?
>>>
>>>
>>> Glenn
>>> Dear Casperites,
>>>
>>> I've been trying to complete tutorial 4
>>> 
>>> for the Roach2, and have run into difficulty compiling either the .slx
>>> 
>>> or .mdl
>>> files
>>> given for the Roach 2, or uploading the precompoliled .fpg
>>> 
>>> file onto my Roach2 (using either the python scripts given or simply by
>>> command-line uploading the .fpg using ipython). My error messages are
>>> attached in this Google Drive document.
>>> 
>>>
>>> For tutorials 1-3 I have had no trouble compiling the .slx files and
>>> upload the corresponding .fpg files to my Roach2.
>>>
>>> I've made sure in the .slx I cite above (for tutorial 4) that the
>>> XSG_core_config block does not have a broken link and that the settings are
>>> as follows:
>>>
>>>
>>>- Hardware platform: Roach2:sx475t
>>>- User IP clock source: adc0_clk
>>>- User IP clock rate (MHz): 200, (and that the adc1 and adc0 are
>>>correspondingly clocked to 800 MHz)
>>>- Sample period: 1
>>>- Synthesis tool: XST
>>>
>>> Any advice on how I can complete tutorial 4?
>>>
>>>
>>> Best,
>>>
>>> Alec
>>>
>>>
>>>
>>>
>>
>

Re: [casper] Roach2 Tutorial 4 Troubles (Can't Compile .slx or Upload .fpg)

[G Jones]

Hi Alec,
Sorry if it wasn't clear, my answers were to your two separate queries, not
all together:

To diagnose the compilation problem, you need to dig through the
tut4_update directory that was created by casper_xps in the same directory
as the tut4_update.slx file you are compiling and find all the .log files
(be sure to look in all the subdirectories) and then search those .log
files for "error"


For your problem of not being able to program the fpga, that's where I
suggest running fpga.is_connected() to make sure you are properly
communicating with the FPGA aside from trying to program it. Similarly,
look at the .fpg file vs. the ones that seem to be working and see if
anything obvious is amiss. I suspect a version incompatibility between the
toolflow used to create the tutorial 4 .fpg file and your casper_fpga
python library or katcp library.

Glenn

On Fri, Nov 4, 2016 at 5:02 PM, Alec Josaitis  wrote:

> Dear Glenn,
>
> Thanks for getting back to me. Unfortunately, the .log files don't reveal
> any hints to this issue; below is a print-out of the entire .log file (it
> is only five lines long). None of these lines refer to
> 'fpga.is_connected()'.
>
> - Version Log
> --
> Version Path
> System Generator/opt/Xilinx/14.7/ISE_DS/ISE/sysgen
> Matlab 8.0.0.783 (R2012b)   /usr/local/Matlab/2012b
> ISE /opt/Xilinx/14.7/ISE_DS/ISE
>
>
> Do you have a copy of tutorial 4 that you were able to successfully
> compile? Upon receiving it, did you have to update any casper_XPS library
> blocks, or update the .mdl file in any way before attempting to compile it
> with the casper_xps script in MATLAB?
>
> Best,
> Alec
>
> On Wed, Nov 2, 2016 at 3:29 PM, G Jones  wrote:
>
>> Hi Alec,
>> Your compilation error indicates that running system generator failed.
>> You need to look in the directory created with the design name for the
>> system generator logs to see where the error occurred. I can't remember the
>> exact name but dig through the sub directories for .log files and the
>> search for "error" to see if you can find an error message.
>> I'm not familiar enough with the casper_fpga library to offer much
>> advice. Does fpga.is_connected() return True?
>>
>> Does the .fpg file look the same as the ones that work for you?
>>
>>
>> Glenn
>> Dear Casperites,
>>
>> I've been trying to complete tutorial 4
>> 
>> for the Roach2, and have run into difficulty compiling either the .slx
>> 
>> or .mdl
>> files
>> given for the Roach 2, or uploading the precompoliled .fpg
>> 
>> file onto my Roach2 (using either the python scripts given or simply by
>> command-line uploading the .fpg using ipython). My error messages are
>> attached in this Google Drive document.
>> 
>>
>> For tutorials 1-3 I have had no trouble compiling the .slx files and
>> upload the corresponding .fpg files to my Roach2.
>>
>> I've made sure in the .slx I cite above (for tutorial 4) that the
>> XSG_core_config block does not have a broken link and that the settings are
>> as follows:
>>
>>
>>- Hardware platform: Roach2:sx475t
>>- User IP clock source: adc0_clk
>>- User IP clock rate (MHz): 200, (and that the adc1 and adc0 are
>>correspondingly clocked to 800 MHz)
>>- Sample period: 1
>>- Synthesis tool: XST
>>
>> Any advice on how I can complete tutorial 4?
>>
>>
>> Best,
>>
>> Alec
>>
>>
>>
>>
>

Re: [casper] Roach2 Tutorial 4 Troubles (Can't Compile .slx or Upload .fpg)

[Alec Josaitis]

Dear Casperites,

One other thing I should clarify, is that before the XSG generation fails,
the following warning is given in Matlab, regarding inconsistent ADC time
samples. Does this provide insight as to why my compilation fails?


Warning: Inconsistent sample times. Sample time (0.25) of signal driving
input port 1 of 'tut4_update/adc2/tut4_update_adc2_user_data_valid' differs
from the expected
sample time ([0, 0]) at this input port.
> In
/opt/Xilinx/14.7/ISE_DS/ISE/sysgen/bin/lin64/xlCompileGenerateMdl.p>xlCompileGenerateMdl
at 203
  In
/opt/Xilinx/14.7/ISE_DS/ISE/sysgen/bin/lin64/xlGenerateButton.p>xlGenerateButton
at 302
  In gen_xps_files at 323
  In casper_xps>run_Callback at 158
  In casper_xps at 88
  In
@(hObject,eventdata)casper_xps('run_Callback',hObject,eventdata,guidata(hObject))


On Fri, Nov 4, 2016 at 5:02 PM, Alec Josaitis  wrote:

> Dear Glenn,
>
> Thanks for getting back to me. Unfortunately, the .log files don't reveal
> any hints to this issue; below is a print-out of the entire .log file (it
> is only five lines long). None of these lines refer to
> 'fpga.is_connected()'.
>
> - Version Log
> --
> Version Path
> System Generator/opt/Xilinx/14.7/ISE_DS/ISE/sysgen
> Matlab 8.0.0.783 (R2012b)   /usr/local/Matlab/2012b
> ISE /opt/Xilinx/14.7/ISE_DS/ISE
>
>
> Do you have a copy of tutorial 4 that you were able to successfully
> compile? Upon receiving it, did you have to update any casper_XPS library
> blocks, or update the .mdl file in any way before attempting to compile it
> with the casper_xps script in MATLAB?
>
> Best,
> Alec
>
> On Wed, Nov 2, 2016 at 3:29 PM, G Jones  wrote:
>
>> Hi Alec,
>> Your compilation error indicates that running system generator failed.
>> You need to look in the directory created with the design name for the
>> system generator logs to see where the error occurred. I can't remember the
>> exact name but dig through the sub directories for .log files and the
>> search for "error" to see if you can find an error message.
>> I'm not familiar enough with the casper_fpga library to offer much
>> advice. Does fpga.is_connected() return True?
>>
>> Does the .fpg file look the same as the ones that work for you?
>>
>>
>> Glenn
>> Dear Casperites,
>>
>> I've been trying to complete tutorial 4
>> 
>> for the Roach2, and have run into difficulty compiling either the .slx
>> 
>> or .mdl
>> files
>> given for the Roach 2, or uploading the precompoliled .fpg
>> 
>> file onto my Roach2 (using either the python scripts given or simply by
>> command-line uploading the .fpg using ipython). My error messages are
>> attached in this Google Drive document.
>> 
>>
>> For tutorials 1-3 I have had no trouble compiling the .slx files and
>> upload the corresponding .fpg files to my Roach2.
>>
>> I've made sure in the .slx I cite above (for tutorial 4) that the
>> XSG_core_config block does not have a broken link and that the settings are
>> as follows:
>>
>>
>>- Hardware platform: Roach2:sx475t
>>- User IP clock source: adc0_clk
>>- User IP clock rate (MHz): 200, (and that the adc1 and adc0 are
>>correspondingly clocked to 800 MHz)
>>- Sample period: 1
>>- Synthesis tool: XST
>>
>> Any advice on how I can complete tutorial 4?
>>
>>
>> Best,
>>
>> Alec
>>
>>
>>
>>
>

Re: [casper] Roach2 Tutorial 4 Troubles (Can't Compile .slx or Upload .fpg)

[Alec Josaitis]

Dear Glenn,

Thanks for getting back to me. Unfortunately, the .log files don't reveal
any hints to this issue; below is a print-out of the entire .log file (it
is only five lines long). None of these lines refer to
'fpga.is_connected()'.

- Version Log
--
Version Path
System Generator/opt/Xilinx/14.7/ISE_DS/ISE/sysgen
Matlab 8.0.0.783 (R2012b)   /usr/local/Matlab/2012b
ISE /opt/Xilinx/14.7/ISE_DS/ISE


Do you have a copy of tutorial 4 that you were able to successfully
compile? Upon receiving it, did you have to update any casper_XPS library
blocks, or update the .mdl file in any way before attempting to compile it
with the casper_xps script in MATLAB?

Best,
Alec

On Wed, Nov 2, 2016 at 3:29 PM, G Jones  wrote:

> Hi Alec,
> Your compilation error indicates that running system generator failed. You
> need to look in the directory created with the design name for the system
> generator logs to see where the error occurred. I can't remember the exact
> name but dig through the sub directories for .log files and the search for
> "error" to see if you can find an error message.
> I'm not familiar enough with the casper_fpga library to offer much advice.
> Does fpga.is_connected() return True?
>
> Does the .fpg file look the same as the ones that work for you?
>
>
> Glenn
> Dear Casperites,
>
> I've been trying to complete tutorial 4
> 
> for the Roach2, and have run into difficulty compiling either the .slx
> 
> or .mdl
> files
> given for the Roach 2, or uploading the precompoliled .fpg
> 
> file onto my Roach2 (using either the python scripts given or simply by
> command-line uploading the .fpg using ipython). My error messages are
> attached in this Google Drive document.
> 
>
> For tutorials 1-3 I have had no trouble compiling the .slx files and
> upload the corresponding .fpg files to my Roach2.
>
> I've made sure in the .slx I cite above (for tutorial 4) that the
> XSG_core_config block does not have a broken link and that the settings are
> as follows:
>
>
>- Hardware platform: Roach2:sx475t
>- User IP clock source: adc0_clk
>- User IP clock rate (MHz): 200, (and that the adc1 and adc0 are
>correspondingly clocked to 800 MHz)
>- Sample period: 1
>- Synthesis tool: XST
>
> Any advice on how I can complete tutorial 4?
>
>
> Best,
>
> Alec
>
>
>
>

Re: [casper] Roach2 Tutorial 4 Troubles (Can't Compile .slx or Upload .fpg)

[G Jones]

Hi Alec,
Your compilation error indicates that running system generator failed. You
need to look in the directory created with the design name for the system
generator logs to see where the error occurred. I can't remember the exact
name but dig through the sub directories for .log files and the search for
"error" to see if you can find an error message.
I'm not familiar enough with the casper_fpga library to offer much advice.
Does fpga.is_connected() return True?

Does the .fpg file look the same as the ones that work for you?


Glenn
Dear Casperites,

I've been trying to complete tutorial 4
 for
the Roach2, and have run into difficulty compiling either the .slx

or .mdl
files
given for the Roach 2, or uploading the precompoliled .fpg

file onto my Roach2 (using either the python scripts given or simply by
command-line uploading the .fpg using ipython). My error messages are
attached in this Google Drive document.


For tutorials 1-3 I have had no trouble compiling the .slx files and upload
the corresponding .fpg files to my Roach2.

I've made sure in the .slx I cite above (for tutorial 4) that the
XSG_core_config block does not have a broken link and that the settings are
as follows:


   - Hardware platform: Roach2:sx475t
   - User IP clock source: adc0_clk
   - User IP clock rate (MHz): 200, (and that the adc1 and adc0 are
   correspondingly clocked to 800 MHz)
   - Sample period: 1
   - Synthesis tool: XST

Any advice on how I can complete tutorial 4?


Best,

Alec

Re: [casper] Roach2 Tutorial 4 Troubles (Can't Compile .slx or Upload .fpg)

[Alec Josaitis]

Dear Casperites,

I just wanted to follow-up with you all on the above error. Do any of you
have recommendations for getting the tut4 files to run on my copy of MATLAB
and Roach2? I'm happy to provide any other information you all may need to
diagnose this issue.

Thank you all for your time.

Best,
Alec

On Tue, Oct 4, 2016 at 7:50 PM, Alec Josaitis  wrote:

> Dear Casperites,
>
> I've been trying to complete tutorial 4
> 
> for the Roach2, and have run into difficulty compiling either the .slx
> 
> or .mdl
> files
> given for the Roach 2, or uploading the precompoliled .fpg
> 
> file onto my Roach2 (using either the python scripts given or simply by
> command-line uploading the .fpg using ipython). My error messages are
> attached in this Google Drive document.
> 
>
> For tutorials 1-3 I have had no trouble compiling the .slx files and
> upload the corresponding .fpg files to my Roach2.
>
> I've made sure in the .slx I cite above (for tutorial 4) that the
> XSG_core_config block does not have a broken link and that the settings are
> as follows:
>
>
>- Hardware platform: Roach2:sx475t
>- User IP clock source: adc0_clk
>- User IP clock rate (MHz): 200, (and that the adc1 and adc0 are
>correspondingly clocked to 800 MHz)
>- Sample period: 1
>- Synthesis tool: XST
>
> Any advice on how I can complete tutorial 4?
>
>
> Best,
>
> Alec
>
>
>
>