Parameterizing Parts Request (from phdl-support)

Date: 8/10/2012
E-mail from user
Name: Roderick Mann
Subject: Parameterizing parts
Email: rmann@...
Message Content:

One of the things I've run into frequently is the tedium of creating part definitions for what is essentially the same part, except it varies in parameters like value or voltage, or in the case of connectors, by number of pins. It would be really cool to be able to parameterize these attributes, in order to create implicit part defs from a template. Perhaps you already support it; I'm still teaching myself PHDL.

But, let's say I have several single-row headers in my design. I hate to create a device for each one, just because it changes pin count. I wish I could just say something like:

device SingleRowHeader(inNumPins)
{
attr PINCOUNT = inNumPins;

//magic here for defining pins, maybe a loop-like syntax 

}

inst header1 of SingleRowHeader(5)
{
}

alternatively

inst header1 of SingleRowHeader
{
inNumPins = 5; // I wouldn't call it "inNumPins" in this case; that's a convention I use for parameter names
}

A second parameter in this instance could specify the number of rows, a third male or female, etc.

One related feature that stands independently: part numbers (and other attributes) derived from attributes. For example, for many values of chip resistor, the part number is the same, except for a few digits. Allowing me to specify at least a GREP-like string format for the part number, or even a whole script (pick your scripting poison, allow me to embed it in the PHDL file). But I'd like to be able to go from a nice attr VALUE string like "0.1µF" to "C0603C104K4RACTU". Note that this requires several things, but focusing on the value alone, you have to go from "0.1 µF" to "104", which is 1 x 10^4 x 10pF, I think. So, the scripting language needs to be able to express some arithmetic.

Getting more sophisticated, it would be nice for the tool to automatically pick the part and package based on a few things specified. Let's say I call for Kemet caps, 1608 (that's metric, EIA 0603), 0.1µF,10V. It may be that there's no 1608 package for that combination of values. It would be cool if it could find the next-largest package. I realize the difficulty of encoding so many parts from a given manufacturer, so maybe this feature requires too much infrastructure (it can either be encoded with ranges of values, or looked up from an online database).

Just some ideas...