Re: [casper] Changing SLX file names causes LUT errors during jasper compiles.

[Mitchell Burnett]

Hi Bishnu,

> So far, I have only encountered this issue with the RFDC block. It involves 
> renaming the .slx file and copying the RFDC from one design to another 
> without changing the port name inside the mask.

This should have be resolved by the pull request’s and commit’s I linked. The 
port names inside the mask should now automatically updated when opening a 
`slx` with an `rfdc`  that was copied by one name, to another. At least, the is 
the intention. If not, please consider raising an issue to 
casper-astro/mlib_devel Github.

> I have also made a compiled note for complete installation and running CASPER 
> tutorials with all the issues that I faced. I hope it will save time for new 
> users. Thank you. 
> - https://github.com/Bishnus350/rfsoc4x2_board_setup

Thanks for your help here. I hope new users can benefit from your information. 
There is still significant room for improvement in the tutorials and 
documentation. If you feel inclined, you could consider including the 
information as edits to parts of the casper tutorials, where relevant.

Thanks,
Mitch

> On Feb 19, 2025, at 6:35 PM, Bishnu Kumar Sharma 
>  wrote:
> 
> Hi Mitchell, 
> So far, I have only encountered this issue with the RFDC block. It involves 
> renaming the .slx file and copying the RFDC from one design to another 
> without changing the port name inside the mask. When i was playing around 
> with 4x2 board tutorial of RFDC, sometimes the green block  "bitfield 
> snapshot" block also behaved weirdly when copying. So I stopped using 
> bitfield snapshot and started using the "snapshot" block. 
> I have mentioned this issue in a note i keep it in my GitHub repository. I 
> have also kept tutorials on using TICS Pro for designing new clock files. 
> - https://github.com/Bishnus350/rfsoc4x2_board_setup
> I have also made a compiled note for complete installation and running CASPER 
> tutorials with all the issues that I faced. I hope it will save time for new 
> users. Thank you. 
> 
> Best Regards
> Bishnu Sharma
> Institute of Astronomy and Astrophysics
> Academia Sinica
> 
> 
> 
> On Thu, Feb 20, 2025 at 3:18 AM Mitchell Burnett  > wrote:
>> Hello,
>> 
>> For Bishnu, and Kaj, they report it is specific to the RFDC. In Ken’s case, 
>> was this specific to the RFDC, or other blocks? This was first addressed in 
>> https://github.com/casper-astro/mlib_devel/issues/199 with fixes coming from 
>> https://github.com/casper-astro/mlib_devel/pull/205. In any case, if the 
>> issue is persistent, or exists with another yellow block, please consider 
>> opening an issue on Github in casper-astro/mlib_devel with minimal working 
>> example or details to reproduce from the main `m2021a` branch. Updates to 
>> documentation and/or tutorials to help others in the future is also 
>> encouraged.
>> 
>> Best,
>> Mitch 
>> 
>>> On Feb 19, 2025, at 1:58 AM, Andrew Martens >> > wrote:
>>> 
>>> Hey Kaj, Ken
>>> 
>>> JASPER helpfully ties various project elements together
>>> - the core generated by the System Generator/ Model Composer compiler
>>> - HDL cores (registers etc) that attach to ports on the core 
>>> - software infrastructure that can access registers etc
>>> 
>>> Usually, the yellow block init scripts change the names of Simulink 
>>> input/output ports so that they are predictable and unique. This allows 
>>> JASPER to link them to the cores in the Vivado project during compilation. 
>>> The scripts are generally set up so that, when an update (e.g before 
>>> simulation or compilation) occurs, this port name is updated/changed. It 
>>> seems that this automatic updating is not happening and that the RFDC init 
>>> script is probably behaving more like the DSP-related ones (that only 
>>> change their internals when a mask parameter changes ).
>>> 
>>> Changing the name of the .slx and running just the JASPER backend without 
>>> first running the Matlab frontend is not recommended as JASPER internally 
>>> no doubt uses the name to predict the port names (and other things), and 
>>> will use this new name with project components generated with the old name. 
>>> This will cause chaos.
>>> 
>>> Note that this information is slightly dated and refers to the tooflow 
>>> pre-JASPER. Jack will need to correct me if he has changed certain 
>>> steps/mechanisms.
>>> 
>>> Regards
>>> Andrew
>>> 
>>> On Wed, Feb 19, 2025 at 9:18 AM Kaj Wiik >> > wrote:
 Hi Ken,
 
 Yes, I think I have reported this before, maybe there should be a FAQ 
 list somewhere.
 
 Just renaming SLX in OS (mv a.slx b.slx) will create all kinds of weird 
 errors, the correct way to create a file with a different name is to 
 save the project with a different name inside Simulink.
 
 If I remember correctly, the root cause of this is that the .slx file 
 contains the file name and is dependent on it. Yes, I cannot think any 
 other

Re: [casper] Changing SLX file names causes LUT errors during jasper compiles.

[Mitchell Burnett]

Hi Ken,

Thanks for the feedback.

> This is correct in individual repo branches.  gateway_out is populated as a 
> 0-by-1 cell in the mask script and fails silently.  Nothing appears wrong to 
> the designers until later stages of implementation.  

To clarify, what you are saying here is that to reproduce the error as you were 
getting it was to have a known working .slx made in R2021a using 
`casper-astro/mlib_devel/m2021a` and then open and run `jasper` in R2022a using 
`casper-astro/mlib_devel/m2022a`?

> there is a difference between the MATLAB versions  R2021a and R2022a.


