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 <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 "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/d8f05b12-93c4-4ae0-b400-197ec0d064a9n%40lists.berkeley.edu.
