phdl-devel — PHDL General Development Discussion

Re: [phdl-devel] Abstract PHDL Intermediate Format Content

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

On Sunday, January 26, 2014 08:54:27 Peter Dudley wrote:
> I think is safe to assume that board layout formats will always be able to
> use fully flattened structure.
> 
> In Mentor PADS, busses get broken out into individual signals in the
> layout netlist.  Paths just get embedded in the names as you describe.

This is my impression as well, but I wanted to throw my assumptions out 
there and see if they sound reasonable. =) 

Anyway, I think PHDLIF will work best as a completely flattened model. This 
makes writing all backends I can imagine much simpler, because it means that 
we don't force every backend to do its own work flattening things out (and 
possibly botching the job in the process!).

Other kinds of tools that definitely need hierarchy support, such as a 
hypothetical graphical design browser for PHDL, I'm not considering 
"backends". Such a tool wouldn't use PHDLIF at all, but instead would use a 
(TBD) PHDL API to get at the full hierarchical PHDL information model.

[phdl-devel] PHDLIF suggestion for connection

[Peter D. <hd...@ho...>]

Wes,

That looks very good.  

In order to understand the issues, I did some experimentation with using JSON as the data format for PHDLIF.  I wrote a python program that would read the JSON generic netlist format and write Mentor PADS and KiCad specific netlists.

In that work I discovered something funny at the lowest level. PADS describes connections as refdes.pin_number, ie., "U1.17", "C6.1".

KiCad on the other hand requires two different entries for each connection, ie, connection = (refdes, pin_number).  For this reason, I recommend that a connection be defined something like 

Connection ::= SEQUENCE {
	Refdes,
	Pin_number
}

It is not difficult to parse "U1.17" into "U1" and "17" but since you are defining the format now it would be more convenient to make them separate values.

    Pete

-----Original Message-----
From: Wesley J. Landaker [mailto:wj...@ic...] 
Sent: Saturday, January 25, 2014 12:43 PM
To: phd...@li...
Cc: Peter Dudley
Subject: Re: [phdl-devel] Abstract PHDL Intermediate Format Content

On Friday, January 24, 2014 22:42:56 Wesley J. Landaker wrote:
> Currently, as I currently have it drafted, PHDLIF contains the 
> following (written informally as a abstract grammar, hopefully the 
> meaning is clear).
> 
> PHDLIF = Design
> Design = Name Instance* Net* Attribute* Device = Name Pin* Attribute* 
> Instance = Name Device Attribute* Net = Name Connection* Attribute* 
> Pin = Name Attribute* Connection = Instance Pin Attribute Attribute = 
> Name Value Name = <a string> Value = <a string>

Here is a bit more readable and more specific version of the above in ASN.1 (I've also extended the attribute value type since it was easy to do and might be useful):

PHDL-Intermediate-Format DEFINITIONS AUTOMATIC TAGS ::= BEGIN

	Design ::= SEQUENCE {
		name        Name,
		attributes  Attributes,
		devices     Devices,
		instances   Instances,
		nets        Nets
	}

	Attributes ::= SEQUENCE OF Attribute

	Attribute ::= SEQUENCE {
		name   Name,
		value  Value
	}

	Name ::= UTF8String

	Value ::= CHOICE {
		null    NULL,
		bool    BOOLEAN,
		number  INTEGER,
		string  UTF8String,
		bytes   OCTET STRING
	}

	Devices ::= SEQUENCE OF Device

	Device ::= SEQUENCE {
		name        Name,
		attributes  Attributes,
		pins        Pins
	}

	Pins ::= SEQUENCE OF Pin

	Pin ::= Name

	Instances ::= SEQUENCE OF Instance

	Instance ::= SEQUENCE {
		name        Name,
		attributes  Attributes,
		device      Name
	}

	Nets ::= SEQUENCE OF Net

	Net ::= SEQUENCE {
		name         Name,
		attributes   Attributes,
		connections  Connections
	}

	Connections ::= SEQUENCE OF Connection

	Connection ::= SEQUENCE {
		name         Name,
		attributes   Attributes,
		instance     Name,
		pin          Name
	}

END

Re: [phdl-devel] Abstract PHDL Intermediate Format Content

[Peter D. <hd...@ho...>]

Wes,

I think is safe to assume that board layout formats will always be able to use fully flattened structure.

In Mentor PADS, busses get broken out into individual signals in the layout netlist.  Paths just get embedded in the names as you describe.

    Pete


-----Original Message-----
From: Wesley J. Landaker [mailto:wj...@ic...] 
Sent: Saturday, January 25, 2014 1:18 PM
To: phd...@li...
Cc: Peter Dudley
Subject: Re: [phdl-devel] Abstract PHDL Intermediate Format Content

On Friday, January 24, 2014 22:42:56 Wesley J. Landaker wrote:
> 2. Specifically, are there are target netlist formats or PCB tools 
> that read in a hierarchical rather than a flattened design? (I'm not 
> talking about the pseudo-hierarchy you get in PADS just from 
> names/getting/pathified/like/this, but real hierarchy in the netlist 
> structure itself.)

Along with this, another question is do any netlist formats directly support structure in the nets or device pins themselves {arrays, buses, vectors}? 
I'm not talking about if their GUIs *show* or *reconstruct* net or pin structure by looking at names -- but real structural support in the netlist format. From what I've seen of our current netlist formats, I am assuming right now that nothing supports or uses this information, and that some bus[7:0] in PHDL will be always flattened into individual bus[0], ... bus[7] nets at the PHDLIF level.

Re: [phdl-devel] Abstract PHDL Intermediate Format Content

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

On Friday, January 24, 2014 22:42:56 Wesley J. Landaker wrote:
> 2. Specifically, are there are target netlist formats or PCB tools that
> read in a hierarchical rather than a flattened design? (I'm not talking
> about the pseudo-hierarchy you get in PADS just from
> names/getting/pathified/like/this, but real hierarchy in the netlist
> structure itself.)

Along with this, another question is do any netlist formats directly support 
structure in the nets or device pins themselves {arrays, buses, vectors}? 
I'm not talking about if their GUIs *show* or *reconstruct* net or pin 
structure by looking at names -- but real structural support in the netlist 
format. From what I've seen of our current netlist formats, I am assuming 
right now that nothing supports or uses this information, and that some 
bus[7:0] in PHDL will be always flattened into individual bus[0], ... bus[7] 
nets at the PHDLIF level.

Re: [phdl-devel] Abstract PHDL Intermediate Format Content

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

On Friday, January 24, 2014 22:42:56 Wesley J. Landaker wrote:
> Currently, as I currently have it drafted, PHDLIF contains the following
> (written informally as a abstract grammar, hopefully the meaning is
> clear).
> 
> PHDLIF = Design
> Design = Name Instance* Net* Attribute*
> Device = Name Pin* Attribute*
> Instance = Name Device Attribute*
> Net = Name Connection* Attribute*
> Pin = Name Attribute*
> Connection = Instance Pin Attribute
> Attribute = Name Value
> Name = <a string>
> Value = <a string>

Here is a bit more readable and more specific version of the above in ASN.1 
(I've also extended the attribute value type since it was easy to do and 
might be useful):

PHDL-Intermediate-Format DEFINITIONS AUTOMATIC TAGS ::= BEGIN

	Design ::= SEQUENCE {
		name        Name,
		attributes  Attributes,
		devices     Devices,
		instances   Instances,
		nets        Nets
	}

	Attributes ::= SEQUENCE OF Attribute

	Attribute ::= SEQUENCE {
		name   Name,
		value  Value
	}

	Name ::= UTF8String

	Value ::= CHOICE {
		null    NULL,
		bool    BOOLEAN,
		number  INTEGER,
		string  UTF8String,
		bytes   OCTET STRING
	}

	Devices ::= SEQUENCE OF Device

	Device ::= SEQUENCE {
		name        Name,
		attributes  Attributes,
		pins        Pins
	}

	Pins ::= SEQUENCE OF Pin

	Pin ::= Name

	Instances ::= SEQUENCE OF Instance

	Instance ::= SEQUENCE {
		name        Name,
		attributes  Attributes,
		device      Name
	}

	Nets ::= SEQUENCE OF Net

	Net ::= SEQUENCE {
		name         Name,
		attributes   Attributes,
		connections  Connections
	}

	Connections ::= SEQUENCE OF Connection

	Connection ::= SEQUENCE {
		name         Name,
		attributes   Attributes,
		instance     Name,
		pin          Name
	}

END

[phdl-devel] Abstract PHDL Intermediate Format Content

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

Happy 2014 everyone!

As far as my experience goes, PHDL 2 is very usable, but could certainly 
benefit from some dedicated maintaince from an interested party. It 
certainly has been a success in that we've made a few boards with it at my 
workplace with very good results.

Where I am personally interested is in moving forward PHDL 3 (vaporware at 
the moment), which for me fits into my personal research on next-generation 
hardware description language tooling. My technical interest in more in the 
compiler technology than in actually making PCBs. (After all, the former I 
do as hobby -- the latter I only do at work!) For my own sanity, I have 
resolved not to give any concrete estimates for "when will it be ready?". 
(BTW, the standard open-source project answer is: "sooner, if you help!").

Things have been mostly quiet on the mailing list for quite a while, but 
I've had a couple private queries about the state of PHDL development in the 
last few weeks, which has prompted me to think about why I've been stalled 
on PHDL lately. One thing about the backend that not totally comfortable 
with, is:

* Exactly what information should the PHDL Intermediate Format contain?

Since its has been a long while (about a year) since we've discussed this, 
the PHDLIF concept is as follows. Currently, PHDL 2.x does not support 
PHDLIF, but supports backends directly in code via simple polymorphism. This 
is not a nice situation, because to make or modify a backend, you have to 
rebuild the compiler, and the backends and compiler are tied to single 
language, and worse, a single implementation. The new concept is that the 
next PHDL compiler will not generate any files directly for any particular 
target. Instead, it will generate an intermediate format (PHDLIF) which then 
will be read by backends. This approach adds a step in compilation, but has 
all the usual benefits of abstraction and separation of concerns.

Anyway, let's talk about what information PHDLIF should contain. In this 
discussion, I'm not interested in talking about the concrete format (e.g. is 
it XML, JSON, etc) -- we'll of course make it human-readable and easy to use 
programmatically, but that is an unimportant implementation detail at the 
moment. Instead, I want to focus on what information should be present in 
order to support a reasonable set of backends.