This is correct, among other nuances that have changed in the underlying model 
composer API, and was part of the work done to get the beginnings of a `m2022a` 
compatible version of the repository.

> Backward compatibility is not something that should be gauranteed nor 
> expected. However, due to the LUT error being pernicious, it would be wise to 
> make some changes.  Possible changes are to detect the version automatically

This is was considered as part of new changes that haven’t been submitted back 
to m2022a, at least not yet. We had wanted to achieve some sort of minimum 
level of backwards compatibility, at least for RFSoC. Although, as I went 
through and found several places where the API had started to change I somewhat 
abandoned it. However, I think there would still be some support to achieve 
backwards compatibility. It sounds like you have a good approach here.

Thanks again,
Mitch

> On Feb 20, 2025, at 2:52 PM, Ken Semanov  wrote:
> 
> Hello Mitch,
> 
> We have discovered the source of this LUT error.   In custom Yellowblocks   
> there is a difference between the MATLAB versions  R2021a and R2022a.   
> 
> the masktype is given as
> "Xilinx Gateway Out Block"   (R2021a)  (branch m2021a)
> "Gateway Out Block"   (R2022a)  (branch m2022a) 
> 
> (m2021a)  
> https://github.com/casper-astro/mlib_devel/blob/m2021a/xps_library/gpio_bidir_mask.m
> (m2022a)  
> https://github.com/casper-astro/mlib_devel/blob/m2022a/xps_library/gpio_bidir_mask.m
> 
> This is correct in individual repo branches.  gateway_out is populated as a 
> 0-by-1 cell in the mask script and fails silently.  Nothing appears wrong to 
> the designers until later stages of implementation.  
> 
> Compiles can last up to 30 minutes and a "LUT disconnection error" appears to 
> be some kind of circuit design mistake, but it's not.  The error is 
> pernicious.  Backward compatibility is not something that should be 
> gauranteed nor expected. However, due to the LUT error being pernicious, it 
> would be wise to make some changes.  Possible changes are to detect the 
> version automatically and retrieve the masktype. 
> 
> use_masktype = 
> get_param('zcu216_tut_rfdc/rfdc/zcu216_tut_rfdc_rfdc_m00_axis_tdata' ,  
> 'masktype'  ) 
> 
> The string in the first argument could be obtained by find_system() but 
> without type. 
>  
> 
> 
> On Wednesday, February 19, 2025 at 2:18:27 PM UTC-5 Mitchell Burnett wrote:
>> Hello,
>> 
>> For Bishnu, and Kaj, they report it is specific to the RFDC. In Ken’s case, 
>> was this specific to the RFDC, or other blocks? This was first addressed in 
>> https://github.com/casper-astro/mlib_devel/issues/199 with fixes coming from 
>> https://github.com/casper-astro/mlib_devel/pull/205. In any case, if the 
>> issue is persistent, or exists with another yellow block, please consider 
>> opening an issue on Github in casper-astro/mlib_devel with minimal working 
>> example or details to reproduce from the main `m2021a` branch. Updates to 
>> documentation and/or tutorials to help others in the future is also 
>> encouraged.
>> 
>> Best,
>> Mitch 
>> 
>> 
>>> On Feb 19, 2025, at 1:58 AM, Andrew Martens > wrote:
>>> 
>> 
>>> Hey Kaj, Ken
>>> 
>>> JASPER helpfully ties various project elements together
>>> - the core generated by the System Generator/ Model Composer compiler
>>> - HDL cores (registers etc) that attach to ports on the core 
>>> - software infrastructure that can access registers etc
>>> 
>>> Usually, the yellow block init scripts change the names of Simulink 
>>> input/output ports so that they are predictable and unique. This allows 
>>> JASPER to link them to the cores in the Vivado project during compilation. 
>>> The scripts are generally set up so that, when an update (e.g before 
>>> simulation or compilation) occurs, this port name is updated/changed. It 
>>> seems that this automatic updating is not happening and that the RFDC init 
>>> script is probably behaving more like the DSP-related ones (that only 
>>> change their internals when a mask parameter changes ).
>>> 
>>> Changing the name of the .slx and running just the JASPER backend without 
>>> first running the Matlab frontend is not recommended as JASPER internally 
>>> no doubt uses the name to predict the port names (and other things), and 
>>> will use this new name with project components generated with the old name. 
>>> This will cause chaos

Re: [casper] Changing SLX file names causes LUT errors during jasper compiles.

[Ken Semanov]

Hello Mitch,

We have discovered the source of this LUT error.   In custom Yellowblocks   
there is a difference between the MATLAB versions  R2021a and R2022a.   

the masktype is given as

   - *"Xilinx Gateway Out Block"*   (R2021a)  (branch m2021a) 
   - *"Gateway Out Block" *  (R2022a)  (branch m2022a)  
   

(m2021a)  
https://github.com/casper-astro/mlib_devel/blob/m2021a/xps_library/gpio_bidir_mask.m
(m2022a)  
https://github.com/casper-astro/mlib_devel/blob/m2022a/xps_library/gpio_bidir_mask.m

This is correct in individual repo branches.  gateway_out is populated as a 
0-by-1 cell in the mask script and fails silently.  Nothing appears wrong 
to the designers until later stages of implementation.  

Compiles can last up to 30 minutes and a "LUT disconnection error" appears 
to be some kind of circuit design mistake, but it's not.  The error is 
pernicious.  Backward compatibility is not something that should be 
gauranteed nor expected. However, due to the LUT error being pernicious, it 
would be wise to make some changes.  Possible changes are to detect the 
version automatically and retrieve the masktype. 

