|
From: Wesley J. L. <wj...@ic...> - 2013-01-20 23:55:40
|
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!
|