My thoughts are we've got basically the following requirements:

1. PHDLIF should directly represent the flattened design structure, as most 
backends are going to be netlist formats, or analysis tools that operate 
most easily on a flattened structure.

2. PHDLIF should a way for the PHDL front-end and netlister backends to 
communicate important non-structural information, such as globa, instance, 
and/or net properties.

3. PHDLIF should have a simple information model that is easy to process in 
a backend implementation.

Currently, as I currently have it drafted, PHDLIF contains the following 
(written informally as a abstract grammar, hopefully the meaning is clear).

PHDLIF = Design
Design = Name Instance* Net* Attribute*
Device = Name Pin* Attribute*
Instance = Name Device Attribute*
Net = Name Connection* Attribute*
Pin = Name Attribute*
Connection = Instance Pin Attribute 
Attribute = Name Value
Name = <a string>
Value = <a string>

In prose, basically this is saying that a PHDLIF file contains a Design, 
which has a Name, and some Devices, Instances, and Nets. The Devices each 
have a Name and some Pins. The Instances each have a Name and are an 
instance of a Device. The Nets each have a Name and some Connections to 
Instance's Pins. Everything can have Attributes, which are Name/Value pairs, 
attached. So, a glorified netlist with metadata.

I believe everything non-structural we've hard-coded into PHDL 2.x -- like 
footprint, library, refdes, etc -- can actually be expressed just as easily, 
and with more flexibility and extensibility, with Attributes. The intent is 
to standardize on some set of core Attributes (footprint, refdes, etc, etc) 
so that backends know what they have to work with, but not to bake that into 
the *structure* of PHDLIF.

Here's what I'd love to hear from anyone knowledgeable:

1. What is the information model of some target netlist formats? For 
example, PHDL 2.x targets PADS and Eagle, but I could still use more 
information on those formats, since I'm not confident we know how they work 
other than just by mimicing examples from other tools. We also want to 
target open-source tools like gEDA (PCB, maybe even gschem), KiCAD, and 
possibly other commercial tools that people are interested in. While we 
don't have to write code to target everything under the sun all at once, I 
do want to make sure our PHDLIF information model fits with at least the 
backends we do know about!

2. Specifically, are there are target netlist formats or PCB tools that read 
in a hierarchical rather than a flattened design? (I'm not talking about the 
pseudo-hierarchy you get in PADS just from 
names/getting/pathified/like/this, but real hierarchy in the netlist 
structure itself.)

3. Is there any other structural information you believe that ought to be in 
PHDLIF that wouldn't be sufficient as an attribute? Or are there any other 
places in the structure that you think ought to be attributeable?

4. Speaking of attributes ... what attributes do certain backends expect? 
Although its not critical to the definition of the abstract PHDLIF 
information model, it is important to know what standard attributes we ought 
to start with. We've already got some of these in PHDL 2.x. For example, for 
devices, we've got footprint (what is the device's footprint/package type -- 
but do all backends split device type and device footprint into two 
pieces?), and for instances we've got refdes (reference designator -- which 
is really just a short alias for it's name; do different backends have 
different rules about these?). The key is to try to extract commonality. 
Individual backends may still by their nature require specific attributes (a 
io-compatibility DRC checker might need net annotations, a BOM generator 
might need device prices, etc) -- that's no problem.

Thanks in advance for any feedback!

- Wes

Re: [phdl-devel] KiCad TimeStamp value in layout files?

[Brian C. <cla...@no...>]

Pete

That should work. The only problem I can see is that if you use the name 
of the component as the TimeStamp then when the user renames anything 
you will lose the mapping between modules in the schematic and PCB. 
However, in that case the user can have PCBNEW use the References to do 
the matching, assuming those haven't changed also. In the end, for 
simplicity, I recommend using some hash key that is not tied to how the 
user names objects in his design.

Kind regards,
Brian

