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 <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/73bf6f36-b679-449a-a739-da21a23105fbn%40lists.berkeley.edu.
