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 <mitch.c...@gmail.com> >> 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 <and...@sarao.ac.za> 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 <kaj....@utu.fi> 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 "cas...@lists.berkeley.edu" group. >>>> > To unsubscribe from this group and stop receiving emails from it, send >>>> >>>> > an email to casper+un...@lists.berkeley.edu >>>> > <mailto:casper+un...@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 >>>> > <https://groups.google.com/a/lists.berkeley.edu/d/msgid/ >>>> > 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 "cas...@lists.berkeley.edu" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to casper+un...@lists.berkeley.edu. >>>> To view this discussion visit >>>> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/84ad5cf3-dd4f-4053...@utu.fi >>>> >>>> <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 "cas...@lists.berkeley.edu" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to casper+un...@lists.berkeley.edu. >>> To view this discussion visit >>> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CADEwHTdxpHaTLw%3DD%3DjxnYtA5qF6%2BYV%3DZEOzDHyyOSBAZjwwVBw%40mail.gmail.com >>> >>> <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CADEwHTdxpHaTLw%3DD%3DjxnYtA5qF6%2BYV%3DZEOzDHyyOSBAZjwwVBw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "cas...@lists.berkeley.edu" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to casper+un...@lists.berkeley.edu. >>> >> To view this discussion visit >>> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/A50A853D-68ED-44A9-A21C-B5C468F3AC70%40gmail.com >>> >>> <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/A50A853D-68ED-44A9-A21C-B5C468F3AC70%40gmail.com?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/8eefe302-60f9-427d-86cf-9555e381e6d4n%40lists.berkeley.edu.