On 4/18/2013 10:38 PM, Peter Dudley wrote:
>
> Brian,
>
> That's very helpful.
>
> Our PHDL language supports hierarchical design so I think I will try 
> making the TimeStamp equal to fully resolved name of the component. 
> Maybe something like this
>
> TimeStamp = /ddr_block/term_network/termres1
>
> Maybe it will be necessary to replace the "/" symbols with "_" or 
> something but it will still be unique.  Failing that, I will generate 
> a unique hash value for that field.
>
> The other thing that you mention about the Reference Designators 
> (refdes), normally: R1, C17, U5, ..., we also wanted to make those old 
> fashioned refdes more useful.  Our idea is to put just a little 
> hierarchical info into the refdes.  We allow an optional "RefPrefix" 
> string to be supplied by the designer when he instantiates a 
> hierarchical block.  That RefPrefix gets prepended to the refdes of 
> the components inside that block when the netlist is generated.  If 
> there is a subdesign for the FPGA for example, the designer could make 
> RefPrefix = "X" and all the refdes for the FPGA page would begin with 
> X, ie.,  XR1, XC17, XU5, ...
>
> I want to answer your other email about design checking separately.  
> I'm also copying our phdl-devel mailing list on this email.  I hope 
> that's ok.
>
> Pete
>
> *From:*Brian Clarkson [mailto:cla...@no...]
> *Sent:* Thursday, April 18, 2013 2:19 PM
> *To:* Peter Dudley
> *Subject:* Re: KiCad TimeStamp value in layout files?
>
> The TimeStamp is really just a unique ID generated for the component 
> at the moment it is inserted into the schematic. Timestamp a bit of a 
> misnomer. It is semantically separate from the Reference because the 
> user might rearrange the References but the TimeStamp (aka unique ID) 
> always stays the same.
>
> So in my scripts, I do exactly the same. When a Component is inserted 
> into the Schematic object, a unique hash key is generated that stays 
> with the Component. This hash key is what I put into the TimeStamp 
> field of the CMP file and as the module ID in the NET file. References 
> are generated separately according to whatever algorithm the user 
> wants. For example, my favorite is to generate references of the form 
> C6.2 where C is the component prefix (capacitor in this case), 6 is 
> the section number, and 2 means this is the 2nd capacitor in its section.
>
> I've attached an example of NET and CMP files that I've generated from 
> Python and use successfully to fabricate a board in PCBNEW recently. I 
> hope that helps.
>
> On 4/18/2013 8:24 PM, Peter Dudley wrote:
>
>     Brian
>
>     I have a question about TimeStamp values in the Kicad .cmp and
>     .net formats.
>
>     I have started to write a new backend netlister for our PHDL
>     language.  I'm using JSON as the intermediate netlist format and
>     python as the programming language to process that JSON file into
>     valid layout netlists. I have written and tested the json-to-PADS
>     converter and now I am starting to look at generating the Kicad
>     .cmp and .net files.
>
>     Can you tell me the purpose of the TimeStamp statement  in the
>     .cmp file?  Is the TimeStamp the unique identifier for the
>     component type in the kicad system? I can see how using a time
>     stamp this way could make sense for a schematic component but in a
>     text based flow we don't really have the equivalent of the
>     creation time or anything like that.  Can we just use a textual
>     component name in place of the 32 bit hex string?  Here is an
>     snippet from a .cmp I generated from the kicad schematic editor.
>
>     BeginCmp
>
>     TimeStamp = /5139F8CC;
>
>     Reference = U1;
>
>     ValeurCmp = PIC12C508A;
>
>     IdModule = DIP-8__300;
>
>     EndCmp
>
>     Here is the component declaration in the .net file.
>
>     (comp (ref U1)
>
>     (value PIC12C508A)
>
>     (libsource (lib microcontrollers) (part PIC12C508A))
>
>     (sheetpath (names /) (tstamps /))
>
>     (tstamp 5139F8CC)))
>
>     I think you must have faced this issue yourself. Can you tell me
>     what you do with the TimeStamp value?
>
>     Any advice is greatly appreciated.
>
>     Pete
>
>     *From:*Brian Clarkson [mailto:cla...@no...]
>     *Sent:* Friday, March 08, 2013 2:59 PM
>     *To:* kic...@ya... <mailto:kic...@ya...>
>     *Cc:* padudle
>     *Subject:* Re: [kicad-users] PHDL to KiCAD conversion path?
>
>     Hi Pete
>
>     This is exciting stuff. I really agree with the idea that
>     graphical schematic capture is terribly inefficient and I applaud
>     your efforts with PHDL.  I do all of my schematic capture with
>     Python and all of my component libraries are just Python modules.
>     Once you get use to it, the time-savings and the ability to re-use
>     subcircuits, build circuits procedurally, rename components
>     exactly the way you want, etc. you just can't go back.
>
>     Anyway, I found that in order to generate what PCBNEW needs I just
>     have to produce a .NET file to describe the netlist and .CMP file
>     to associate the footprints. I just use existing .MOD files or
>     create new ones in PCBNEW's module editor. This part I haven't
>     seen a compelling reason to replace with a text-based tool. Yet.
>
>     There is no official documentation for the .NET or .CMP files but
>     they are extremely easy to pick apart by just looking at a few
>     examples.
>
>     Good luck.
>
>     Kind regards,
>     Brian
>
>     On 3/8/2013 8:43 PM, padudle wrote:
>
>         Hello All,
>
>         I am currently part of a small group of people developing a
>         new Hardware Description Language (HDL) specifically for
>         Printed Circuit Board (PCB) development. We call our language
>         PHDL. It is a open-source project and you can find some
>         information about it here if you are interested,
>         http://sourceforge.net/p/phdl/wiki/Home/.
>         <http://sourceforge.net/p/phdl/wiki/Home/> We have written
>         version 1 and version 2 of the PHDL compiler and quite a few
>         utilities to support it.
>
>         PHDL replaces schematic entry in the the PCB design flow. As
>         such, our compiler must write out netlist files in the correct
>         format for each layout tool we want to support. So far, PHDL
>         2.1 can write netlist files for Mentor PADS and CadSoft Eagle
>         PCB. We are currently doing a rewrite of the PHDL compiler to
>         improve maintainability and extensibility and we would very
>         much like to write netlist files that are compatible with at
>         least one open source layout tool. KiCad looks like a good
>         candidate.
>
>         I am seeking advice here. Can anyone offer an opinion as to
>         the best file format to write in order to get our netlist into
>         the KiCad pcbnew layout tool?
>
>         Looking at the KiCad work flow diagram, I see a netlist and a
>         .mod file going into CVpcb. Is the netlist format stable and
>         open? Is that what we should target?
>
>         Anyway, all advice is greatly appreciated.
>
>         Regards,
>
>         Pete Dudley
>
>         __._,_.___
>
>         *Reply via web post
>         <http://groups.yahoo.com/group/kicad-users/post;_ylc=X3oDMTJycG5mZGdoBF9TAzk3MzU5NzE0BGdycElkAzE2MDI3Njk4BGdycHNwSWQDMTcwNzI4MTk0MgRtc2dJZAMxNDY5NwRzZWMDZnRyBHNsawNycGx5BHN0aW1lAzEzNjI3NDUwMDg-?act=reply&messageNum=14697>
>         *
>
>         	
>
>         Reply to sender
>         <mailto:hd...@ho...?subject=Re%3A%20PHDL%20to%20KiCAD%20conversion%20path%3F>
>
>         	
>
>         Reply to group
>         <mailto:kic...@ya...?subject=Re%3A%20PHDL%20to%20KiCAD%20conversion%20path%3F>
>
>         	
>
>         Start a New Topic
>         <http://groups.yahoo.com/group/kicad-users/post;_ylc=X3oDMTJmODQwZ2JtBF9TAzk3MzU5NzE0BGdycElkAzE2MDI3Njk4BGdycHNwSWQDMTcwNzI4MTk0MgRzZWMDZnRyBHNsawNudHBjBHN0aW1lAzEzNjI3NDUwMDg->
>
>
>         	
>
>         Messages in this topic
>         <http://groups.yahoo.com/group/kicad-users/message/14697;_ylc=X3oDMTM3amprN3RuBF9TAzk3MzU5NzE0BGdycElkAzE2MDI3Njk4BGdycHNwSWQDMTcwNzI4MTk0MgRtc2dJZAMxNDY5NwRzZWMDZnRyBHNsawN2dHBjBHN0aW1lAzEzNjI3NDUwMDgEdHBjSWQDMTQ2OTc->
>         (1)
>
>         *Recent Activity:*
>
>         ·*New Members
>         <http://groups.yahoo.com/group/kicad-users/members;_ylc=X3oDMTJnNTZqbzltBF9TAzk3MzU5NzE0BGdycElkAzE2MDI3Njk4BGdycHNwSWQDMTcwNzI4MTk0MgRzZWMDdnRsBHNsawN2bWJycwRzdGltZQMxMzYyNzQ1MDA4?o=6>****16***
>
>         ·*New Photos
>         <http://groups.yahoo.com/group/kicad-users/spnew;_ylc=X3oDMTJnNGxraXIxBF9TAzk3MzU5NzE0BGdycElkAzE2MDI3Njk4BGdycHNwSWQDMTcwNzI4MTk0MgRzZWMDdnRsBHNsawN2cGhvdARzdGltZQMxMzYyNzQ1MDA4>****3***
>
>         ·*New Files
>         <http://groups.yahoo.com/group/kicad-users/files;_ylc=X3oDMTJoZ3JzMWFvBF9TAzk3MzU5NzE0BGdycElkAzE2MDI3Njk4BGdycHNwSWQDMTcwNzI4MTk0MgRzZWMDdnRsBHNsawN2ZmlsZXMEc3RpbWUDMTM2Mjc0NTAwOA-->****1***
>
>         Visit Your Group
>         <http://groups.yahoo.com/group/kicad-users;_ylc=X3oDMTJmcmF1c2oxBF9TAzk3MzU5NzE0BGdycElkAzE2MDI3Njk4BGdycHNwSWQDMTcwNzI4MTk0MgRzZWMDdnRsBHNsawN2Z2hwBHN0aW1lAzEzNjI3NDUwMDg->
>
>
>         Please read the Kicad FAQ in the group files section before
>         posting your question.
>         Please post your bug reports here. They will be picked up by
>         the creator of Kicad.
>         Please visit http://www.kicadlib.org for details of how to
>         contribute your symbols/modules to the kicad library.
>         For building Kicad from source and other development questions
>         visit the kicad-devel group at
>         http://groups.yahoo.com/group/kicad-devel
>
>         Yahoo! Groups
>         <http://groups.yahoo.com/;_ylc=X3oDMTJldnRjN2Y4BF9TAzk3MzU5NzE0BGdycElkAzE2MDI3Njk4BGdycHNwSWQDMTcwNzI4MTk0MgRzZWMDZnRyBHNsawNnZnAEc3RpbWUDMTM2Mjc0NTAwOA-->
>
>         Switch to: Text-Only
>         <mailto:kic...@ya...?subject=Change%20Delivery%20Format:%20Traditional>,
>         Daily Digest
>         <mailto:kic...@ya...?subject=Email%20Delivery:%20Digest>
>         . Unsubscribe
>         <mailto:kic...@ya...?subject=Unsubscribe>
>         . Terms of Use <http://docs.yahoo.com/info/terms/> . Send us
>         Feedback
>         <mailto:ygr...@ya...?subject=Feedback%20on%20the%20redesigned%20individual%20mail%20v1>
>
>         .
>
>         __,_._,___
>

Re: [phdl-devel] Welcome aboard.

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

Hey Mike & Pete,

On Thursday, March 14, 2013 13:19:44 Mike Crowe wrote:
> A concept that I like to think of about a schematic is that it is
> projected in many different directions, like light being reflected from
> a diamond.  Sometimes it is projected into a new PCB layout, sometimes
> into a BOM, sometimes into a spice simulation, sometimes into a power
> point presentation,...  well you get the idea.    Humans work in terms
> of 'HDL tools,  computers on the other hand need more precision.  In my
> current design development, I project my schematic into an XML document
> and then through an XSLT into the desired product.  What I'd like to see
> is a way to convert PHDL into XML, and then be able to back annotate
> PHDL from the XML, that is reciprocity between PHDL and an XML.  The XML
> would need to contain the same hierarchy as the PHDL.

On Friday, March 15, 2013 04:27:53 Peter Dudley wrote:
> It is our goal to define an intermediate format that is super easy to
> parse. We call it PHDLIF.  Then anyone could write utilities that
> convert that intermediate format file into whatever they need.  For
> PHDLIF we are considering JSON, XML or just a super simple plain text
> format.  We want people to be able to retarget their PHDL source to any
> board layout, documentation or other tool.  I had not considered it
> before but you could easily go the other way, back to PHDL, since it is
> such a simple language. We will certainly write netlisters to go from
> PHDLIF to PADS, Eagle and at least one open-source layout tool.