use_masktype = 
get_param('zcu216_tut_rfdc/rfdc/zcu216_tut_rfdc_rfdc_m00_axis_tdata' ,  
'masktype'  )  

The string in the first argument could be obtained by find_system() but 
without type.  
  


On Wednesday, February 19, 2025 at 2:18:27 PM UTC-5 Mitchell Burnett wrote:

> Hello,
>
> For Bishnu, and Kaj, they report it is specific to the RFDC. In Ken’s 
> case, was this specific to the RFDC, or other blocks? This was first 
> addressed in https://github.com/casper-astro/mlib_devel/issues/199 with 
> fixes coming from https://github.com/casper-astro/mlib_devel/pull/205. In 
> any case, if the issue is persistent, or exists with another yellow block, 
> please consider opening an issue on Github in casper-astro/mlib_devel with 
> minimal working example or details to reproduce from the main `m2021a` 
> branch. Updates to documentation and/or tutorials to help others in the 
> future is also encouraged.
>
> Best,
> Mitch 
>
> On Feb 19, 2025, at 1:58 AM, Andrew Martens  wrote:
>
> Hey Kaj, Ken
>
> JASPER helpfully ties various project elements together
> - the core generated by the System Generator/ Model Composer compiler
> - HDL cores (registers etc) that attach to ports on the core 
> - software infrastructure that can access registers etc
>
> Usually, the yellow block init scripts change the names of Simulink 
> input/output ports so that they are predictable and unique. This allows 
> JASPER to link them to the cores in the Vivado project during compilation. 
> The scripts are generally set up so that, when an update (e.g before 
> simulation or compilation) occurs, this port name is updated/changed. It 
> seems that this automatic updating is not happening and that the RFDC init 
> script is probably behaving more like the DSP-related ones (that only 
> change their internals when a mask parameter changes ).
>
> Changing the name of the .slx and running just the JASPER backend without 
> first running the Matlab frontend is not recommended as JASPER internally 
> no doubt uses the name to predict the port names (and other things), and 
> will use this new name with project components generated with the old name. 
> This will cause chaos.
>
> Note that this information is slightly dated and refers to the tooflow 
> pre-JASPER. Jack will need to correct me if he has changed certain 
> steps/mechanisms.
>
> Regards
> Andrew
>
> On Wed, Feb 19, 2025 at 9:18 AM Kaj Wiik  wrote:
>
> Hi Ken,
>>
>> Yes, I think I have reported this before, maybe there should be a FAQ 
>> list somewhere.
>>
>> Just renaming SLX in OS (mv a.slx b.slx) will create all kinds of weird 
>> errors, the correct way to create a file with a different name is to 
>> save the project with a different name inside Simulink.
>>
>> If I remember correctly, the root cause of this is that the .slx file 
>> contains the file name and is dependent on it. Yes, I cannot think any 
>> other software doing this and it is a very bad design choice IMHO.
>>
>> Cheers,
>> Kaj
>>
>> On 19.2.2025 0.30, Ken Semanov wrote:
>> > Changing the file names of an SLX file can cause LUT errors during 
>> > jasper compiles.  These errors are fatal and will drop the compile to 
>> > command line in Matlab. The CASPER toolflow official documentation 
>> > should mention this problem, if -- for no other reason --  CASPER 
>> > doesn't have a mechanism to check whether the current SLX filename has 
>> > been changed
>> > 
>> > These LUT errors occur in the later stages of implementation, during the
>>  
>> > "Logical Optimization" stages.The blocks in the design which invoke
>>  
>> > the missing logic LUT error are random, and seem to be related to the 
>> > order in which optimizer selects blocks for optimizing. For example,  if
>>  
>> > the offending block is removed, the LUT error will migrate to some other
>>  
>> > -- often unrelated -- blo

Re: [casper] Changing SLX file names causes LUT errors during jasper compiles.

[Ken Semanov]

 Right-click on design background and select "Update diagram".  This will 
create changes in the pin names during compile. 

The offending pins were changed in the following way.  A prefix on the 
names was substituted for a prefix that matches the SLX file name.   For 
example  alpha.slx  saved as  beta.slx.The previous pin name was 
alpha_s_axis_tdata   changed to beta_s_axis_tdata  , after Update Diagram.  

Caveat emptor :  This is not a full solution to the problem of the LUT 
compile errors, but could play a role.  


On Thursday, February 20, 2025 at 2:27:09 PM UTC-5 Ken Semanov wrote:

