• Skip to main content
  • Skip to search
  • Skip to footer
Cadence Home
  • This search text may be transcribed, used, stored, or accessed by our third-party service providers per our Cookie Policy and Privacy Policy.

  1. Community Forums
  2. Custom IC Design
  3. Trim Methodology in Maestro Assembler. The trim value is...

Stats

  • Locked Locked
  • Replies 5
  • Subscribers 125
  • Views 4194
  • Members are here 0
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Trim Methodology in Maestro Assembler. The trim value is out of range and the cross() function returns no value. How can I get the trim value as "min" or "max"

IceTea
IceTea over 3 years ago

The tool versions are below:

Virtuoso IC 6.1.8-64b.500.15
Spectre 19.1.0.541.isr14

I developed a trim procedure in Maestro Assembler using the calcVal() function. Assume a trim range from 0 to 15. If the trim range is not large enough, the trim procedure doesn't return a value because it's out of the trim range. In this case either 0 or 15 should be the reported value, depending on which value (0 or 15) is the closest to the desired trimming value. How can this be implemented? Thank you

  • Cancel
  • ShawnLogan
    ShawnLogan over 3 years ago

    Dear IceTea,

    I don't know the details of your calculator function so it is hard to give you specific advice. If it were me, I would use your calculator expressions in an ocean script ( which you add as an Assembler output) with something like the following:

    last_trim_val = <your prior trim result with valid code between 1 and 14>
    trim_val = <your result> ( which may fail due to cross function)

    if(abs(last_trim_val-15) < abs(last_trim_val - 0) then

    trim_val = if(trim_val trim_val 15)

    else

    trim_val = if(trim_val trim_val 0)

    )

    last_trim_val = trim_val

    Does this help IceTea? Others may have a more efficient way to approach this, but this came to mind quickly. Basically, if the cross function yields nil, the two of statements will catch that and assign trim_val to the closest last value to 15 or 0.

    Shawn

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • IceTea
    IceTea over 3 years ago in reply to ShawnLogan

    Hi Shawn,

    I think I found a way:

    v_out is the output of interest.

    I try to find the trim code for which v_out = v_th

    To find the best trim code irrespective if v_th is in the trimming range or not, I need to do a sweep of v_out as a function of the trimming code and then apply the xmin function to the abs(v_out - v_th), like below:

    xmin(abs(v_out - v_th)  

    That's all thank you,

    IceTea

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • IceTea
    IceTea over 3 years ago in reply to ShawnLogan

    Shawn,

    I need to explain a little bit more. I need to find the trim parameter called TRIM, such that the DC value of a node voltage called v_out equals a certain value say 1.25V. Of course v_out is a function of the TRIM value. To do that I perform a DC sweep of the trim parameter TRIM  between 0 and 15 with a step of 1 (or it could be even less like 0.1). I'm plotting v_out, obviously. The cross() function has as an input v_out with a threshold  v_th=1.25V. The round(croos()) function reports the integer TRIM value that satisfies the criteria v_out=1.25V. Now, in certain circuit conditions like temperature, process corners, etc. v_out may not cross 1.25V while TRIM goes from 0 to 15. The closest v_out to 1.25V could be at TRIM=0 or TRIM=15. In this case the round(cross()) function will return nil, the message in Assembler is "eval error". Bottom line is that I'm not doing a search iteratively for TRIM where there is a "previous" and "present" value. I hope this clarifies my problem and shows why I have a hard time understanding how the above code would help. 

    In the meanwhile I developed something that works, but getting an idea for an ocean script embedded in the Assembler sim flow would be nice for me because I've never done something like this in the past.

    Here's what I've done: since v_out is very close to a linear function of TRIM, after the DC sweep of TRIM, I calculate:

    abs(v_out - v_th) - ymin(abs(v_out - v_th)) - 0.1*vout_trim_step

     where:

    v_th is the value we need v_out trimmed at (already defined above)

    vout_trim_step is the voltage step when TRIM is increased by 1.

    I needed to subtract a small fraction of vout_trim_step to make sure the cross() function will detect a zero crossing. So last step was:

    round(cross( abs(v_out - v_th) - ymin(abs(v_out - v_th)) - 0.1*vout_trim_step)...)

    The problem I had is that it didn't work in the  above format and I had to create an intermediary variable:

    int_var=abs(v_out - v_th) - ymin(abs(v_out - v_th)) - 0.1*vout_trim_step

    and then apply the round(cross()) function to int_var

    My first question is: why isn't the round(cross( abs(v_out - v_th) - ymin(abs(v_out - v_th)) - 0.1*vout_trim_step)...) working, because I tested the expression: 

    abs(v_out - v_th) - ymin(abs(v_out - v_th)) - 0.1*vout_trim_step 

    and it is correct. Why do I need an intermediate variable like int_var?

    The second question is how would I do that with an ocean script as you suggested. If you have an example that I could start from, that'd be great, thank you, sorry for the long message.

    IceTea  

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • ShawnLogan
    ShawnLogan over 3 years ago in reply to IceTea

    Dear IceTea,

    I re-read your latest clarification post and your prior post and have a "big picture" based comment. In all of your examples, you are relying essentially on a linear search with the exception of the method you settled on - which is still a version of a linear search.

    A far more efficient search methodology is a binary search with the possible exception if the time required for each trial simulation is very, very small. I have an ocean script shell for a binary search that can be run as a pre-run script in Assembler. In addition, Cadence provides a rapid adoption kit for calibrated circuits and I just examined it. It also has one example of a binary search staring on page 67, but its script is coded in SKILL (not ocean). I'm not sure which language is your favorite, but both scripts serve the same purpose. This will eliminate the cross() function issues you are encountering. The RAK is at URL:

    support.cadence.com/.../ArticleAttachmentPortal

    Let me know if you would like to inspect the binary search example I have in ocean.

    Shawn

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • IceTea
    IceTea over 3 years ago in reply to ShawnLogan

    Hi Shawn,

    Thank you for taking the time to answer. I already read and executed the examples in the RAK for calibration. That was the starting point for my trim flow. I'm really not fluent in skill or ocean. I tried to resolve my trim/calibration issues using the flow provided by ADE Assembler. One further detail: my circuit provides a reference voltage based on the bandgap circuit and it provides bias currents using a voltage-to-current converter based on the reference voltage as well. Both the reference voltage and the bias currents need trimming so essentially I need two trimming processes. First I trim the reference voltage. Then I pass the trim code to the second test case that performs the trim of the bias current. Then both trim codes are passed to the third test that verifies the functionality of the entire circuit over corners, temperature and supply voltages. To do all that in ocean (or skill) seems quite involved to me. I'm sure that a designer skilled in... skill (or ocean) can do it, but to be honest I was impressed that ADE Assembler was designed in such a way to make this task quite easy by just programming this using the flow of the ADE Assembler. Keep in mind that, at least in my case, the trim is done at a specific temperature and supply voltage, after which the verification of functionality is done at different supply voltages (and temperatures, but this is usually swept). I'm sure this creates additional programming twists in ocean. I was able to solve this with an additional Design Variable that is set only during trim steps. One more thing: it's true that my trim is based on a linear search and a binary search is more efficient. However, these trim procedures being based on DC sweeps, they really don't impact the overall sim time by much. Even if larger test benches, that would use the bandgap circuit, would require the trim steps, one could use a config view for the trim steps in which the circuits not needed for trim are omitted from netlisting (by setting their view to "symbol") thus minimizing the sim time for the trim stage.  

    To answer your question, yes I'd like to look at the ocean script, it will take a while to understand it.

    I also have a question about ocean scripts in the context of the ADE assembler. I noticed that ADE Assembler allows for a pre-run ocean script. Is it possible to include an ocean script between tests, or at the end of all tests, in the Assembler?

    Thank you,

    IceTea

    P.S. I'm not against ocean. I could not find a self paced course on ocean, only instructor based. Did I miss it? How would you recommend a DIY methodology to learn ocean?

    P.P.S. Found this post: https://support.cadence.com/apex/ArticleAttachmentPortal?id=a1Od0000000nXS2EAM&pageName=ArticleContent Is CCR 1043333 already implemented, or do I need to include abXLRunAfterSim.ils in my .cdsinit?

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel

Community Guidelines

The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.

© 2025 Cadence Design Systems, Inc. All Rights Reserved.

  • Terms of Use
  • Privacy
  • Cookie Policy
  • US Trademarks
  • Do Not Sell or Share My Personal Information