Thanks for the update, Joe. The only way the gateway blocks would get renamed to "xps_library_..." is if the upgrade advisor is replacing the ADC16 block from the library. In theory, this should run the mask init script which would rename the block according to CASPER naming conventions. Since the rename is not happening, either the mask init script is not being run or the block parameters (specifically UserData) are being copied to the new block before the mask init script runs (which would trick the mask init script into thinking that it already renamed the gateway blocks).
While gen_xps_mod_mhs.m is the file that's complaining about gateway block X not being named "the_expected_name", it only runs after the design has been generated to a netlist using the unexpected name for the gateway block, so renaming the gateway block at that point (i.e. from gen_xps_mod_mhs) would not have the desired effect. I think the best place to fix this is either the ADC16 mask init script itself (i.e. make it more robust in its renaming of the gateway blocks) or in a DRC script. Putting the fix in a generic DRC script would benefit all blocks rather than just one specific block. Thanks again, Dave On Sep 24, 2013, at 6:52 AM, Kujawski, Joseph wrote: > David, > > The biggest issue with using the upgrade advisor is that it changes the names > of the gateway blocks within the block adc16x250_8 from > 'adc_test_adc16x250_8_a1' to 'xps_library_ADCs_adc16x250_8_a1'. Whoever > wrote the tool 'gen_xps_mod_mhs.m' can probably fix this issue easily. If I > can trace through the code for a complete correction to the issue, I'll let > you know. > > -Joe Kujawski > > > On Mon, Sep 23, 2013 at 4:24 PM, Kujawski, Joseph <[email protected]> wrote: > David, > > The warnings reported by Simulink are all of the type that indicates that the > file is not going to be forward compatible. The automated fix requires you > to save the model into the newer .slx format. I am investigating the issue > and will let you know if something useful comes out of the investigation. > > -Joe Kujawski > > > On Mon, Sep 23, 2013 at 1:10 PM, David MacMahon <[email protected]> > wrote: > Hi, Joe, > > I never use these advisors. What sort of errors are they reporting and how > are you clearing them? > > Dave > > On Sep 23, 2013, at 9:39 AM, Kujawski, Joseph wrote: > > > Here is an update on the problem: > > > > This problem was cleared up when I installed the new mlib_devel library > > this morning, however, when I went through the model and used Matlab's > > Upgrade advisor and Model Advisor and clearing all the errors, Matlab > > changes the model enough that this particular error cropped up again. > > > > I'll let you know if I am able to clear the problem without reverting to > > the original mlib_devel version. In the meantime, anyone working on this > > toolchain might want to look into the issue as it may indicate that there > > will be compatibility issues in the future. > > > > -Joe Kujawski > > > > > > -- > > ************************************** > > * Joe Kujawski > > * Siena College > > * Dept. of Physics and Astronomy, RB 113 > > * 515 Loudon Road > > * Loudonville, NY 12211-1462 > > * > > * Email: [email protected] > > * Phone: 518-782-6885 > > * Fax: 518-783-2986 > > ************************************** > > > > > > > -- > ************************************** > * Joe Kujawski > * Siena College > * Dept. of Physics and Astronomy, RB 113 > * 515 Loudon Road > * Loudonville, NY 12211-1462 > * > * Email: [email protected] > * Phone: 518-782-6885 > * Fax: 518-783-2986 > ************************************** > > > > > -- > ************************************** > * Joe Kujawski > * Siena College > * Dept. of Physics and Astronomy, RB 113 > * 515 Loudon Road > * Loudonville, NY 12211-1462 > * > * Email: [email protected] > * Phone: 518-782-6885 > * Fax: 518-783-2986 > ************************************** >