As you may have seen from my previous e-mails on this list, I'm in the 
middle of reworking PHDL into a C++ version with many upgrades a much more 
thorough specification, and a lot more room for modularity and 
extensibility. Having PHDL easily work with other tools -- both in the input 
and output direction -- is one of my most important goals.

I think you will really like the changes that are upcoming in PHDL. Although 
the core format of PHDLIF isn't finalized, it definitely will be round-
trippable. It will differ a bit from the first document I wrote up to get us 
started is in Git.

The very first PHDLIF translator I'm planning to create is a PHDL writer, so 
you can do a PHDL -> PHDLIF -> PHDL round-trip. I also want it to be easy to 
handle any format bidirectional. For example, I am planning to use a PADS 
netlist -> PHDL conversion step to help free boards from legacy tools and 
get them into PHDL.

Right now I am working very hard to get a stable core PHDL C++ codebase 
created that will be easy to collaborate and improve upon, but its not 
really ready to share yet (although, I do push every once in a while to a 
branch -- nothing is hidden on purpose, but there are lots and lots of notes 
in my design notebook and in my head that are not yet implemented!) I am 
really exited about this and have put a lot of other projects on hold to 
give me more time to focus on this work -- but I'm still just doing this in 
my spare time, so please be patient. =) Realistically, I expect to have the 
base compiler and a full language specification written up this year.

But please nobody, need hobble themselves waiting for me to complete this 
upgrade. PHDL 2.0 and 2.1, although they are a little different from each 
other, and each have some warts, are both very usable right now. Several 
folks have made real boards using both of those two versions!

Work on understanding backends and file formats and creating libraries or 
translators that target them is all stuff that is important but I am 
personally ignoring right now. That's a *great* place for anyone interested 
to jump in now, as anything that gets created that works with PHDL 2.x will 
be pretty easily port to PHDLIF / PHDL 3.0 once it gets rolling.

[phdl-devel] Welcome aboard.

[Peter D. <hd...@ho...>]

Mike,

Welcome aboard.  Thank you for understanding what we are trying to do.  You
might be surprised by the number of people who are offended by even the idea
of using something other than a schematic editor to define circuit
connectivity.

We are writing this tool for people like you and me.  I got my MSEE in 1984
so I'm a couple years older.  I have worked 28 years for a similar company
doing electronics design.  I feel like I could go another 28 years.

We also admire K&R. In the design of the language we are keeping with the
philosophy of "less is more" or the simpler the better.  For a board design
you really only need to instantiate components and wire them up. A few
"attributes" are needed to decorate the design for board layout, bill of
materials, etc. PHDL has nice support for hierarchy so you can break up your
design for re-use or just to make it more readable. I like my top level
design to have just major sub-design instantiations.

It is our goal to define an intermediate format that is super easy to parse.
We call it PHDLIF.  Then anyone could write utilities that convert that
intermediate format file into whatever they need.  For PHDLIF we are
considering JSON, XML or just a super simple plain text format.  We want
people to be able to retarget their PHDL source to any board layout,
documentation or other tool.  I had not considered it before but you could
easily go the other way, back to PHDL, since it is such a simple language.
We will certainly write netlisters to go from PHDLIF to PADS, Eagle and at
least one open-source layout tool.

Right now, we are rewriting the compiler from scratch in C++ for
maintainability, packagability, extensibility and all the other ilities.  

Please stay tuned. When we have the new compiler working I'm sure there will
be an announcement.  That would be a good time to develop some XML tools
like you propose.

Best wishes,

    Pete Dudley

-----Original Message-----
From: Mike Crowe [mailto:mc...@gc...] 
Sent: Thursday, March 14, 2013 8:20 PM
To: phd...@li...
Subject: [phdl-devel] Greeting and salutations

Hello
I am new to the list.  Since this appears to be a small group, I'd like to
introduce myself, ramble a bit, then ask a question.

Background
Age: 50
Education: MSEE, 1987
20 years as a defense contractor as a design engineer (Qinetiq), primarily
in underwater acoustic data acquisition systems.  Last five years at
http://www.gcdataconcepts.com designing data acquisition systems.

Some development groups that I subscribe to geda-user, ghdl-discuss,
ngspice-devel, sdcc-devel, openocd-devel.

yada yada yada.... enough said.

<ramble>
I'm really interested in text based schematic entry and associated tools.
I've noted in recent years that graphical schematic have become nothing more
than a box with pins on it and lines with net-names stuck onto the pins.
Not exactly pretty.  Certainly not clear.  I've toyed with the idea of
creating a text based schematic language, but it's never really gotten past
being a fantasy, ... until now!  PHDL are you my dream child?  Well,
maybe,...  I like many of the things I see in PHDL, but if it could only
.... :-)

One of the things that I think of when I think of a 'HDL is a text based way
for a human to create something.  The syntax must be terse, but not too
terse.  Consistent with as few rules as possible.  Powerful, but stay within
scope.  In other words, logical, clean, and clear.  For myself I take as the
benchmark for a logical, clean and clear language, "The C programming
language" by Kernighan and Ritchie.  I feel that your project has many
elements that are embodied by the K&R work.  The PHDL_3-0-0_language_spec is
clean and concise.  I am reading it now.
More on that in the future.

A concept that I like to think of about a schematic is that it is projected
in many different directions, like light being reflected from a diamond.
Sometimes it is projected into a new PCB layout, sometimes into a BOM,
sometimes into a spice simulation, sometimes into a power
point presentation,...  well you get the idea.    Humans work in terms
of 'HDL tools,  computers on the other hand need more precision.  In my
current design development, I project my schematic into an XML document and
then through an XSLT into the desired product.  What I'd like to see is a
way to convert PHDL into XML, and then be able to back annotate PHDL from
the XML, that is reciprocity between PHDL and an XML.  The XML would need to
contain the same hierarchy as the PHDL.  

I've done some work with xslt transformation, it's wordy, but otherwise
consistent and logical.  I've done some work work with xslt 2.0 in
transforming plain-text documents into xml, but seem to have problems
capturing the hierarchy into the XML.  

Back annotation into PHDL is important because XML doesn't do a very good
job with whitespace (it's mostly ignored), and just as there is more than
one way to skin a cat,  there is more than one way to express a design
thought.
</ramble>

So finally the question
Is there a tool being developed that would provide this reciprocal
relationship between PHDL and an XML equivalent version?  If not, I'd be
interested doing some development in that direction.

Thanks
Mike



----------------------------------------------------------------------------
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics Download AppDynamics Lite for
free today:
http://p.sf.net/sfu/appdyn_d2d_mar
_______________________________________________
phdl-devel mailing list
phd...@li...
https://lists.sourceforge.net/lists/listinfo/phdl-devel

[phdl-devel] Greeting and salutations

[Mike C. <mc...@gc...>]

Hello
I am new to the list.  Since this appears to be a small group, I'd like
to introduce myself, ramble a bit, then ask a question.

Background
Age: 50 
Education: MSEE, 1987
20 years as a defense contractor as a design engineer (Qinetiq),
primarily in underwater acoustic data acquisition systems.  Last five
years at http://www.gcdataconcepts.com designing data acquisition
systems.

Some development groups that I subscribe to
geda-user, ghdl-discuss, ngspice-devel, sdcc-devel, openocd-devel.

yada yada yada.... enough said.

<ramble>
I'm really interested in text based schematic entry and associated
tools.  I've noted in recent years that graphical schematic have become
nothing more than a box with pins on it and lines with net-names stuck
onto the pins.  Not exactly pretty.  Certainly not clear.  I've toyed
with the idea of creating a text based schematic language, but it's
never really gotten past being a fantasy, ... until now!  PHDL are you
my dream child?  Well, maybe,...  I like many of the things I see in
PHDL, but if it could only .... :-)

One of the things that I think of when I think of a 'HDL is a text based
way for a human to create something.  The syntax must be terse, but not
too terse.  Consistent with as few rules as possible.  Powerful, but
stay within scope.  In other words, logical, clean, and clear.  For
myself I take as the benchmark for a logical, clean and clear language,
"The C programming language" by Kernighan and Ritchie.  I feel that your
project has many elements that are embodied by the K&R work.  The
PHDL_3-0-0_language_spec is clean and concise.  I am reading it now.
More on that in the future.

A concept that I like to think of about a schematic is that it is
projected in many different directions, like light being reflected from
a diamond.  Sometimes it is projected into a new PCB layout, sometimes
into a BOM, sometimes into a spice simulation, sometimes into a power
point presentation,...  well you get the idea.    Humans work in terms
of 'HDL tools,  computers on the other hand need more precision.  In my
current design development, I project my schematic into an XML document
and then through an XSLT into the desired product.  What I'd like to see
is a way to convert PHDL into XML, and then be able to back annotate
PHDL from the XML, that is reciprocity between PHDL and an XML.  The XML
would need to contain the same hierarchy as the PHDL.  

I've done some work with xslt transformation, it's wordy, but otherwise
consistent and logical.  I've done some work work with xslt 2.0 in
transforming plain-text documents into xml, but seem to have problems
capturing the hierarchy into the XML.  

