[phdl-devel] Device Attributes

[Wesley J. L. <wj...@ic...>]

In my message about PHDLIF, I asked about attributes:

On Friday, January 24, 2014 22:42:56 Wesley J. Landaker wrote:
> 4. Speaking of attributes ... what attributes do certain backends expect?

Here are some of my thoughts about attributes for devices that I'd love to 
get feedback on:

1. The structural two parts of devices we capture in PHDLIF are the device 
name and its list of pins. The rest is attributes. Let's look at the 
structure for second:

	* Name -- this is the low-level name of the device. This is not 
intended to be the friendly "user" name the PHDL user might have given their 
part {"FPGA", "ADC"} but instead is the "real" name of the device 
{"XC6LX45-1-CSG324I", "MAX1112EEE+"} that should match the datasheet. (For 
reference, In PHDL 2.x this was the "PARTNUMBER" attribute, but in 3.x it is 
part of the device structure.)

	* Pins -- the pins on the device. Again, this is not the friendly 
"user" pin names the PHDL user might have given {"clock", "data[5]"}, but 
are the "real" names of the pins from the device declaration {"AA17", "12"} 
that should match the datasheet.

In a sane world, this might be all we'd need, since this is how real 
designers refer to parts on their boards {"clock is hooked to pin AA17 of 
the FPGA"}. But pragmatically, we need more than structural information to 
work with most PCB tools.

2. Here are the "standard" device attributes I think we need. (Not worried 
too much about names yet, until we know semantically what are we trying to 
communicate.)

	* Part number -- this here to show that I'm not forgetting this, but 
this is actually just the device name, as described above. This is always 
guaranteed to be present, so there are no edge conditions here.

	* Package / footprint -- usually a designer picks a part atomically, 
package and all, but some PCB tools like to separate the part number and the 
package or footprint type. This is like PHDL 1.x's "PACKAGE" attribute and 
PHDL 2.x "FOOTPRINT" attribute[1]. Since it seems that about 50% of backend 
formats require this information split out, whether or not the *user* wants 
it split out, my thought is that there are two ways to handle this: A. Leave 
the attribute optional (since many tools don't need or want this 
information) and leave the backend to do something quasi-intelligent if its 
not provided (like reuse the part number for the footprint name), or B. make 
package/footprint information part of the first-class structure of PHDL 
devices (thus making it required for the user to always provide). I'm a 
little torn here. Any thoughts?

	* Library / collection -- I'm not sure why -- since part numbers are 
already unique in a global namespace -- but every PCB tool seems to insist 
that all parts be part of a name library or collection. This is like PHDL 
2.x's LIBRARY attribute. This is fine, and kind of nice from an 
organizational point of view *when the user wants it*, but it is a little 
obnoxious that it is *required* by some tools, especially where there is no 
global library/collection hierarchy to follow. My thought here is that if 
this attribute is not provided by the user, and there is no way to indicate 
"no library" in a particular backend, netlisters should default to a default 
(but documented) library name {"default" if there is nothing better, "work" 
for VHDL, and so forth}.

Obviously there are a zillion other attributes that CAN go on devices, that 
might be useful for certain backends. For example, BOM generators need to 
know about values for parameterized parts {resistors}, and can use extra 
info like manufacturer, supplier, price, etc for making reports. We should 
standardize on names for those as well, but first I want to make sure we're 
on the right track for fundamental attributes needed during primary 
netlisting.

Footnotes:
[1] Okay, I said I didn't care about names yet, but seriously, what is the 
standard PCB terminology here? Package, footprint, or something else?! For 
reference, we changed from PACKAGE to FOOTPRINT only because "package" was a 
keyword in PHDL 2.x, not for any other super insightful reason.