Re: [phdl-devel] a few short comments on Wes' comments.

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

On Sunday, January 20, 2013 13:46:37 peter dudley wrote:
> >= Packages and Imports =
> 
> I question whether we want this type of thing at all.  Right now I think
> it is optional.  When I write PHDL code I will probably always use this
> style to fully specify a device where I use it. iinst oscillator of
> dev_pack.CB3LV-3I {EOH=open; OUT=clk100; VCC=+3V3; GND=gnd;}

I'd be okay with this. So basically we'd have packages, but no import 
statements. If you want to use a package, you point the compiler at it, and 
now it's available. If you don't want to include a package, you just don't 
point the compiler at it. Using packages is the same syntax as now, as 
you've shown above.

Is this what you are thinking? The good thing about this is that it's 
simple, but still provides most of the advantages of packages.

>  == Attributes on Everything ==
> Now you are scaring me.  I sounds like you are evolving PHDL toward a
> generalized connection definition tool instead of something tweaked to
> just to do PCB's.  Maybe that would be practical.

Well, don't get too scared yet. =) The idea isn't to make PHDL for anything 
but PCBs, but to keep a very strict and clean separation between front-end 
language specification/grammar and back-end netlisters, etc. Think the split 
between a language and it's standard library. There are good reasons not to 
tangle them up together, even if from the user's perspective, they really 
look like one and the same.

Keep in mind that the only thing we currently can't put attributes on, but 
NEED to be able to in order to successfully allow users to use and develop 
DRC tools is attributes on pins. We already currently support them on 
devices, instances, and nets.

Analogy: you probably think of "printf" as part of the C language -- it 
actually has nothing AT ALL to do with the C language, but is part of the C 
standard library. The attributes we expect our users to use can be 
standardized and they may think of them as part of the language, but they 
are actually an interface to back-ends, and not really part of the base 
language.
 
> == Info Statement ==
> I am ok with removing this feature.  I like the idea of processing the
> design into a report using doxygen. That sounds like something I could
> figure out. :-)

Plus, writing a PHDL interface for doxygen is a lot less work than 
reinventing our own PHDL-specific documentation language.
 
> == inst vs subinst ==
> I can see a small value to the review of retaining "subinst".  It tips
> them off in a very concrete way to look for a subdesign and not for a
> device to check.  Consider this subinst: subinst supply_1V2 of volt_reg
> {vin=+5V; vout=+1V2; gnd=gnd;}
> It could be a three pin LDO or a complete regulator with decoupling, etc.

Okay, I suppose I could see that. I'd suggest that we keep devices and 
subdesigns in the same namespace and emit and error if a user attempts to 
name a device and a subdesign the same thing and just descriminate against 
them with inst and subinst, as that would be a nightmare. 

> I am also glad that we are hammering on the spec now but we should
> forgive ourselves for not knowing all this up front.  I think having a
> pretty darn good working PHDL compiler all this time has made it
> possible to know what we want, which is very close to what we have.  I
> still believe, more than ever, that typing in board designs is much
> smarter than clickety-clicking on a silly drafting tool.

Absolutely. Everyone involved has been doing a superb job, and I think we're 
very close to a really good language revision!