Back annotation into PHDL is important because XML doesn't do a very
good job with whitespace (it's mostly ignored), and just as there is
more than one way to skin a cat,  there is more than one way to express
a design thought.
</ramble>

So finally the question 
Is there a tool being developed that would provide this reciprocal
relationship between PHDL and an XML equivalent version?  If not, I'd be
interested doing some development in that direction.

Thanks
Mike

Re: [phdl-devel] Major PHDL C++ rewrite coming in 2013

[Peter D. <hd...@ho...>]

Wes,

Vous êtes une machine! I am deeply interested in what you are doing and I want to help at the right time and in the correct way.  You are doing the core PHDL compiler that writes PHDLIF.  I don't want to touch that.  

I am not a professional software developer but you know my little Xilinx2PHDL and Actel2PHDL utilities. I think they show I can write converters that go in and out of PHDL and PHDLIF.  Indeed, it was always my dream to be able to extend the PHDL compiler by writing such converters.

I'm going to dig around in your committed code to see what techniques you are using. It probably makes sense to use C++ for something like the PHDLIF to PADS converter. 

  Pete


-----Original Message-----
From: Wesley J. Landaker [mailto:wj...@ic...] 
Sent: Friday, February 22, 2013 5:41 AM
To: phd...@li...
Subject: [phdl-devel] Major PHDL C++ rewrite coming in 2013

Guys,

Consider this a just teaser trailer. Unless you're a real PHDL nut, you might want to skip this until I have something real to announce so you don't get asphixiated by the vaporware. ;)

I am actually not yet at a point where collaboration on code is particularly helpful, but since I've been working on this silently for a few months, I thought I'd at least share where I'm going with this. I've pushed out my latest master branch to the sourceforge repository under wjlanda/phdl-c++.

Just as a heads up, I have started working on a major PHDL rewrite in C++. I am developing an entirely new, much more modular engine, which will include both an upgrade to the PHDL syntax and a well-documented API for both front- end design creation using alternative methods, and easy creation of new back-end formats. Much of this work is coming out of my own previous work and research into a new, modern, HDL. I've decided to put that effort on hold until I get a robust PHDL baseline up and running, as I believe there are ways to leverage a lot of commonality between the languages. As part of this effort, I am also writing a complete, high-quality, user-friendly book- length language reference manual that doubles as both a specification and a tutorial.

In any case, I plan to have a good baseline (compiler + LRM book + external
API) implemented sometime in 2013. I'm in no particular hurry, other than the excitement I have because I want to actually finish and use this. 
(People in a hurry can use the existing PHDL 2.x. =) My biggest requirement for this new is extremely high code, documentation, and API quality. (Of course, everything I generate (book included) will be GPLv3 licensed.)

All that said, as I get pieces of my syntax upgrades, draft documents and exernal APIs completed, I do plan to discuss them here on the mailing list with any interested parties.

I'm not sure if anyone is going to keep maintaining (or moving forward) either of the two existing Java codebases. I have decided that I am not interested in doing so, and I assume that nobody else is going to. But that turns out not to be that case, I hope we can collaborate on language syntax and capabilities, as I have already put over 100s of hours research into the changes that I have coming.

I've pushed out my latest master branch to the sourceforge repository under wjlanda/phdl-c++. There isn't a ton there, as a lot of my work so far has been in other unshared branches, or just on paper. A lot of it is throw-away "playground" garbage that I need to clean up, but there are a few fun tidbits, that might be interesting to look at for folks who are deeply interested in what I'm doing and want to go nose around. In particular, I'd point to the highlight directory, which implements complete syntax highlighting for both GNU source-hightlight (thus usable by asciidoc) and, of course, Vim. Also, the PHDL_Language_Reference_Manual -- which is no where near complete, but I've started to hack up (mostly near the beginning) into something a little more formal -- shows a few insights.

If you've read this far, think this is worthwhile effort, and are wondering how you can help, awesome! At some point, I will absolutely welcome collaboration on both code, documentation, and API design -- but I'm not ready to do that *yet*.

One thing I'd love if someone would do is help figure out how to *robustly* generate backend netlists for various formats. We think we know how to generate PADS .asc and .p files pretty well, but PHDL so far only makes the former. Current PHDL makes output for Eagle pretty well I hear, but its not a tool I personally care tons about. We ought to support these formats, as well as others, like the format for the classic open source PCB tool (now part of gEDA) that is still widely used, or the format for KiCAD's PCBnew (another open source PCB tool). What about Altium? Its not enough to just generate files for these formats -- we also need to do so robustly, by understanding the complete file format. What is and isn't allowed? Character encoding and allowed characters and lengths of names for parts, components and reference designators? Largely, I believe there is a lot of reverse engineering and documentation work to do here, rather than any particular difficulty generating code to spit out the right format.

Anyway, that's what I'm up to. Now I'm heading back into sequestered work mode until I make some notable progress. I'll push out snapshots to the same branch in git every once in a while, and may periodically post things here hoping for feedback.

Happy PHDLing!

[phdl-devel] Major PHDL C++ rewrite coming in 2013

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

Guys,

Consider this a just teaser trailer. Unless you're a real PHDL nut, you 
might want to skip this until I have something real to announce so you don't 
get asphixiated by the vaporware. ;)

I am actually not yet at a point where collaboration on code is particularly 
helpful, but since I've been working on this silently for a few months, I 
thought I'd at least share where I'm going with this. I've pushed out my 
latest master branch to the sourceforge repository under wjlanda/phdl-c++.

Just as a heads up, I have started working on a major PHDL rewrite in C++. I 
am developing an entirely new, much more modular engine, which will include 
both an upgrade to the PHDL syntax and a well-documented API for both front-
end design creation using alternative methods, and easy creation of new 
back-end formats. Much of this work is coming out of my own previous work 
and research into a new, modern, HDL. I've decided to put that effort on 
hold until I get a robust PHDL baseline up and running, as I believe there 
are ways to leverage a lot of commonality between the languages. As part of 
this effort, I am also writing a complete, high-quality, user-friendly book-
length language reference manual that doubles as both a specification and a 
tutorial.

In any case, I plan to have a good baseline (compiler + LRM book + external 
API) implemented sometime in 2013. I'm in no particular hurry, other than 
the excitement I have because I want to actually finish and use this. 
(People in a hurry can use the existing PHDL 2.x. =) My biggest requirement 
for this new is extremely high code, documentation, and API quality. (Of 
course, everything I generate (book included) will be GPLv3 licensed.)

All that said, as I get pieces of my syntax upgrades, draft documents and 
exernal APIs completed, I do plan to discuss them here on the mailing list 
with any interested parties.

I'm not sure if anyone is going to keep maintaining (or moving forward) 
either of the two existing Java codebases. I have decided that I am not 
interested in doing so, and I assume that nobody else is going to. But that 
turns out not to be that case, I hope we can collaborate on language syntax 
and capabilities, as I have already put over 100s of hours research into the 
changes that I have coming.

I've pushed out my latest master branch to the sourceforge repository under 
wjlanda/phdl-c++. There isn't a ton there, as a lot of my work so far has 
been in other unshared branches, or just on paper. A lot of it is throw-away 
"playground" garbage that I need to clean up, but there are a few fun 
tidbits, that might be interesting to look at for folks who are deeply 
interested in what I'm doing and want to go nose around. In particular, I'd 
point to the highlight directory, which implements complete syntax 
highlighting for both GNU source-hightlight (thus usable by asciidoc) and, 
of course, Vim. Also, the PHDL_Language_Reference_Manual -- which is no 
where near complete, but I've started to hack up (mostly near the beginning) 
into something a little more formal -- shows a few insights.

If you've read this far, think this is worthwhile effort, and are wondering 
how you can help, awesome! At some point, I will absolutely welcome 
collaboration on both code, documentation, and API design -- but I'm not 
ready to do that *yet*.

One thing I'd love if someone would do is help figure out how to *robustly* 
generate backend netlists for various formats. We think we know how to 
generate PADS .asc and .p files pretty well, but PHDL so far only makes the 
former. Current PHDL makes output for Eagle pretty well I hear, but its not 
a tool I personally care tons about. We ought to support these formats, as 
well as others, like the format for the classic open source PCB tool (now 
part of gEDA) that is still widely used, or the format for KiCAD's PCBnew 
(another open source PCB tool). What about Altium? Its not enough to just 
generate files for these formats -- we also need to do so robustly, by 
understanding the complete file format. What is and isn't allowed? Character 
encoding and allowed characters and lengths of names for parts, components 
and reference designators? Largely, I believe there is a lot of reverse 
engineering and documentation work to do here, rather than any particular 
difficulty generating code to spit out the right format.

Anyway, that's what I'm up to. Now I'm heading back into sequestered work 
mode until I make some notable progress. I'll push out snapshots to the same 
branch in git every once in a while, and may periodically post things here 
hoping for feedback.

Happy PHDLing!

[phdl-devel] inst array simplification

[Peter D. <hd...@ho...>]

Wes,

I played around with it some more and I cannot see a syntax that doesn't get
messy or subtle using inst arrays on parts with bus pins.

Because this is for board designs everything must be perfectly clear.

I suggest that we just do not support inst arrays of parts with bus pins. We
should generate an error if it is tried.

  Pete

"There is power in humility."

Re: [phdl-devel] a very modest simplification proposal

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