> For custom Yellowblocks  (and also RFDC blocks)  , their import into a 
> design makes them "absorb" the slx file name, then  prepend that name as a 
> prefix on the port names inside the block's mask.  These absorbed prefixes 
> are never updated, even after *Save as... *and/or  *Update Diagram...*   
> is applied.Bishnu mentioned this in a reply, above. 
> On Thursday, February 20, 2025 at 2:19:37 PM UTC-5 Ken Semanov wrote:
>
>> Right-click on design background and select "Update diagram".  This will 
>> create changes in the pin names during compile. 
>>
>> The offending pins were changed in the following way.  A prefix on the 
>> names was substituted for a prefix that matches the SLX file name.   For 
>> example  alpha.slx  saved as  beta.slx.The previous pin name was 
>> alpha_s_axis_tdata.slx.  to beta_s_axis_tdata.slx  , after Update Diagram.  
>>
>> Caveat emptor :  This is not a full solution to the problem of the LUT 
>> compile errors, but could play a role.   
>>
>> On Wednesday, February 19, 2025 at 8:36:06 PM UTC-5 Bishnu Kumar Sharma 
>> wrote:
>>
>>> Hi Mitchell, 
>>> So far, I have only encountered this issue with the RFDC block. It 
>>> involves renaming the .slx file and copying the RFDC from one design to 
>>> another without changing the port name inside the mask. When i was playing 
>>> around with 4x2 board tutorial of RFDC, sometimes the green 
>>> block  "bitfield snapshot" block also behaved weirdly when copying. So I 
>>> stopped using bitfield snapshot and started using the "snapshot" block. 
>>> I have mentioned this issue in a note i keep it in my GitHub repository. 
>>> I have also kept tutorials on using TICS Pro for designing new clock files. 
>>> - https://github.com/Bishnus350/rfsoc4x2_board_setup
>>> I have also made a compiled note for complete installation and running 
>>> CASPER tutorials with all the issues that I faced. I hope it will save time 
>>> for new users. Thank you. 
>>>
>>> Best Regards
>>> Bishnu Sharma
>>> Institute of Astronomy and Astrophysics
>>> Academia Sinica
>>>
>>>
>>> On Thu, Feb 20, 2025 at 3:18 AM Mitchell Burnett  
>>> wrote:
>>>
 Hello,

 For Bishnu, and Kaj, they report it is specific to the RFDC. In Ken’s 
 case, was this specific to the RFDC, or other blocks? This was first 
 addressed in https://github.com/casper-astro/mlib_devel/issues/199 with 
 fixes coming from https://github.com/casper-astro/mlib_devel/pull/205. 
 In any case, if the issue is persistent, or exists with another yellow 
 block, please consider opening an issue on Github in 
 casper-astro/mlib_devel with minimal working example or details to 
 reproduce from the main `m2021a` branch. Updates to documentation and/or 
 tutorials to help others in the future is also encouraged.

 Best,
 Mitch 

 On Feb 19, 2025, at 1:58 AM, Andrew Martens  wrote:

 Hey Kaj, Ken

 JASPER helpfully ties various project elements together
 - the core generated by the System Generator/ Model Composer compiler
 - HDL cores (registers etc) that attach to ports on the core 
 - software infrastructure that can access registers etc

 Usually, the yellow block init scripts change the names of Simulink 
 input/output ports so that they are predictable and unique. This allows 
 JASPER to link them to the cores in the Vivado project during compilation. 
 The scripts are generally set up so that, when an update (e.g before 
 simulation or compilation) occurs, this port name is updated/changed. It 
 seems that this automatic updating is not happening and that the RFDC init 
 script is probably behaving more like the DSP-related ones (that only 
 change their internals when a mask parameter changes ).

 Changing the name of the .slx and running just the JASPER backend 
 without first running the Matlab frontend is not recommended as JASPER 
 internally no doubt uses the name to predict the port names (and other 
 things), and will use this new name with project components generated with 
 the old name. This will cause chaos.

 Note that this information is slightly dated and refers to the tooflow 
 pre-JASPER. Jack will need to correct me if he has changed certain 
 steps/mechanisms.

 Regards
 Andrew

 

Re: [casper] Changing SLX file names causes LUT errors during jasper compiles.

[Ken Semanov]

For custom Yellowblocks  (and also RFDC blocks)  , their import into a 
design makes them "absorb" the slx file name, then  prepend that name as a 
prefix on the port names inside the block's mask.  These absorbed prefixes 
are never updated, even after *Save as... *and/or  *Update Diagram...*   is 
applied.Bishnu mentioned this in a reply, above. 
On Thursday, February 20, 2025 at 2:19:37 PM UTC-5 Ken Semanov wrote:

