Hi
Jason and I have been talking and it seems that David's idea is a good
idea. We propose the following;
* UserData consists of a struct containing two values ('state',
'parameters'). (Other fields could be added in future.)
* These are updated at the end of every script in "save_state".
'state' contains the hash, 'parameters' contains a struct that has
fields with the names and values extracted from the parameters passed
in.
* A hidden parameter (num_updates) in every mask (not displayed) is
incremented at the end of the script. This will force the
initialisation script to be executed next time the mask is updated as
Matlab does not run the script unless something actually changes in
the mask parameters (regardless of underlying variable values).
* The scripts would need to be updated to *not* back-populate the
parameters at the end so that the call is not over-written with the
actual values so as to prevent too-large parameters being written into
the mask.
* Mask values of underlying blocks could be updated with a call to the
Userdata struct which would contain the data. (e.g. "getfield(
getfield( get_param(gcb,'UserData'), 'parameters'), 'foo')" ).
This has the following advantages;
* Initialisation scripts could remain as-is. Updates need only to be
made to infrastructure scripts.
* This should allow the user to twiddle with generated values if they
want to (via direct editing, or updates to 'UserData')).
* It should also prevent name space pollution while allowing the user
to fiddle with their own variables.
* It also preserves the values used to initialise the block without
having long values in parameter boxes lying around.
Comments/questions?
Cheers
Andrew
2008/5/21 David MacMahon <[email protected]>:
> As an alternative to multiple global variables, perhaps we could use the
> UserData parameter to allow storage of values (i.e. a stuct of values).
> Then the block's mask (i.e. dialog field) could access the fields in the
> block's UserData structure using the obviously-not-too-long string
> "get_user_data(gcb,'coefs')", assuming that the mask_init method populated
> the "coefs" field of the UserData structure. Here is the get_user_data.m
> file...
>
> function val = get_user_data(blk, field)
> ud = get_param(blk, 'UserData');
> val = getfield(ud, field);
> end
>
> For storing data in the UserData parameter of Xilinx blocks, this would work
> fine as-is, but because CASPER blocks already use UserData, we would need to
> change our handling of the UserData parameter *if* we want to support this
> technique with casper blocks. I don't know of any blocks that require
> hugely long strings in their masks, but there may be some (does anybody
> know?). If we wanted to do this, it could be done by using UserData as a
> structure with one field used to save state info and other fields to save,
> well, user data.
>
> This UserData technique would prevent pollution of the global namespace and
> save values with the models.
>
> Dave
>
> On May 21, 2008, at 1:00 , Jason Manley wrote:
>>
>> Good idea with the auto-check workspace for the variables! They have to be
>> independently named because sometimes you have multiple versions of the same
>> block in a design (eg, two PFBs). But we don't want the workspace filling up
>> with random variables each time the design is updated, so there would need
>> to be some housekeeping in there too.
>>
>> Andrew and I have just been chatting, and we think possibly creating the
>> global variables based on the name of the parent block (rather than the
>> time) would keep things tidy, because you wouldn't need to keep track of the
>> last variable name used - you'd know it explicitly. If this variable doesn't
>> exist, it will be created. Otherwise, it will just be updated. This does
>> mean that if the user changes the name of a block, there will potentially be
>> an unused variable floating in the workspace, but I think we can live with a
>> few extra kB of memory in use.
>>
>> I'm not sure how same-state/save-state will deal with it if we keep using
>> the same variable - it might see that the string passed to the child blocks
>> hasn't changed and then not update the block, even though the value stored
>> in that variable has changed. I remember we had this problem, but I'm not
>> sure if Mark fixed it. If not, it's a simple enough update to these scripts
>> to just evaluate all passed variables and then store/compare the value
>> rather than the name.
>>
>> Jason
>>
>>
>> On 21 May 2008, at 09:26, G Jones wrote:
>>
>>> One problem with using global variables is they could be accidentally
>>> deleted from the workspace, so it may be good to have the routine that
>>> checks if the block needs to be updated also check that the required
>>> global variables are still present in the workspace, and if not,
>>> regenerate them.
>>> I thought about just rounding the coefficients, but it seemed like it
>>> would only allow another power of two or so in spectrum length.
>>> Glenn
>>>
>>> On 5/21/08, Jason Manley <[email protected]> wrote:
>>>>
>>>> haha! Funny you should suggest this now. We've just had a meeting about
>>>> this
>>>> string length limitation and the porting teams has decided that we will
>>>> use
>>>> global variables to solve it. As a stop-gap (and to prevent matlab from
>>>> dying for unknown reasons), I've checked-in a version of the PFB to SVN
>>>> that
>>>> brings up a warning box when the maximum string length is exceeded.
>>>> There is
>>>> also an option to round-off coefficients now and save some space (else
>>>> the
>>>> string contains 15 significant decimal places, which is excessive for
>>>> most
>>>> 8-bit applications).
>>>>
>>>> Andrew Martens will be writing a guide for building future blocks, which
>>>> will mandate global variables for long strings and scripts to build the
>>>> blocks from scratch. It will probably include a template to help guys
>>>> get
>>>> started. This will demonstrate the preferred method of passing variables
>>>> to
>>>> sub-blocks etc. Also, I think safety checks (like the afore-mentioned
>>>> string
>>>> length limit) are essential. Crashing Matlabs are not cool.
>>>>
>>>> Any further ideas?
>>>>
>>>> Jason
>>>>
>>>>
>>>>
>>>>
>>>> On 21 May 2008, at 02:05, G Jones wrote:
>>>>
>>>>
>>>>>
>>>>> Hi,
>>>>> This code seems to work for making long PFBs with the green blocks. It
>>>>> could probably be improved, but at least it's functional. Basically it
>>>>> assigns the 'buf' variable that contains the PFB coefficients to a
>>>>> unique name in the base Matlab workspace. I couldn't manage to get it
>>>>> to work assigning it in any other namespace. The unique name I chose
>>>>> is just related to the current time, so is meaningless. A more
>>>>> meaningful unique name could probably be constructed, but this was
>>>>> easy. Let me know if anyone has a better fix for this problem.
>>>>> Glenn
>>>>> <pfb_coeff_gen_init.m>
>>>>>
>>>>
>>>>
>>
>>
>
>
>