On Wednesday, January 23, 2013 18:24:50 Wesley J. Landaker wrote:
> net clk, cs012, cs3, v33, gnd;
> inst(3:0) flip_flops of flip_flop_chip {
>    attribute REFDES(:) = {"U13", "U12", "U11", "U10"};
>    // common signals
>    clk(:) = <clk>; vcc(:) = <v33>; gnd(:) = <gnd>;
>    // common signal with an exception
>    cs(:) = <cs012>; cs(3) = cs3;

BTW, the compiler in my mind threw an error on this line, telling me cs(3) 
had been assigned twice. Then I fixed it to read:

  cs(2:0) = <cs012>; cs(3) = cs3;

See how nicely that worked! =)

Re: [phdl-devel] a very modest simplification proposal

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

On Wednesday, January 23, 2013 02:15:27 Peter Dudley wrote:
> ... or we could just use our concatenation syntax and the assignment
> becomes.
> 
> cs = {cs012,cs012,cs012,cs3};  // I'm not sure this is the right
> concatenation syntax but you get the idea.
> 
> Doesn't that eliminate rules 2 and 3.

It does for 1-bit nets, but remember the case I suggested:

On Tuesday, January 22, 2013 19:30:03 Wesley J. Landaker wrote:
> In this proposal, your example only has 1-bit ports. What would happen
> if the instance you want to put in array has a, say, 5-bit port, and you
> instance 7 of them?
> 
> Having the them all concatenate into a 35-bit port would be analogous to
> what you are showing happen with 1-bit ports, but that seems pretty
> obviously awkward. Other options (disallowing this, doing something
> different magically when there is more than 1-bit) are probably even
> worse.

// d_in is a 5-bit net
// d is 5-bit port, but in an 7:0 array is auto-combined to a 35-bit net
d = {d_in,d_in,d_in,d_in,d_in,d_in,d_in};

Is that what you're thinking? That would drive me nuts. =)

On Wednesday, January 23, 2013 02:15:27 Peter Dudley wrote:
> The situation gets complicated when you have something like a memory
> where the address pins all get the same nets but the data pins get
> different nets. If we really want to simplify, we probably have to
> simplify what the language can do.
> 
> Here is what I suggest for memories. There is no guessing about how the
> arrayed nets and pins are hooked up.
> 
> inst mem_array3 of sram_chip {address=address; data=data(31:24)};
> inst mem_array2 of sram_chip {address=address; data=data(23:16)};
> inst mem_array1 of sram_chip {address=address; data=data(15: 8)};
> inst mem_array0 of sram_chip {address=address; data=data( 7: 0)};

Yeah, that's what I'd probably end up writing if there were just 4 chips.

And, like I said above, if there were somehow 128 memories, I'd probably 
have already used hierarchy to combine chips in powers of 2 or 4 so that 
each level is easy to write but still simple and easy to understand.

Anyway, I agree simplification from the current syntax, even if it loses 
some flexibility is not a terrible price to pay; it's likely that if there 
are 100's of things to instance in non-uniform ways, hierarchy is probably a 
better solution than direct instance arrays anyway.

That said, I want to make sure that we don't pick up a syntax that is 
intuitive only when you have 1-bit ports. Here is another (more realistic) 
try. What do you think about this syntax, which has the following single 
rule:

  1. All pins in the array must be assigned via indexing.

// each flip_flop has a 4-bit d and q port
net      d_in0_lsb;
net[3:1] d_in0_msbs;
net[3:0] d_in1;
net[3:0] d_in2;
net[3:0] d_in3;
net[3:0] q_out0;
net[3:0] q_out1;
net[3:0] q_out2;
net[3:0] q_out3;
net clk, cs012, cs3, v33, gnd;
inst(3:0) flip_flops of flip_flop_chip {
   attribute REFDES(:) = {"U13", "U12", "U11", "U10"};
   // common signals
   clk(:) = <clk>; vcc(:) = <v33>; gnd(:) = <gnd>;
   // common signal with an exception
   cs(:) = <cs012>; cs(3) = cs3;
   // signals combined into a bus, with an exception
   // still straightforward and unambiguous
   d(3:1) = {d_in3,d_in2,d_in1};
   d(0) = {d_in0_msbs,d_in0_lsb};
   // ports assigned individually
   // that could could also have been written as:
   //   q(:) = {q_out3,q_out2,q_out1,q_out0};
   // but this way would be more as to read if there were lots of
   // different signals, etc
   q(0) = q_out0;
   q(1) = q_out1;
   q(2) = q_out2;
   q(3) = q_out3;
}

As you can see I've taken the liberty to use the pythonish/matlabish (:) 
mean the entire bounds, but the point is that here you get the advantage of 
combining or not and there is nothing ambiguous anywhere.

Basically the idea is that you have an array of instances, so now you are 
assigning to an array of (possibly multibit) pins. There is no ambiguity as 
there aren't any defaults and there is no automatic magic combining. Yet, 
it's very easy to bus everything up with (:) syntax or expand out signal 
nets with <> syntax. It's an error if you forget to assign any part of any 
port, so there is no danger of missing something.

Come on, you know you like this one. =)

Re: [phdl-devel] a very modest simplification proposal

[Peter D. <hd...@ho...>]

... or we could just use our concatenation syntax and the assignment becomes.

cs = {cs012,cs012,cs012,cs3};  // I'm not sure this is the right concatenation syntax but you get the idea.

Doesn't that eliminate rules 2 and 3.


The situation gets complicated when you have something like a memory where the address pins all get the same nets but the data pins get different nets. If we really want to simplify, we probably have to simplify what the language can do.

Here is what I suggest for memories. There is no guessing about how the arrayed nets and pins are hooked up.

inst mem_array3 of sram_chip {address=address; data=data(31:24)}; 
inst mem_array2 of sram_chip {address=address; data=data(23:16)}; 
inst mem_array1 of sram_chip {address=address; data=data(15: 8)}; 
inst mem_array0 of sram_chip {address=address; data=data( 7: 0)};



-----Original Message-----
From: Wesley J. Landaker [mailto:wj...@ic...] 
Sent: Wednesday, January 23, 2013 3:34 AM
To: phd...@li...; peter dudley
Subject: Re: [phdl-devel] a very modest simplification proposal

On 01/22/2013 07:30 PM, Wesley J. Landaker wrote:
> 1. If a plain pin name is assigned, it is assigned the same to all of 
> the instances.
>
> 2. If an indexed pin names are assigned, it only applies to those instances.
>
> 3. Rule #2 takes precedence over rule #1.
>
> Here is your example, slightly modified to illustrate:
>
> net[3:0] d_in, q_out;
> net clk, cs012, cs3, v33, gnd;
> inst(3:0) flip_flops of flip_flop_chip {
>     attribute REFDESPREFIX = "U"; // applies to all of them
>     attribute REFDES(3:0) = "U13", "U12", "U11", "U10";
>     clk = clk; vcc = v33; gnd = gnd; // common signals
>     cs = cs123; cs(3) = cs3; // common signal with an exception
>     d(3:0) = d_in; q_out(3:0) = q_out; // signals combined into a bus 
> }

We could even eliminate rule #3 by making the chip-select line look like
this:

cs(0:2) = <cs012>; cs(3) = cs3; // common signal with an exception

Even simpler rules, and maybe even easier to read and understand.

Re: [phdl-devel] a very modest simplification proposal

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

On 01/22/2013 07:30 PM, Wesley J. Landaker wrote:
> 1. If a plain pin name is assigned, it is assigned the same to all of
> the instances.
>
> 2. If an indexed pin names are assigned, it only applies to those instances.
>
> 3. Rule #2 takes precedence over rule #1.
>
> Here is your example, slightly modified to illustrate:
>
> net[3:0] d_in, q_out;
> net clk, cs012, cs3, v33, gnd;
> inst(3:0) flip_flops of flip_flop_chip {
>     attribute REFDESPREFIX = "U"; // applies to all of them
>     attribute REFDES(3:0) = "U13", "U12", "U11", "U10";
>     clk = clk; vcc = v33; gnd = gnd; // common signals
>     cs = cs123; cs(3) = cs3; // common signal with an exception
>     d(3:0) = d_in; q_out(3:0) = q_out; // signals combined into a bus
> }

We could even eliminate rule #3 by making the chip-select line look like 
this:

cs(0:2) = <cs012>; cs(3) = cs3; // common signal with an exception

Even simpler rules, and maybe even easier to read and understand.

Re: [phdl-devel] a very modest simplification proposal

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

On 12/19/2012 05:56 AM, Peter Dudley wrote:
> I created alittle document(with a picture)suggesting a simplification to
> the PHDL inst array syntax.  I attach it to this email but I don’t know
> if attachments go through this email expanderso here is the path into
> the git
> repo_http://git.code.sf.net/p/phdl/cod__e/doc/inst_array_proposal.pdf_<http://git.code.sf.net/p/phdl/code/doc/inst_array_proposal.pdf>

I think there is a way to get a better, more easily-understandable 
expressiveness than our current inst arrays without completely 
eliminating this quite useful functionality and I think your 
simplification proposal is a good starting point to address this.

