I had the same issue and found that when copying the block or changing
the name of the slx doesnt update the internal names (I faced the same
problem in some old ROACH models).
What I found to work is to open the dialog of the block, modify a
parameter and apply the changes, then return the previous working
value and save the changes of the block. For the RFDC what I do is to
change the sampling rate to a gigantic number (if you use a reasonable
number, some parameters may change automatically) then a warning
appears when applying the changes bcs the sample rate is not correct,
and finally return to the previous sampling rate and save. With that
it should update the names.


El vie, 2 jun 2023 a las 8:27, Jason Gallicchio (<[email protected]>) escribió:
>
> Yes, this seems to be the problem. If by "look underneath the RFDC yellow 
> block," you mean go into the BLOCK toolbar and click Expand. The gateways 
> that are revealed do include the name of the original file, not the renamed 
> file.
>
> Creating a new RFDC block and Expanding it does give the gateways the 
> new-file names, but
> 1. I won't be able to test if it works on the RFSoC board until Monday here 
> in Australia.
> 2. If it still didn't work, it probably would be because I didn't get the 
> hundred fiddly block parameter settings exactly the same.
>
> I'll raise an issue on the mlib_devel repo.
>
> Thank you, though for making me feel slightly saner again,
> Jason
>
>
> On Fri, Jun 2, 2023 at 8:04 PM Jack Hickish <[email protected]> wrote:
>>
>> Hi Jason,
>>
>> If you look underneath the RFDC yellow block, the gateways should have names 
>> which include a prefix which is the model name + RFDC block name. Are these 
>> correct in your broken models, or do they reflect a previous model name?
>> If they are wrong, does creating a new RFDC block and reconfiguring it sort 
>> things?
>> If this turns out to be the problem, please raise an issue on the mlib_devel 
>> repo, because this is definitely a bug in the RFDC mask.
>>
>> Cheers
>> Jack
>>
>> On Fri, 2 Jun 2023 at 06:25, Jason Gallicchio <[email protected]> wrote:
>>>
>>> I can run jasper to build rfsoc4x2_tut_rfdc_real.slx  and 
>>> rfsoc4x2_tut_spec.slx examples into .fpg and .dtbo files, and they work. 
>>> However, if I rename the .slx file or copy it to a new file to make 
>>> changes, it still builds, but the ADC only returns -1.
>>>
>>> When I say ANY changes to the .slx make the ADC return all -1, this has 
>>> been reduced to even trivial things:
>>> * renaming the .slx files with mv
>>> * copying an .slx file to a new name with cp
>>> * Save As within simulink
>>> * copying and pasting the .slx contents into a new file
>>>
>>> This is an embarrassing and trivial-sounding issue, but I don't understand 
>>> enough about simulink or Model Composer to understand how this could be. Is 
>>> there a filename check or checksum buried in some block in these .slx files 
>>> or some casperfpga init code? I can't find any.
>>>
>>> I've also failed in a similar way with the rfdc when trying to build up "by 
>>> hand" any project with the RFDC yellow block, including the RFDC tutorial 
>>> #2.
>>>
>>> In case it's relevant I'm using all of the recommended versions:
>>> * Ubuntu 20.04.6 LTS (in a Virtual Box virtual machine)
>>> * Matlab R2021a
>>> * Vivado 2021.1
>>> * casperfpga branch py38  (not mega-merge as suggested on Getting Started)
>>> * mlib_devel branch m2021a
>>>
>>> Thanks,
>>> Jason
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups 
>>> "[email protected]" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>> email to [email protected].
>>> To view this discussion on the web visit 
>>> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/f4208d93-23e7-4471-a887-177b1fa8c1b9n%40lists.berkeley.edu.
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "[email protected]" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to [email protected].
>> To view this discussion on the web visit 
>> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAG1GKSnU3Wq8wjQfjNM8rmox6gWkQr_p6RzSO-9Mn-6gJD%3DD2A%40mail.gmail.com.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "[email protected]" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to [email protected].
> To view this discussion on the web visit 
> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAFOBgPVpVQw9uV3Zahpg0-_hM7hpxidT4fDCv7nrYeTbw37KvA%40mail.gmail.com.

-- 
You received this message because you are subscribed to the Google Groups 
"[email protected]" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAASoV%3DNY01__kGPXwonJuqOijzk4VkU0Jurb-1gnynGH5ePW8w%40mail.gmail.com.

Reply via email to