Best primers for Ruby scripting, as used in DRC / extract / LVS?

Being no sort of programmer, I find it difficult to grasp the (object oriented?) style, syntax, meaning of the scripts I see. I think I need a pretty basic tutorial about how the verification-script "this.that.other_stuff" formulations work. But I've waded through a few Ruby tutorial Google hits and it seems these do not look the same, really (maybe it's all balled up with the data structure and name-specificity, or something, but my decades-ago FORTRAN, BASIC, Pascal coursework provides me no sense of what's up, let alone how to put my thoughts into code that works -for the task- ("Hello, World" ain't it).

So I'd like to ask the folks who are any good at this, to recommend what they found the best "leg up" in grokking the Ruby script styles that Klayout verification employs. Free is good, words of one syl-lab-le even better, but relevance is key (I can't let myself be dragged through hours / days of irrelevant slow paced video when what I really need is to get this chip design wrapped up). Just pound the "smart screw" into my head far enough that I can translate the foundry's PDF groundrules into a better-than-1/2-a$$ DRC deck and get, if not LVS, at least a layout derived subcircuit that I can simulate for function.

My offer to pay engineering rates for help / tutelage still stands. Just on the off chance that my coding skills remain resistant to development, and in the interest of expedience.

Comments

  • I guess giving a recommendation myself isn't helpful. Obviously I have no experience about how to get up on speed .. :)

    I'm actually thinking whether this space here isn't too secluded to attract a big enough community for this kind of support. The reason why I'm maintaining the Forum is purely historical and honestly it's some maintenance burden. Maybe Reddit (or some other place) is better and such a request reaches a bigger audience?

    And there is one thing you already mentioned: if the design rules you are dealing with were public, there is chance someone already had translated the rules or it would be very easy to get help with a specific detail. I don't know why foundries still think that there is a business reason for keeping design rules secret. The Linux story (and many others) should have told everyone that openness is a business success factor rather than a risk. The captive customer is a Medieval concept and I can't wait to see the first foundry to open it's PDK.

    Matthias

  • Thanks, Matthias,

    All I know is, I signed a NDA and the foundry is concerned about preserving their process IP (despite that they've bought the fab from its previous owner and the technology in question is as standard as "standard linear bipolar" gets and they have no real run-rate on the technology). I have a PDF groundrules package and a couple of Tanner L-Edit verification decks to work from.

    When I was an "inside foundry guy" my employers were the same way. Competitive advantage must be witheld, no possible leg-up may be given. Certainly when you're on the front ramp of technology development and product development, in a competitive market segment, this is a valid concern (Intel vs TSMC vs GlobalFoundries vs Samsung all trying to get to the next node first) but I agree (with zero authority to do about) that a 40 year old technology probably doesn't have any secrets worth keeping. Changes nothing. This is all "corporate best practices" set by business school types who couldn't give a damn about making anything free, no matter the benefit to people who won't pay anything this quarter.

    I'm believing that I could mash the width and space rules into shape using your "example PDK" material, but these guys do some crazy stuff with recognizing device types and terminals that I doubt sane CMOS people would, and I would need to show one example (with details suitably modified that nothing is given away) and try to get its Ruby equivalent, so then I can knock down that part and on to the next.

    My preference is for text-tagging (in Cadence Diva, we made much use of "getTexted()" to declare what a given "island" was supposed to be, and of Cadence pin polygons to assert connectivity. This is not at all what they do. They have hundreds of derived layers (a dozen or so per specific device subtype) that have various logics.

    But my problems are more basic - (1) I "just don't get it", the grammar and syntax and flow; (2) the tutorials I find seem way afield of what I am trying to emulate, modify and accomplish. If there's no "just change the layer and the numbers" example I have no hope of figuring it out on my own and no great optimism about "Ruby tutorials for general purpose UI script programmers" ever getting around to telling me what I need to know, for what I have to do (and as little irrelevance-to-that as possible).

  • edited January 7

    Did I mention this one?

    https://wiki.f-si.org/index.php/Hands-on_with_KLayout:_Design_rule_checks_and_layout_to_netlist_tools

    There is a link to "Video recording" in "Downloads". If you promise not to be too picky about my appearance you can follow this one. In this talk, I'm trying to explain how you write a DRC ...

    BTW: there is going to be another conference this year early June in Zurich, Switzerland.

    Matthias

Sign In or Register to comment.