In this proposal, your example only has 1-bit ports. What would happen 
if the instance you want to put in array has a, say, 5-bit port, and you 
instance 7 of them?

Having the them all concatenate into a 35-bit port would be analogous to 
what you are showing happen with 1-bit ports, but that seems pretty 
obviously awkward. Other options (disallowing this, doing something 
different magically when there is more than 1-bit) are probably even worse.

But that's okay -- I bet we can make this work. A slight alternative 
that addresses this would be to have a simplification similar to your 
proposed modification, but with the following straightforward rules:

1. If a plain pin name is assigned, it is assigned the same to all of 
the instances.

2. If an indexed pin names are assigned, it only applies to those instances.

3. Rule #2 takes precedence over rule #1.

Here is your example, slightly modified to illustrate:

net[3:0] d_in, q_out;
net clk, cs012, cs3, v33, gnd;
inst(3:0) flip_flops of flip_flop_chip {
   attribute REFDESPREFIX = "U"; // applies to all of them
   attribute REFDES(3:0) = "U13", "U12", "U11", "U10";
   clk = clk; vcc = v33; gnd = gnd; // common signals
   cs = cs123; cs(3) = cs3; // common signal with an exception
   d(3:0) = d_in; q_out(3:0) = q_out; // signals combined into a bus
}

I feel like this is VERY readable, and is easy to understand and 
explain. It keeps both the simplicity you proposed as well as most of 
the power of the current implementation with making anyone stumble over 
cryptic "this/combine" syntax. Best of all, to me this FEELS like PHDL.

What do you think?

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!

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

[peter d. <hd...@ho...>]

Wes, thanks for getting all that down in words. Here are my thoughts on your comments.

>= 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;}

 = Required Attributes =
It sounds right what you are saying about making all attributes optional.  

It sounds like all attributes, including my beloved PINCOUNT, can be optional.  I don't put PINCOUNT on my resistor definitions for example.

Big, fat, all UPPERCASE attributes do seem wrong.  Let's do whatever is right.  I don't know the answer to all these case issues but after 50 years living in the Computer Age we should know what to do.

 == 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.

== Pin Types ==
I agree with Wes on this.  Plus, it simplifies the language to eliminate those keywords from the language.  I will stay tuned to see more on the idea of Attributes on Anything and how that might be used down the road.

== 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. :-)

== Reference Designator Prefix Combining ==
Exactement.

== 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.

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.  

Bonsoir,

  Pete
 		 	   		  

Re: [phdl-devel] PHDL 3.0 Specification comments and suggestions.

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

On Thursday, January 17, 2013 18:45:58 Joshua Mangelson wrote:
> I just committed the final copy of our projected PHDL Language Spec.
> If everyone has time to look it over and make comments or ideas for
> changes. That would be great!

I've got a few comments. Let me add them here in order as they follow the 
specification document. I'll quote Pete in related sections as well so we 
can keep comments together. We can split each part into a separate thread if 
necessary.

= Packages and Imports =

The way the spec reads, it's unclear how packages and imports interact. 
Let's discuss some specifics, assuming I have a device "device1" and 
"device2" in package "package1", and a "device1" in the current package (for 
some cases) and a device called "package1" (in the last examples).

This is how I would assume -- and kind of hope -- things work. If it doesn't 
work like this, let's talk about how it does work.

Example #1:
  import package1;
  device device1 ...;
  // WORKS: package1.device1
  // WORKS: package1.device2
  // WORKS: device1 (refers to my local device1)
  // FAILS: device2

Example #2:
  import package1.device1; or import package1.*;
  device device1 ...; // FAILS here because device1 has been imported

Example #3:
  import package1.device2;
  device device1 ...;
  // FAILS: package1.device1 (because it was not imported)
  // FAILS: package1.device2 (because device2 was imported, not package1)
  // WORKS: device1 (refers to my local device1)
  // WORKS: device2 (refers package1.device2)

Example #4:
  import package1.*;
  // FAILS: package1.device1 (because * was imported, not package1)
  // FAILS: package1.device2 (because * was imported, not package1)
  // WORKS: device1 (refers package1.device1)
  // WORKS: device2 (refers package1.device2)

Example #5:
  import package1;
  device package1 ...; // FAILS here because package1 has been imported

Example #6:
  import package1.*
  device package1 ...;
  // FAILS: package1.device1 (because * was imported, not package1)
  // FAILS: package1.device2 (because * was imported, not package1)
  // WORKS: device1 (refers package1.device2)
  // WORKS: device2 (refers package1.device2)
  // WORKS: package1 (refers to my local device)

Basically, this means that we only import names that are specifically asked 
for. If importing those names causes ambiguity, that it causes an error. 
These are strongly desired properties to avoid errors.

Now, I see verbage in the "Qualified Namespaces" section that says that 
packages can be used even if they aren't imported. I'd suggest that defeats 
the purpose of having import statements and hierarchy at all, as it gloms 
lots of unnecessary things (package names) into a global namespace, and 
makes working around name conflicts between unrelated nets/devices/packages 
almost impossible to resolve.

= Packages and Imports -- Transitivity =

What about when a package imports things, then is imported? Take the 
following example:

// in package1
device device1 ...;
device device2 ...;

// in package2
import package1.*;

// in top-level package
import package2;
// can I use device1 here?

I would propose that trying to use device1 there does NOT work. The default 
behavior should be that packages do not export names that they have 
imported. Otherwise, this breaks encapsulation and any abstraction 
guarantees you might hope for with hierarchy.

If we want to be able to do this kind of thing (e.g. having a meta-package 
that imports certain devices and then makes them available for use) I would 
suggest we add an "export" keyword so that package can explicitly state what 
things that they have imported that they wish to export.

The other choice is to make the use of device1 above always work. That would 
mean that the default is that packages always export all names that they can 
see, and leave it up to the user to be explicit and not use ".*" poorly. I'd 
argue that in this case, we've made ".*" a land-mine feature and it should 
be removed.

For reference, this *EXACT SAME PROBLEM* came up in Python, and they had to 
do massive hacks to the language to avoid ".*" causing bugs while trying to 
maintain backwards compatibility. I'd say lets just get this right in the 
first place.

= Required Attributes =

I'd suggest that making attributes required in the *language* (as opposed to 
being required by a particular back-end) may be too heavy handed. For 
example, REFPREFIX is all blank everywhere? Okay, then your parts all get 
named "1", "2", "3", etc. If you don't like it, add a REFPREFIX. If that 
doesn't work with some tool's backend, then it can add a default REFPREFIX 
(like forcing a "U" in front or whatever). Why should PHDL itself care? No 
FOOTPRINT attribute? Okay, then it's blank. Maybe the backend will complain, 
or maybe it won't. The PHDL language itself shouldn't tell you what to do. 
Same for LIBRARY. What if my backend doesn't even use libraries?

Also, I really dislike the uppercase REFPREFIX, FOOTPRINT, and LIBRARY. Why 
all uppercase? Nothing else in PHDL (or modern computer languages) is all 
UPPERCASE.

My belief is that the PHDL language (as opposed to backends) should treat 
all attributes as just pass-throughs. PHDL should not interpret them in any 
way. Specific back-ends (e.g. the PADS backend) may be written so as to 
expect or require certain attributes to be set. DRC tools could verify that 
certain attributes are set, or look for and warn about attributes set that 
aren't used by a certain system. Both of those might be built into the same 
compiler implementation. But the PHDL language itself has no business 
telling me what my attributes should be.

Same thing goes with even the REFDES and PINCOUNT attributes. Its totally 
fine for these to be used by various backends, (netlisters, DRCs, BoM 
generators, etc) but the PHDL language itself should just treat them like 
any other attribute. This leaves the language much more flexible and 
extensible by users. I know in my own designs, I will use many, many more 
DRC-related attributes, because I'm a static-checking nut; but I don't want 
them cooked into the PHDL language.

== Attributes on Everything ==

Attributes should be placeable on everything. Devices (check), Instances 
(check), Pins (not currently possible), and Nets (check). We really want to 
have a uniform syntax to apply attributes to all of these objects.

== Pin Types ==

On Friday, January 18, 2013 07:17:47 Peter Dudley wrote:
> PinType - Do we really want to have all those PinType reserved words,
> "pin", "inpin", "outpin",.   There are 11 of them.  I remember that Wes
> had some concern about this feature.  I know having this was a
> suggestion from me to allow error checking but let's do what really
> makes sense.

I love being able to statically check a design for correctness, but I'm 
strongly against the keyword-based pin type syntax. I think this kind of 
thing should be handled in a uniform way with pin attributes, which we can 
already support very easily and consistently.

First, the names are confusing. Nobody knows what "oepin" is. Most engineers 
might guess something like "output enable?". What's a "passpin"? Something 
that just passes through a signal? Even though I've looked at this many 
times, when I went to comment on them this time, I could remember what those 
two were supposed to be until I read the description.

Second, the categories that we have: in, out, inout, power, supply, open-
collector, open-emitter, tri-state, passive, and no-connect are not 
exhaustive, are weirdly overlapping. What's the difference between a power 
pin and a supply pin? I can imagine, but to most engineers those are 
synonyms. What about pins like a Xilinx FPGA's DONE? You tell me what pin 
type it is from the list above, and I'll tell you why you are wrong.