> Right-click on design background and select "Update diagram".  This will 
> create changes in the pin names during compile. 
>
> The offending pins were changed in the following way.  A prefix on the 
> names was substituted for a prefix that matches the SLX file name.   For 
> example  alpha.slx  saved as  beta.slx.The previous pin name was 
> alpha_s_axis_tdata.slx.  to beta_s_axis_tdata.slx  , after Update Diagram.  
>
> Caveat emptor :  This is not a full solution to the problem of the LUT 
> compile errors, but could play a role.   
>
> On Wednesday, February 19, 2025 at 8:36:06 PM UTC-5 Bishnu Kumar Sharma 
> wrote:
>
>> Hi Mitchell, 
>> So far, I have only encountered this issue with the RFDC block. It 
>> involves renaming the .slx file and copying the RFDC from one design to 
>> another without changing the port name inside the mask. When i was playing 
>> around with 4x2 board tutorial of RFDC, sometimes the green 
>> block  "bitfield snapshot" block also behaved weirdly when copying. So I 
>> stopped using bitfield snapshot and started using the "snapshot" block. 
>> I have mentioned this issue in a note i keep it in my GitHub repository. 
>> I have also kept tutorials on using TICS Pro for designing new clock files. 
>> - https://github.com/Bishnus350/rfsoc4x2_board_setup
>> I have also made a compiled note for complete installation and running 
>> CASPER tutorials with all the issues that I faced. I hope it will save time 
>> for new users. Thank you. 
>>
>> Best Regards
>> Bishnu Sharma
>> Institute of Astronomy and Astrophysics
>> Academia Sinica
>>
>>
>> On Thu, Feb 20, 2025 at 3:18 AM Mitchell Burnett  
>> wrote:
>>
>>> Hello,
>>>
>>> For Bishnu, and Kaj, they report it is specific to the RFDC. In Ken’s 
>>> case, was this specific to the RFDC, or other blocks? This was first 
>>> addressed in https://github.com/casper-astro/mlib_devel/issues/199 with 
>>> fixes coming from https://github.com/casper-astro/mlib_devel/pull/205. 
>>> In any case, if the issue is persistent, or exists with another yellow 
>>> block, please consider opening an issue on Github in 
>>> casper-astro/mlib_devel with minimal working example or details to 
>>> reproduce from the main `m2021a` branch. Updates to documentation and/or 
>>> tutorials to help others in the future is also encouraged.
>>>
>>> Best,
>>> Mitch 
>>>
>>> On Feb 19, 2025, at 1:58 AM, Andrew Martens  wrote:
>>>
>>> Hey Kaj, Ken
>>>
>>> JASPER helpfully ties various project elements together
>>> - the core generated by the System Generator/ Model Composer compiler
>>> - HDL cores (registers etc) that attach to ports on the core 
>>> - software infrastructure that can access registers etc
>>>
>>> Usually, the yellow block init scripts change the names of Simulink 
>>> input/output ports so that they are predictable and unique. This allows 
>>> JASPER to link them to the cores in the Vivado project during compilation. 
>>> The scripts are generally set up so that, when an update (e.g before 
>>> simulation or compilation) occurs, this port name is updated/changed. It 
>>> seems that this automatic updating is not happening and that the RFDC init 
>>> script is probably behaving more like the DSP-related ones (that only 
>>> change their internals when a mask parameter changes ).
>>>
>>> Changing the name of the .slx and running just the JASPER backend 
>>> without first running the Matlab frontend is not recommended as JASPER 
>>> internally no doubt uses the name to predict the port names (and other 
>>> things), and will use this new name with project components generated with 
>>> the old name. This will cause chaos.
>>>
>>> Note that this information is slightly dated and refers to the tooflow 
>>> pre-JASPER. Jack will need to correct me if he has changed certain 
>>> steps/mechanisms.
>>>
>>> Regards
>>> Andrew
>>>
>>> On Wed, Feb 19, 2025 at 9:18 AM Kaj Wiik  wrote:
>>>
 Hi Ken,

 Yes, I think I have reported this before, maybe there should be a FAQ 
 list somewhere.

 Just renaming SLX in OS (mv a.slx b.slx) will create all kinds of weird
  
 errors, the correct way to create a file with a different name is to 
 save the project with a different name inside Simulink.

 If I remember correctly, the root cause of this is that the .slx file 
 contains the file name and is dependent on it. Yes, I cannot think any 
 other software doing this and it is a very bad design choice IMHO.

 Cheers,
 Kaj

 On 19.2.2025 0.30, Ken Semanov wrote:
 > C

Re: [casper] Changing SLX file names causes LUT errors during jasper compiles.

[Ken Semanov]

Right-click on design background and select "Update diagram".  This will 
create changes in the pin names during compile. 

The offending pins were changed in the following way.  A prefix on the 
names was substituted for a prefix that matches the SLX file name.   For 
example  alpha.slx  saved as  beta.slx.The previous pin name was 
alpha_s_axis_tdata.slx.  to beta_s_axis_tdata.slx  , after Update Diagram.  

Caveat emptor :  This is not a full solution to the problem of the LUT 
compile errors, but could play a role.   

On Wednesday, February 19, 2025 at 8:36:06 PM UTC-5 Bishnu Kumar Sharma 
wrote:

> Hi Mitchell, 
> So far, I have only encountered this issue with the RFDC block. It 
> involves renaming the .slx file and copying the RFDC from one design to 
> another without changing the port name inside the mask. When i was playing 
> around with 4x2 board tutorial of RFDC, sometimes the green 
> block  "bitfield snapshot" block also behaved weirdly when copying. So I 
> stopped using bitfield snapshot and started using the "snapshot" block. 
> I have mentioned this issue in a note i keep it in my GitHub repository. I 
> have also kept tutorials on using TICS Pro for designing new clock files. 
> - https://github.com/Bishnus350/rfsoc4x2_board_setup
> I have also made a compiled note for complete installation and running 
> CASPER tutorials with all the issues that I faced. I hope it will save time 
> for new users. Thank you. 
>
> Best Regards
> Bishnu Sharma
> Institute of Astronomy and Astrophysics
> Academia Sinica
>
>
> On Thu, Feb 20, 2025 at 3:18 AM Mitchell Burnett  
> wrote:
>
>> Hello,
>>
>> For Bishnu, and Kaj, they report it is specific to the RFDC. In Ken’s 
>> case, was this specific to the RFDC, or other blocks? This was first 
>> addressed in https://github.com/casper-astro/mlib_devel/issues/199 with 
>> fixes coming from https://github.com/casper-astro/mlib_devel/pull/205. 
>> In any case, if the issue is persistent, or exists with another yellow 
>> block, please consider opening an issue on Github in 
>> casper-astro/mlib_devel with minimal working example or details to 
>> reproduce from the main `m2021a` branch. Updates to documentation and/or 
>> tutorials to help others in the future is also encouraged.
>>
>> Best,
>> Mitch 
>>
>> On Feb 19, 2025, at 1:58 AM, Andrew Martens  wrote:
>>
>> Hey Kaj, Ken
>>
>> JASPER helpfully ties various project elements together
>> - the core generated by the System Generator/ Model Composer compiler
>> - HDL cores (registers etc) that attach to ports on the core 
>> - software infrastructure that can access registers etc
>>
>> Usually, the yellow block init scripts change the names of Simulink 
>> input/output ports so that they are predictable and unique. This allows 
>> JASPER to link them to the cores in the Vivado project during compilation. 
>> The scripts are generally set up so that, when an update (e.g before 
>> simulation or compilation) occurs, this port name is updated/changed. It 
>> seems that this automatic updating is not happening and that the RFDC init 
>> script is probably behaving more like the DSP-related ones (that only 
>> change their internals when a mask parameter changes ).
>>
>> Changing the name of the .slx and running just the JASPER backend without 
>> first running the Matlab frontend is not recommended as JASPER internally 
>> no doubt uses the name to predict the port names (and other things), and 
>> will use this new name with project components generated with the old name. 
>> This will cause chaos.
>>
>> Note that this information is slightly dated and refers to the tooflow 
>> pre-JASPER. Jack will need to correct me if he has changed certain 
>> steps/mechanisms.
>>
>> Regards
>> Andrew
>>
>> On Wed, Feb 19, 2025 at 9:18 AM Kaj Wiik  wrote:
>>
>>> Hi Ken,
>>>
>>> Yes, I think I have reported this before, maybe there should be a FAQ 
>>> list somewhere.
>>>
>>> Just renaming SLX in OS (mv a.slx b.slx) will create all kinds of weird 
>>> errors, the correct way to create a file with a different name is to 
>>> save the project with a different name inside Simulink.
>>>
>>> If I remember correctly, the root cause of this is that the .slx file 
>>> contains the file name and is dependent on it. Yes, I cannot think any 
>>> other software doing this and it is a very bad design choice IMHO.
>>>
>>> Cheers,
>>> Kaj
>>>
>>> On 19.2.2025 0.30, Ken Semanov wrote:
>>> > Changing the file names of an SLX file can cause LUT errors during 
>>> > jasper compiles.  These errors are fatal and will drop the compile to 
>>> > command line in Matlab. The CASPER toolflow official documentation 
>>> > should mention this problem, if -- for no other reason --  CASPER 
>>> > doesn't have a mechanism to check whether the current SLX filename has
>>>  
>>> > been changed
>>> > 
>>> > These LUT errors occur in the later stages of implementation, during 
>>> the 
>>> > "Logical Optimization" stages.The blocks in the design

Re: [casper] Changing SLX file names causes LUT errors during jasper compiles.

[Mitchell Burnett]

Hello,

For Bishnu, and Kaj, they report it is specific to the RFDC. In Ken’s case, was 
this specific to the RFDC, or other blocks? This was first addressed in 
https://github.com/casper-astro/mlib_devel/issues/199 with fixes coming from 
https://github.com/casper-astro/mlib_devel/pull/205. In any case, if the issue 
is persistent, or exists with another yellow block, please consider opening an 
issue on Github in casper-astro/mlib_devel with minimal working example or 
details to reproduce from the main `m2021a` branch. Updates to documentation 
and/or tutorials to help others in the future is also encouraged.

Best,
Mitch 

> On Feb 19, 2025, at 1:58 AM, Andrew Martens  wrote:
> 
> Hey Kaj, Ken
> 
> JASPER helpfully ties various project elements together
> - the core generated by the System Generator/ Model Composer compiler
> - HDL cores (registers etc) that attach to ports on the core 
> - software infrastructure that can access registers etc
> 
> Usually, the yellow block init scripts change the names of Simulink 
> input/output ports so that they are predictable and unique. This allows 
> JASPER to link them to the cores in the Vivado project during compilation. 
> The scripts are generally set up so that, when an update (e.g before 
> simulation or compilation) occurs, this port name is updated/changed. It 
> seems that this automatic updating is not happening and that the RFDC init 
> script is probably behaving more like the DSP-related ones (that only change 
> their internals when a mask parameter changes ).
> 
> Changing the name of the .slx and running just the JASPER backend without 
> first running the Matlab frontend is not recommended as JASPER internally no 
> doubt uses the name to predict the port names (and other things), and will 
> use this new name with project components generated with the old name. This 
> will cause chaos.
> 
> Note that this information is slightly dated and refers to the tooflow 
> pre-JASPER. Jack will need to correct me if he has changed certain 
> steps/mechanisms.
> 
> Regards
> Andrew
> 
> On Wed, Feb 19, 2025 at 9:18 AM Kaj Wiik  > wrote:
>> Hi Ken,
>> 
>> Yes, I think I have reported this before, maybe there should be a FAQ 
>> list somewhere.
>> 
>> Just renaming SLX in OS (mv a.slx b.slx) will create all kinds of weird 
>> errors, the correct way to create a file with a different name is to 
>> save the project with a different name inside Simulink.
>> 
>> If I remember correctly, the root cause of this is that the .slx file 
>> contains the file name and is dependent on it. Yes, I cannot think any 
>> other software doing this and it is a very bad design choice IMHO.
>> 
>> Cheers,
>> Kaj
>> 
>> On 19.2.2025 0.30, Ken Semanov wrote:
>> > Changing the file names of an SLX file can cause LUT errors during 
>> > jasper compiles.  These errors are fatal and will drop the compile to 
>> > command line in Matlab. The CASPER toolflow official documentation 
>> > should mention this problem, if -- for no other reason --  CASPER 
>> > doesn't have a mechanism to check whether the current SLX filename has 
>> > been changed
>> > 
>> > These LUT errors occur in the later stages of implementation, during the 
>> > "Logical Optimization" stages.The blocks in the design which invoke 
>> > the missing logic LUT error are random, and seem to be related to the 
>> > order in which optimizer selects blocks for optimizing. For example,  if 
>> > the offending block is removed, the LUT error will migrate to some other 
>> > -- often unrelated -- block in a different portion of the overall 
>> > design. If that new offending block is removed, the LUT error migrates 
>> > to yet another block, and so on ad infinitum.
>> > 
>> > We might ask why this occurs.  A name-changed SLX survives completely 
>> > through the synthesis stage of jasper compile, making the error 
>> > unusually pernicious.
>> > 
>> > 
>> > 
>> > -- 
>> > 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 visit https://groups.google.com/a/ 
>> > 
>> > lists.berkeley.edu/d/msgid/ 
>> > casper/54d66da9-896c-4fd1-888f-53f4f6e3e090n%40lists.berkeley.edu 
>> > 
>> > > > 
>> > casper/54d66da9-896c-4fd1-888f-53f4f6e3e090n%40lists.berkeley.edu 
>> > ?
>> > utm_medium=email&utm_source=footer>.
>> 
>> -- 
>> You received this mess

