string to symbol and left side of assignment

Discussion in 'Cadence' started by bu-bu, Mar 4, 2009.

  1. bu-bu

    bu-bu Guest

    Hello All,

    I don't know how to create a symbol and use it later in the left side
    of assignement.

    I would like to create a symbol, let say strcat("My_" Var)
    (with Var = "Symbol")

    Then convert it into a symbol (using stringToSymbol function)

    and then, using this Symbol in left side of assignement : My_Symbol =
    result_of_my_function

    I really need My_Symbol to be unrepeatable. My_Symbol will be
    generated in a procedure that will be called many times: I need to
    sort my data!

    I tried stringToSymbol(strcat("My_" Var)) = result_of_my_function but
    i got error message:

    *WARNING* (Parser): illegal left hand side of assignment operator

    how can i do that ? I tried with sprintf, println, and so on, but
    resultless.

    thanks a lot for your help.

    Best,

    bubu
     
    bu-bu, Mar 4, 2009
    #1
  2. bu-bu wrote, on 03/04/09 03:05:
    First of all you need to think carefully if you really want to do this - it
    sounds as if you may be generating a lot of symbols - you might be better off
    using an associative array (or hash).

    But here's how you'd do it:

    result=23
    Var="Symbol"
    ; concat directly concatenates and produces a symbol
    varName=concat("My_" Var)
    ; use the set function to set a variable given its name
    set(varName result)
    ; if you need to retrieve the value, you can do:
    symeval(varName)

    Alternatively, you could do:

    result=23
    Var="Symbol"
    unless(boundp('myTab)
    myTab=makeTable('myTab)
    )
    myTab[Var]=result
    myTab["Schematic"]=45
    ; and then to access it:
    myTab[Var] => 23
    ; or loop over the keys
    foreach(key myTab
    printf("Key: %L Value: %L\n" key myTab[key])
    )

    Regards,

    Andrew.
     
    Andrew Beckett, Mar 4, 2009
    #2
  3. bu-bu

    bu-bu Guest

    Hello Andrew,

    Thanks a lot for you reply.

    your code does exactly what i need.
    I don't want to use an array because i think it will be difficult to
    manage (but i'm not a sharp knife in programing neither)

    Let me explain you:
    i have a list of topcells.
    for each topcell, i have a list of devices and a list of nets.

    Using Calibre, i know the geometry of each net / device, for each
    topcell.

    now i'm creating a user interface: user can select the topcell, the
    device and the net to display.

    The display will be done in the cellview using hilight functions.
    User can decide either display or erase (Hilight~>enable = t or nil)
    the device/net

    So i wanted to create symbols like : Cell_Name_Device or
    Cell_Name_Netname

    to do a Cell_Name_Netname~>enable = t or nil.

    Do you think better to use an array ?

    Thanks and regards,

    bubu
     
    bu-bu, Mar 4, 2009
    #3
  4. bu-bu

    I-F AB Guest

    Hi,
    I had something like this before.
    I also wanted to avoid using arrays since I wasn't familiar on how
    they worked.
    The Cadence AE (Quek) I asked suggested that in my case, I could use
    evalstring() to produce something like:
    evalstring( strcat( "Object_Data_" elem " = \"" elem_data "\"" ) )
    so if variable 'elem' = "Type" and 'elem_data' = "path", then I will
    have something such as:
    Object_Data_Type = "path"

    But I'm not sure which method is faster to run.

    Best regards,
    I-F AB
     
    I-F AB, Mar 5, 2009
    #4
  5. bu-bu wrote, on 03/04/09 17:25:
    You really should NOT use symbols for this. Symbols do not get garbage
    collected, so they end up permanently in the symbol table - if you're doing this
    on a design with lots of nets, you could easily end up creating lots of symbols,
    and lots of variables, and lots of unreclaimable garbage. This will waste
    memory, and also slow down symbol table access. Since symbol table access is
    used for everything in SKILL, this is NOT a good idea!

    Association tables are very easy to use. The idea is that they look like arrays,
    but the index can be anything. You can think of them as being a little database,
    with a key and a value. The key can be any type you like, and they don't even
    have to have the same datatype for all keys.

    So, for example, you can create one like this:

    MYglobalHilightTable=makeTable('globTab nil)

    This will create a new table. The 'globTab is not important - it does not have
    to be unique - it is just a name that gets shown in the print representation of
    the table. So if you type MYglobalHilightTable, you'll see it returns
    table:globTab. The nil (second argument) is optional, but it defines the value
    that will be returned if the key does not exist in the table. If you don't
    specify this, the default is 'unbound - which can cause you trouble if you're
    not careful, so something like nil is often a good idea.

    Then you can do:

    entry=strcat(cellName "_" netName)
    MYglobalHilightTable[entry]=geCreateHilightSet(...)

    and then when you need it later, you can do:

    MYglobalHilightTable[entry]~>enable=t

    tables can be iterated over with foreach(), and you can use remove() to remove
    keys from the table.

    They are hashed (like the symbol table in fact), and so are easy and quick to
    access data in.

    Rather than doing the strcat, you could also do:

    MYglobalHilightTable[list(cellName netName)]=geCreateHilightSet(...)

    MYglobalHilightTable[list(cellName netName)]~>enable=t

    i.e. you can quite happy use lists as the keys into the table.

    So they're not hard to use - hopefully you've followed my explanation?

    Regards,

    Andrew.
     
    Andrew Beckett, Mar 5, 2009
    #5
  6. I-F AB wrote, on 03/05/09 03:02:
    Oh dear. This has compounded bad practice on bad practice!

    For a start, using symbols like this is bad (see my reply to bu-bu just now),
    and using evalstring for run-time evaluation is bad. Both are a good way (with
    large amounts of data) of killing performance. If the symbol table gets very
    large, you can kill the performance of the rest of DFII, if you're not careful.

    Even if you were going to stick with the bad practice of using symbols for
    storage, you should have done:

    set(concat("Object_Data_" elem) elem_data)

    But better would have been to do:

    ; create the table once
    Object_Data=makeTable('objectData nil)
    ; populate it with a value
    Object_Data[elem]=elem_data
    ; reference the value
    Object_Data["Type"] => "path"

    Regards,

    Andrew.
     
    Andrew Beckett, Mar 5, 2009
    #6
  7. bu-bu

    bu-bu Guest

    Hello Andrew,

    You're right, i will have a lot of symbols to create.

    So i will try to create an association table. it looks easy with the
    example you gave me.

    thanks a lot for your precious help.

    Best,

    bubu
     
    bu-bu, Mar 6, 2009
    #7
Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.