Next, its unclear how this would even work in practice. A regulator's output 
is a suppin (I'd suppose). It goes directly to an inductor's passpin. 
Everything else using that power supply is just hooked up to the inductor's 
passpin. The supply pin never touches anyone's pwrpin. No DRC can do 
anything about this unless it can model the parts themselves (e.g. it knows 
what an inductor is).

Even, matching inputs, outputs and bidirectional signals is a start (and is 
what most graphical schematic tools support -- mostly just for looks, not 
DRC), but falls apart quickly. I have an oscillator output that's an outpin, 
and it goes to my processor's clock input which is an inpin. Except, it 
doesn't really, because it hits a series source termination resistor with 
passpins on both sides first. Now, when I hook it up wrong (to a processor 
output) all is well in the DRC, because outpin -- passpin and passpin -- 
output.

These kind of issues prevent our current ugly, hard-coded, non-extensible, 
keyword-based pin types into an failed, overreaching system right from the 
start. To make matters worse, they don't even help check the most common 
errors like, "did I hook up a 1.8 V line to the FPGA's 3.3 V bank on 
accident?".

That kind of question -- and *all* others -- could be answered fairly simply 
by just allowing the user to annotate pin attributes however they wish and 
process the reports in whatever way makes sense (manually checking, a custom 
DRC tool, etc).

If we want to later canonize a DRC tool or cook it into the language in a 
good way, I'd suggest we do that as its own separate effort once the 
language is robust, because its more complex that it sounds and has to be 
done in a user-controlled-and-user-extensible-per-design way to have any 
real-world value.
 
== Info Statement ==

>  InfoStatement - Is this much better than regular comments?  I think it
> could be and probably does no harm.  My guess is we would want the
> InfoStatement information to go into a report of some kind.  The "Layout
> Guy" would be able to read that report for guidance.  On the other hand,
> I would probably not use that feature.  I always write up a separate
> document to explain special layout requirements and send it to the
> Layout Guy along with the netlist data.

The idea was supposed to be to make generating special layout requirements 
documents automatically. I think this was a fun idea, but really won't work 
in practice -- several (now obsolete) computer languages have tried this 
kind of thing in the past. I'd say to ditch the info statement syntax and, 
if desired, do automatic comment extraction via tools like doxygen if so 
desired.

== Reference Designator Prefix Combining ==

> REFPREFIX - Here you say, " In either case the "/" character will be used
> as a delimiter between the REFPREFIX and the original reference
> designator."  I don't think we want to include any kind of delimiter in
> the RefDes string. It is desireable to be able to print the RefDes onto
> the printed circuit board so characters are precious.  I think "XYR17"
> might be acceptable as a refDes but "X/Y/R17" is probably not acceptable
> to most designers.  Also, I suspect that many layout tools would not
> accept the "/" character in the refDes string.

I agree. Back-ends that use the REFPREFIX attribute should not tack anything 
in the REFDES that isn't requested by the user. If I want "XYR17", I'll give 
REFPREFIX attributes of "X", "Y", and "R". If I want "X/Y/R17", I'll give 
REFPREFIX attributes of "X/", "Y/" and "R".

== Looping / Instance Array Simplication ==

> Inst array simplification - I did not get much comment back on my
> suggestions about simplifying the inst array syntax that we have
> presently. You can find my document on that subject in the git
> repository under doc/inst_array_proposal.pdf.   I think the changes I
> suggest in there would make instance arrays work much more like the rest
> of the PHDL language. Assigning REFDES to an inst array would be just
> like assigning pin numbers to an array of pins on a device.   It would
> also eliminate the need for the combine() and this() operators.  In
> effect, pins would always combine().

I'm convinced that we absolutely must ditch the this() and combine() syntax. 
Sadly, I'm probably the one who originally pushed for such flexable 
instatiation syntax in the first place. It gives us a lot of power in a 
monadic functional style. But I think it takes too much in-head-processing 
(a lot like reading Haskell code) and is kind of a write-only feature that 
is hard to review and unfortunately I think inappropriate for our goals. 
Basically, its the part of PHDL that doesn't look like PHDL.

That said, we *CAN'T* get rid of inst arrays. They are way too useful. 
Looping/arrays is fundamental But we *can* simplify them.

> In discussions with other folk, I often find that combine() and this()
> interfere with communicating the purpose and goals of the language.
> Typically a conversations starts like this, "Hey, did you get an
> opportunity to look at the PHDL stuff?".  The response is something like
> this "Yeah, I've never seen anything like that combine() operator" 45
> minutes later it is "Hey, maybe you could do this or that instead of the
> combine() thing.."

I think Pete's proposal has a lot of merit, although I'd change a few things 
about the syntax. I don't have time now to go into it, but I'm confident it 
has to be done. So let's continue this discussion, and I'll throw in my 
opinion next time around. =)

== inst vs subinst ==

I think having design and subdesign makes sense, because subdesigns have to 
contain ports to be useful, and designs should NEVER contain ports. Having 
multiple subdesigns makes sense, but multiple designs probably means you 
pointed the compiler to the wrong files. So there is a real reason to have 
those be different.

But, why do we need inst for regular devices and subinst for subdesigns? 
They share the same namespace, and subdesigns look like devices from the 
users perspective, even if the language secretly knows they are different. 
Let's just use "inst" for both, and get rid of the special magic non-
attribute REFPREFIX that subinst uses. It can be put in an attribute just 
like any other if desired.

== End ==

That's all I have time to write about for now. It's great to see we've got 
so much written up here. I think we'll be really happy once we get the spec 
really solid. Better to spend time now getting it right. =)

Re: [phdl-devel] PHDL Spec

[Peter D. <hd...@ho...>]

Josh

 

I am trying to use the SubAttrReference thing to control attribute values
down in the hierarchy.

 

The PHDL 3.0 specification mentions this feature but not provide enough
explanation to actually use it.  Also, none of the tutorials show its use.
Can you add an example or more explanation for this to the spec?

 

  Pete

 

From: Joshua Mangelson [mailto:jos...@gm...] 
Sent: Friday, January 18, 2013 2:46 AM
To: <phd...@li...>
Subject: [phdl-devel] PHDL Spec

 

Hey Everybody,

 

I just committed the final copy of our projected PHDL Language Spec. 

If everyone has time to look it over and make comments or ideas for changes.
That would be great!

 

Thanks!

 

Joshua

[phdl-devel] PHDL 3.0 Specification comments and suggestions.

[Peter D. <hd...@ho...>]

Josh,

Thanks for doing that PHDL 3.0 specification document.   I found it readable
and concise.  Here are a few comments and suggestions.

PinType - Do we really want to have all those PinType reserved words, "pin",
"inpin", "outpin",.   There are 11 of them.  I remember that Wes had some
concern about this feature.  I know having this was a suggestion from me to
allow error checking but let's do what really makes sense.

 InfoStatement - Is this much better than regular comments?  I think it
could be and probably does no harm.  My guess is we would want the
InfoStatement information to go into a report of some kind.  The "Layout
Guy" would be able to read that report for guidance.  On the other hand, I
would probably not use that feature.  I always write up a separate document
to explain special layout requirements and send it to the Layout Guy along
with the netlist data.

REFPREFIX - Here you say, " In either case the "/" character will be used as
a delimiter between the REFPREFIX and the original reference designator."  I
don't think we want to include any kind of delimiter in the RefDes string.
It is desireable to be able to print the RefDes onto the printed circuit
board so characters are precious.  I think "XYR17" might be acceptable as a
refDes but "X/Y/R17" is probably not acceptable to most designers.  Also, I
suspect that many layout tools would not accept the "/" character in the
refDes string.

Inst array simplification - I did not get much comment back on my
suggestions about simplifying the inst array syntax that we have presently.
You can find my document on that subject in the git repository under
doc/inst_array_proposal.pdf.   I think the changes I suggest in there would
make instance arrays work much more like the rest of the PHDL language.
Assigning REFDES to an inst array would be just like assigning pin numbers
to an array of pins on a device.   It would also eliminate the need for the
combine() and this() operators.  In effect, pins would always combine().

In discussions with other folk, I often find that combine() and this()
interfere with communicating the purpose and goals of the language.
Typically a conversations starts like this, "Hey, did you get an opportunity
to look at the PHDL stuff?".  The response is something like this "Yeah,
I've never seen anything like that combine() operator" 45 minutes later it
is "Hey, maybe you could do this or that instead of the combine() thing.."



     Pete Dudley
     pe...@hd...
     www.HDLGuy.com

"Remember, we are human beings."

[phdl-devel] PHDL Spec

[Joshua M. <jos...@gm...>]

Hey Everybody,

I just committed the final copy of our projected PHDL Language Spec.
If everyone has time to look it over and make comments or ideas for
changes. That would be great!

Thanks!

Joshua

[phdl-devel] DesignCon - Santa Clara ?

[Peter D. <hd...@ho...>]

Guys,

Did we do anything for DesignCon?

http://designcon.com/santaclara/



     Pete Dudley
     hd...@ho...
     www.HDLGuy.com