Re: [casper] Changing SLX file names causes LUT errors during jasper compiles.

[Andrew Martens]

Hey Kaj, Ken

JASPER helpfully ties various project elements together
- the core generated by the System Generator/ Model Composer compiler
- HDL cores (registers etc) that attach to ports on the core
- software infrastructure that can access registers etc

Usually, the yellow block init scripts change the names of Simulink
input/output ports so that they are predictable and unique. This allows
JASPER to link them to the cores in the Vivado project during compilation.
The scripts are generally set up so that, when an update (e.g before
simulation or compilation) occurs, this port name is updated/changed. It
seems that this automatic updating is not happening and that the RFDC init
script is probably behaving more like the DSP-related ones (that only
change their internals when a mask parameter changes ).

Changing the name of the .slx and running just the JASPER backend without
first running the Matlab frontend is not recommended as JASPER internally
no doubt uses the name to predict the port names (and other things), and
will use this new name with project components generated with the old name.
This will cause chaos.

Note that this information is slightly dated and refers to the tooflow
pre-JASPER. Jack will need to correct me if he has changed certain
steps/mechanisms.

Regards
Andrew

On Wed, Feb 19, 2025 at 9:18 AM Kaj Wiik  wrote:

> Hi Ken,
>
> Yes, I think I have reported this before, maybe there should be a FAQ
> list somewhere.
>
> Just renaming SLX in OS (mv a.slx b.slx) will create all kinds of weird
> errors, the correct way to create a file with a different name is to
> save the project with a different name inside Simulink.
>
> If I remember correctly, the root cause of this is that the .slx file
> contains the file name and is dependent on it. Yes, I cannot think any
> other software doing this and it is a very bad design choice IMHO.
>
> Cheers,
> Kaj
>
> On 19.2.2025 0.30, Ken Semanov wrote:
> > Changing the file names of an SLX file can cause LUT errors during
> > jasper compiles.  These errors are fatal and will drop the compile to
> > command line in Matlab. The CASPER toolflow official documentation
> > should mention this problem, if -- for no other reason --  CASPER
> > doesn't have a mechanism to check whether the current SLX filename has
> > been changed
> >
> > These LUT errors occur in the later stages of implementation, during the
> > "Logical Optimization" stages.The blocks in the design which invoke
> > the missing logic LUT error are random, and seem to be related to the
> > order in which optimizer selects blocks for optimizing. For example,  if
> > the offending block is removed, the LUT error will migrate to some other
> > -- often unrelated -- block in a different portion of the overall
> > design. If that new offending block is removed, the LUT error migrates
> > to yet another block, and so on ad infinitum.
> >
> > We might ask why this occurs.  A name-changed SLX survives completely
> > through the synthesis stage of jasper compile, making the error
> > unusually pernicious.
> >
> >
> >
> > --
> > 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 visit https://groups.google.com/a/
> 
> > lists.berkeley.edu/d/msgid/
> 
> > casper/54d66da9-896c-4fd1-888f-53f4f6e3e090n%40lists.berkeley.edu
> >  
> > casper/54d66da9-896c-4fd1-888f-53f4f6e3e090n%40lists.berkeley.edu?
> > utm_medium=email&utm_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 visit
> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/84ad5cf3-dd4f-4053-8f6c-b4e7792ae...@utu.fi
> 
> .
>

Disclaimer

The information contained in this communication from the sender is 
confidential. It is intended solely for use by the recipient and others 
authorized to receive it. If you are not the recipient, you are hereby notified 
that any disclosure, copying, distribution or taking action in relation of the 
contents of this information is strictly prohibited and may be unlawful.

-- 
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

Re: [casper] Changing SLX file names causes LUT errors during jasper compiles.

[Kaj Wiik]

Hi Bishnu,

I got your message just after I sent my reply, sorry.

Cheers,
Kaj

On 19.2.2025 3.50, Bishnu Kumar Sharma wrote:

