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>