Hi Ken,
This is one of our issues, and I also faced the same problem. When I 
checked the mailing list of the CASPER, I found somebody already 
reported the problem. Simulink files easily compile with it and you can 
get both the .fpg and .dtbo files and then there is no signal in 
the design. I have attached the screenshot for you to look over. It is 
always wise to check the previous issue raised by Casperites in the 
mailing list that is what i usually do.
- This problem persists when you rename the .slx file name. This is 
because renaming slx file name doesn't change the port name inside 
(mask) the  RFDC block. If I create the file supposedly, 
bishnu_rfsoc4x2_tut_rfdc_real.slx. Inside rfdc I should get ports name 
"rfsoc4x2_tut_rfdc_real_rfdc_m00_axis_tdata" and etc. After changing the 
file to bishnu.slx, inside RFDC block the name of ports should be 
"bishnu_rfdc_m00_axis_tdata", but it doesn't update the name 
automatically, it still is "rfsoc4x2_tut_rfdc_real_rfdc_m00_axis_tdata" 
etc. You have to rename the ports inside it manually or remove the old 
rfdc and keep the new one from the Simulink library. This technique 
works for me, so far. I haven't gone deep inside the source code of 
RFDC, this is what i observed. I hope this helps for you. Thank you.

Best Regards
Bishnu Sharma
Institute of Astronomy and Astrophysics
Academia Sinica



On Wed, Feb 19, 2025 at 6:30 AM Ken Semanov > wrote:


Changing the file names of an SLX file can cause LUT errors during
jasper compiles.  These errors are fatal and will drop the compile
to command line in Matlab. The CASPER toolflow official
documentation should mention this problem, if -- for no other reason
--  CASPER doesn't have a mechanism to check whether the current SLX
filename has been changed

These LUT errors occur in the later stages of implementation, during
the "Logical Optimization" stages.    The blocks in the design which
invoke the missing logic LUT error are random, and seem to be
related to the order in which optimizer selects blocks for
optimizing. For example,  if the offending block is removed, the LUT
error will migrate to some other -- often unrelated -- block in a
different portion of the overall design. If that new offending block
is removed, the LUT error migrates to yet another block, and so on
ad infinitum.

We might ask why this occurs.  A name-changed SLX survives
completely through the synthesis stage of jasper compile, making the
error unusually pernicious.



-- 
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 visit https://groups.google.com/a/
lists.berkeley.edu/d/msgid/
casper/54d66da9-896c-4fd1-888f-53f4f6e3e090n%40lists.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 view this discussion visit https://groups.google.com/a/ 
lists.berkeley.edu/d/msgid/casper/ 
CACqpYn4TwOon67hRw17k0ttRF2KRwSa7YA5W%3DWqGLW2A_Vermg%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 visit 
https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/d94a7876-a8a6-4307-b19c-b1d02843f5f9%40utu.fi.

Re: [casper] Changing SLX file names causes LUT errors during jasper compiles.

[Kaj Wiik]

Hi Ken,

Yes, I think I have reported this before, maybe there should be a FAQ 
list somewhere.


Just renaming SLX in OS (mv a.slx b.slx) will create all kinds of weird 
errors, the correct way to create a file with a different name is to 
save the project with a different name inside Simulink.


If I remember correctly, the root cause of this is that the .slx file 
contains the file name and is dependent on it. Yes, I cannot think any 
other software doing this and it is a very bad design choice IMHO.


Cheers,
Kaj

On 19.2.2025 0.30, Ken Semanov wrote:
Changing the file names of an SLX file can cause LUT errors during 
jasper compiles.  These errors are fatal and will drop the compile to 
command line in Matlab. The CASPER toolflow official documentation 
should mention this problem, if -- for no other reason --  CASPER 
doesn't have a mechanism to check whether the current SLX filename has 
been changed


These LUT errors occur in the later stages of implementation, during the 
"Logical Optimization" stages.    The blocks in the design which invoke 
the missing logic LUT error are random, and seem to be related to the 
order in which optimizer selects blocks for optimizing. For example,  if 
the offending block is removed, the LUT error will migrate to some other 
-- often unrelated -- block in a different portion of the overall 
design. If that new offending block is removed, the LUT error migrates 
to yet another block, and so on ad infinitum.


We might ask why this occurs.  A name-changed SLX survives completely 
through the synthesis stage of jasper compile, making the error 
unusually pernicious.




--
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 visit https://groups.google.com/a/ 
lists.berkeley.edu/d/msgid/ 
casper/54d66da9-896c-4fd1-888f-53f4f6e3e090n%40lists.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 view this discussion visit 
https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/84ad5cf3-dd4f-4053-8f6c-b4e7792aefb6%40utu.fi.

[casper] Changing SLX file names causes LUT errors during jasper compiles.

[Ken Semanov]

Changing the file names of an SLX file can cause LUT errors during jasper 
compiles.  These errors are fatal and will drop the compile to command line 
in Matlab.The CASPER toolflow official documentation should mention 
this problem, if -- for no other reason --  CASPER doesn't have a mechanism 
to check whether the current SLX filename has been changed 

These LUT errors occur in the later stages of implementation, during the 
"Logical Optimization" stages.The blocks in the design which invoke the 
missing logic LUT error are random, and seem to be related to the order in 
which optimizer selects blocks for optimizing. For example,  if the 
offending block is removed, the LUT error will migrate to some other -- 
often unrelated -- block in a different portion of the overall design. If 
that new offending block is removed, the LUT error migrates to yet another 
block, and so on ad infinitum. 

We might ask why this occurs.  A name-changed SLX survives completely 
through the synthesis stage of jasper compile, making the error unusually 
pernicious. 



-- 
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 visit 
https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/54d66da9-896c-4fd1-888f-53f4f6e3e090n%40lists.berkeley.edu.