phdl-devel — PHDL General Development Discussion

Re: [phdl-devel] leaving ports connected

[Chris S. <mr....@gm...>]

Ah, okay.. that makes more sense.. and I tried it and it worked ;-)

I saw the reserved word "open" but it seemed to be in the same list as
"oepin" and other specific pin types... It makes sense now! Thanks!

On Sun, Jun 28, 2015 at 9:13 PM, Brent Nelson <bre...@by...> wrote:

>  I believe Pete is correct – the goal was to not allow anything to slip
> through and so nothing was left to assumption on the part of the CAD tool.
> We figured this would minimize mistakes.
>
>  Brent Nelson
>
>
>
>   From: peter dudley <hd...@ho...>
> Date: Sunday, June 28, 2015 at 12:41 PM
> To: Chris Styles <mr....@gm...>, "
> phd...@li..." <phd...@li...>
> Subject: Re: [phdl-devel] leaving ports connected
>
>   Chris,
>
> I haven't used PHDL in about a year because I have been doing fpga work.
>
> We decided to require every pin to be handled by the user to minimize
> mistakes.  As I recall there is a reserved work "open" that you can assign
> to a pin to tell the compiler that you have looked at the pin and decided
> to leave it open.  This comes from the VHDL language where it is optional
> but very good practice.  In PHDL it is required to either assign a net or
> assign it as open.
>
> Please try using "open" instead of creating an NC net that then must be
> cleaned out of the netlist.
>
> Guys, Am I correct on this?
>
>   Pete
>
>  ------------------------------
> Date: Sun, 28 Jun 2015 17:55:55 +0100
> From: mr....@gm...
> To: phd...@li...
> Subject: [phdl-devel] leaving ports connected
>
> Hi All (again),
>
>  So it looks like if i make a device, when I instance it, i have to
> connect every pin to something, else I get an error.
>
>  On a physical device on a real PCB (like and MCU) I might not want to
> use every pin. In the end i created a net called "NC" and hooked it up to
> all the unused pins so it would elaborate, but thats messy when youre in
> Eagle.
>
>  Possible solutions :
>
>  1. downgrade the ERROR to a warning
> 2. dont insist that every pin has a net
> 3. enable a pin to be connected to "NULL" or a specially named net that
> prevents it being hooked up in the Eagle file.
>
>
>  Also, while I am here, I dont seem to be able to overide an attribute in
> an instance.
>
> For example, I want to make a resistor component that has the attribute
> "FOOTPRINT" set to R0805 as a default, but then be able to make an instance
> that overrides the footprint to "R0402" for example. Or, alternatively, not
> requrie the FOOTPRINT to be given value in the device "attrib footprint =
> """ and then give it a value in the instance.
>
>  Cheers,
> Chris
>
> ------------------------------------------------------------------------------
> Monitor 25 network devices or servers for free with OpManager! OpManager is
> web-based network management software that monitors network devices and
> physical & virtual servers, alerts via email & sms for fault. Monitor 25
> devices for free with no restriction. Download now
> http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
> _______________________________________________ phdl-devel mailing list
> phd...@li...
> https://lists.sourceforge.net/lists/listinfo/phdl-devel
>   ------------------------------
>   Mark as Spam
> ------------------------------
>

Re: [phdl-devel] leaving ports connected

[Brent N. <bre...@by...>]

I believe Pete is correct - the goal was to not allow anything to slip through and so nothing was left to assumption on the part of the CAD tool.  We figured this would minimize mistakes.

Brent Nelson



From: peter dudley <hd...@ho...<mailto:hd...@ho...>>
Date: Sunday, June 28, 2015 at 12:41 PM
To: Chris Styles <mr....@gm...<mailto:mr....@gm...>>, "phd...@li...<mailto:phd...@li...>" <phd...@li...<mailto:phd...@li...>>
Subject: Re: [phdl-devel] leaving ports connected

Chris,

I haven't used PHDL in about a year because I have been doing fpga work.

We decided to require every pin to be handled by the user to minimize mistakes.  As I recall there is a reserved work "open" that you can assign to a pin to tell the compiler that you have looked at the pin and decided to leave it open.  This comes from the VHDL language where it is optional but very good practice.  In PHDL it is required to either assign a net or assign it as open.

Please try using "open" instead of creating an NC net that then must be cleaned out of the netlist.

Guys, Am I correct on this?

  Pete

________________________________
Date: Sun, 28 Jun 2015 17:55:55 +0100
From: mr....@gm...<mailto:mr....@gm...>
To: phd...@li...<mailto:phd...@li...>
Subject: [phdl-devel] leaving ports connected

Hi All (again),

So it looks like if i make a device, when I instance it, i have to connect every pin to something, else I get an error.

On a physical device on a real PCB (like and MCU) I might not want to use every pin. In the end i created a net called "NC" and hooked it up to all the unused pins so it would elaborate, but thats messy when youre in Eagle.

Possible solutions :

1. downgrade the ERROR to a warning
2. dont insist that every pin has a net
3. enable a pin to be connected to "NULL" or a specially named net that prevents it being hooked up in the Eagle file.


Also, while I am here, I dont seem to be able to overide an attribute in an instance.

For example, I want to make a resistor component that has the attribute "FOOTPRINT" set to R0805 as a default, but then be able to make an instance that overrides the footprint to "R0402" for example. Or, alternatively, not requrie the FOOTPRINT to be given value in the device "attrib footprint = """ and then give it a value in the instance.

Cheers,
Chris

------------------------------------------------------------------------------ Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical & virtual servers, alerts via email & sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
_______________________________________________ phdl-devel mailing list phd...@li...<mailto:phd...@li...> https://lists.sourceforge.net/lists/listinfo/phdl-devel
________________________________
________________________________

Re: [phdl-devel] leaving ports connected

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

I intended to say, reserved word "open". 
 
From: hd...@ho...
To: mr....@gm...; phd...@li...
Date: Sun, 28 Jun 2015 14:41:16 -0400
Subject: Re: [phdl-devel] leaving ports connected




Chris,
 
I haven't used PHDL in about a year because I have been doing fpga work.
 
We decided to require every pin to be handled by the user to minimize mistakes.  As I recall there is a reserved work "open" that you can assign to a pin to tell the compiler that you have looked at the pin and decided to leave it open.  This comes from the VHDL language where it is optional but very good practice.  In PHDL it is required to either assign a net or assign it as open.
 
Please try using "open" instead of creating an NC net that then must be cleaned out of the netlist.
 
Guys, Am I correct on this?
 
  Pete
 
Date: Sun, 28 Jun 2015 17:55:55 +0100
From: mr....@gm...
To: phd...@li...
Subject: [phdl-devel] leaving ports connected

Hi All (again),
So it looks like if i make a device, when I instance it, i have to connect every pin to something, else I get an error.
On a physical device on a real PCB (like and MCU) I might not want to use every pin. In the end i created a net called "NC" and hooked it up to all the unused pins so it would elaborate, but thats messy when youre in Eagle.
Possible solutions :
1. downgrade the ERROR to a warning2. dont insist that every pin has a net3. enable a pin to be connected to "NULL" or a specially named net that prevents it being hooked up in the Eagle file.

Also, while I am here, I dont seem to be able to overide an attribute in an instance.
For example, I want to make a resistor component that has the attribute "FOOTPRINT" set to R0805 as a default, but then be able to make an instance that overrides the footprint to "R0402" for example. Or, alternatively, not requrie the FOOTPRINT to be given value in the device "attrib footprint = """ and then give it a value in the instance.
Cheers,Chris 

------------------------------------------------------------------------------
Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors 
network devices and physical & virtual servers, alerts via email & sms 
for fault. Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
_______________________________________________
phdl-devel mailing list
phd...@li...
https://lists.sourceforge.net/lists/listinfo/phdl-devel 		 	   		  

------------------------------------------------------------------------------
Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors 
network devices and physical & virtual servers, alerts via email & sms 
for fault. Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
_______________________________________________
phdl-devel mailing list
phd...@li...
https://lists.sourceforge.net/lists/listinfo/phdl-devel 		 	   		  

Re: [phdl-devel] leaving ports connected

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

Chris,
 
I haven't used PHDL in about a year because I have been doing fpga work.
 
We decided to require every pin to be handled by the user to minimize mistakes.  As I recall there is a reserved work "open" that you can assign to a pin to tell the compiler that you have looked at the pin and decided to leave it open.  This comes from the VHDL language where it is optional but very good practice.  In PHDL it is required to either assign a net or assign it as open.
 
Please try using "open" instead of creating an NC net that then must be cleaned out of the netlist.
 
Guys, Am I correct on this?
 
  Pete
 
Date: Sun, 28 Jun 2015 17:55:55 +0100
From: mr....@gm...
To: phd...@li...
Subject: [phdl-devel] leaving ports connected

Hi All (again),
So it looks like if i make a device, when I instance it, i have to connect every pin to something, else I get an error.
On a physical device on a real PCB (like and MCU) I might not want to use every pin. In the end i created a net called "NC" and hooked it up to all the unused pins so it would elaborate, but thats messy when youre in Eagle.
Possible solutions :
1. downgrade the ERROR to a warning2. dont insist that every pin has a net3. enable a pin to be connected to "NULL" or a specially named net that prevents it being hooked up in the Eagle file.

Also, while I am here, I dont seem to be able to overide an attribute in an instance.
For example, I want to make a resistor component that has the attribute "FOOTPRINT" set to R0805 as a default, but then be able to make an instance that overrides the footprint to "R0402" for example. Or, alternatively, not requrie the FOOTPRINT to be given value in the device "attrib footprint = """ and then give it a value in the instance.
Cheers,Chris 

------------------------------------------------------------------------------
Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors 
network devices and physical & virtual servers, alerts via email & sms 
for fault. Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
_______________________________________________
phdl-devel mailing list
phd...@li...
https://lists.sourceforge.net/lists/listinfo/phdl-devel 		 	   		  

[phdl-devel] leaving ports connected

[Chris S. <mr....@gm...>]

Hi All (again),

So it looks like if i make a device, when I instance it, i have to connect
every pin to something, else I get an error.

On a physical device on a real PCB (like and MCU) I might not want to use
every pin. In the end i created a net called "NC" and hooked it up to all
the unused pins so it would elaborate, but thats messy when youre in Eagle.

Possible solutions :

1. downgrade the ERROR to a warning
2. dont insist that every pin has a net
3. enable a pin to be connected to "NULL" or a specially named net that
prevents it being hooked up in the Eagle file.


Also, while I am here, I dont seem to be able to overide an attribute in an
instance.

For example, I want to make a resistor component that has the attribute
"FOOTPRINT" set to R0805 as a default, but then be able to make an instance
that overrides the footprint to "R0402" for example. Or, alternatively, not
requrie the FOOTPRINT to be given value in the device "attrib footprint =
""" and then give it a value in the instance.

Cheers,
Chris

[phdl-devel] phdlcomp switches

[Chris S. <mr....@gm...>]

HI All,

So I am looking at how i would use phdl in a real environment, i.e. trying
to build something with it.

I am trying to specify multiple include directories in the compilation (as
oyu might do if you were compiling a C program, and im not having much
luck. I couldnt get the output redirect to work either

I am using :

java -jar phdlcomp.jar -all -src ./ -src ./lib -get ./out

It seems to acknowledge the paths, but doenst elaborate anything or output
anything

Suggestions?

sorry, I know this is 101 stuff, but im strugglig to navigate the docs.

Cheers,
Chris

[phdl-devel] PHDL newbie

[Chris S. <mr....@gm...>]

HI All,

I have spent the morning getting to grips with this, and I'm really
enjoying it.

Two questions :

1. EagleDeviceGen seems to be really flakey. Is it maintained? Is richard
black still around?

2. When I make an instance of a device, it looks like I cant leave any pin
unconnected.. they all have to be connected to a net, or you get an Error.
Is there any way to turn this error to a warning, and I dont actually want
to connect every pin?

3. What is the active development around this?



Thanks,
Chris

[phdl-devel] annotate phdl to eagle/pads

[Andreas R. <a.r...@od...>]

Hi,

how can new components add to a ready circuit board?

(annotation to routed Board)

 

Thanks,

  Andreas

 

   

[phdl-devel] Pin aliases?

[Rick M. <rm...@la...>]

Working with MCUs, many of the pins are configurable to a number of different functions. Is there any way to specify aliased names for pins to better reflect the function used?

Can I do:

    pin PA0                     =   { 23 };
    pin inpin   USART1_RX       =   { 23 };
    pin outpin  TMR2_CC1_OUT    =   { 23 };

and then later reference the pins with any of those names?

Also, it would be nice to be able to change the pin type during instantiation (for example, PA0 can be configured by software to be either an input or an output).

-- 
Rick Mann
rm...@la...

Re: [phdl-devel] Any way to ignore ERROR:Unassigned pin?

[Rick M. <rm...@la...>]

So, open helps, but it's a bit unwieldy in that I have to specify a lot of pins.

> On Nov 4, 2014, at 13:04 , Brad R <bra...@gm...> wrote:
> 
> Rick,
> 
> If I understand what you want to do, you should be able to do this with the "open" keyword.  Just declare the pins that you don't want to have connect to anything as "open"  (without quotes).
> 
> Regards,
> Brad
> 
> On Fri, Oct 31, 2014 at 11:35 PM, Rick Mann <rm...@la...> wrote:
> Must I always connect every pin? How do I specify a pin as "not connected" in a part instance? Thanks!
> 
> I'd like to compile my code as I go, but if I have to connect every pin, it can make it impractical to work incrementally.
> 
> --
> Rick Mann
> rm...@la...
> 
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> phdl-devel mailing list
> phd...@li...
> https://lists.sourceforge.net/lists/listinfo/phdl-devel
> 


-- 
Rick Mann
rm...@la...

Re: [phdl-devel] Any way to ignore ERROR:Unassigned pin?

[Rick M. <rm...@la...>]

Thanks, I'll try that. I'm using the 2.1 jar I downloaded. It's a bit confusing, as that site seems to be deprecated, and the new github source seems to be C++? Very hard to figure out. I was excited by the translator functionality (now I can get that Osmond support I've always wanted ;-) ).

$ java -jar phdlcomp.jar
0    INFO  PhdlCompile        - PHDL Compiler v2.1, September 26, 2012 build.


> On Nov 4, 2014, at 13:05 , Brad R <bra...@gm...> wrote:
> 
> By the way, what version are you using?
> 
> On Fri, Oct 31, 2014 at 11:35 PM, Rick Mann <rm...@la...> wrote:
> Must I always connect every pin? How do I specify a pin as "not connected" in a part instance? Thanks!
> 
> I'd like to compile my code as I go, but if I have to connect every pin, it can make it impractical to work incrementally.
> 
> --
> Rick Mann
> rm...@la...
> 
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> phdl-devel mailing list
> phd...@li...
> https://lists.sourceforge.net/lists/listinfo/phdl-devel
> 


-- 
Rick Mann
rm...@la...

[phdl-devel] Any way to ignore ERROR:Unassigned pin?

[Rick M. <rm...@la...>]

Must I always connect every pin? How do I specify a pin as "not connected" in a part instance? Thanks!

I'd like to compile my code as I go, but if I have to connect every pin, it can make it impractical to work incrementally.

-- 
Rick Mann
rm...@la...

Re: [phdl-devel] [EXTERNAL] Re: PHDL 2.1 question

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

Josh,

 

Thanks for the reply.  I really dislike Altium.  It is the way everything is integrated and not modular.  Also, recent versions are becoming like social media or something where your every mouse click is reported to an on-line account.  Knowledgeable users can probably get around that stuff but for the new learner it is really annoying.  It looks like you have to pay, pay, pay forever to retain access to your own intellectual property.

 

On the other hand, KiCad looks like it has real potential.  The open netlist format is easy to write.  CERN recently adopted KiCad as its standard open hardware platform.  Maybe I should do the same.

 

Au revoir,

 

                Pete

 

From: Joshua Mangelson [mailto:jos...@gm...] 
Sent: Tuesday, May 20, 2014 3:53 PM
To: Peter Dudley
Cc: <phd...@li...>
Subject: Re: [phdl-devel] [EXTERNAL] Re: PHDL 2.1 question

 

Hey Guys,

 

Its been a while since I've said anything, but I still get all of the email updates and read through them every now and then.

 

I just wanted to let you know that I looked into getting PHDL to work with Altium pretty extensively about a year ago. 

Altium actually doesn't use a netlist at all. The layout editor actually has access to all of the information contained in the original schematic and acts directly on that data rather than using a netlist as an intermediary. 

 

I looked into trying to import a netlist in another tool's netlist format but I don't think Altium has that as an option. I then looked into possibly writing a back end that generates a basic Altium schematic from a PHDL design, but it would be quite a bit more complex than the generator we have for PADS or Eagle. Its been a year or two since I worked on it, but If you have any questions let me know and I would be happy to try and help. I can't remember exactly how far I got. In the end we needed a board made sooner than it would take to write the backend, so we put the project on hold.

 

Let me know if there is anything I can help with.

 

Altium is quite a bit bigger than PADS however, and has some features that make it easier than many other schematic capture programs. It is still a schematic editor but if you had to use one, I would suggest Altium.

 

Joshua Mangelson

Brigham Young University

 

 

 

 

On Sat, May 17, 2014 at 5:55 AM, Peter Dudley <hd...@ho...> wrote:

Chuck, Wes,

Thanks for the help.  I was able to complete my design using PHDL but it
looks like the board is not going to be produced.

It contains a Xilinx Kintex part.  Originally I compiled it with Vivado but
I found that they dramatically changed the pin-out CSV format. They removed
or changed many of the entries I used to parse into the PHDL device
definition format.  Luckily, ISE 14.7 still works for 7-Series parts and
produces the CSV file in a format compatible with phdl_utils.Xilinx2PHDL.

Anyway, in my day job, it looks like I will be required to learn yet another
clickity-click EDA tool, Altium.  When I get a chance I will poke around in
there to see if I can generate the a netlist from PHDL in the Altium netlist
format.  I see that PHDL can generate an XML netlist. I have not
investigated that but if it is complete I could probably use that to
generate the Altium netlist.  There is also the PHDLTrans API though I have
not looked at that.

        Pete


-----Original Message-----
From: Graham, Charles W [mailto:cw...@sa...]
Sent: Monday, May 05, 2014 2:31 PM
To: Wesley J. Landaker; phd...@li...
Cc: Peter Dudley

Subject: Re: [phdl-devel] [EXTERNAL] Re: PHDL 2.1 question

Pete,

Wes is correct. In version 2.1 you use attr versus using newattr in version
1. So your part instance would look something like:
 inst my_part of part {
        attr REFDES = "...";
        ...
  }

Another way of doing it would be to create a blank REFDES attribute in the
device declaration and overwrite it in each part instance where you wanted
to control it:

device part {
       attr REFDES = "";
      ...
}

inst my_part of part {
        REFDES = "...";
        ...
  }

Unfortunately there doesn't seem to be a good way of automating refdes
assignments if you wanted to prevent the compiler from reassigning them each
time unless you manually constrain them.

Good luck with your board design!

Thanks,
Chuck

Charles W. Graham
Sandia National Laboratories
Embedded Signal Processors
MS-0503 Dept. 5339
P.O. Box 5800
Albuquerque, NM 87185
USA
Phone: (505) 284-8019
E-mail: cw...@sa...

-----Original Message-----
From: Wesley J. Landaker [mailto:wj...@ic...]
Sent: Sunday, May 04, 2014 12:01 PM
To: phd...@li...
Cc: Peter Dudley
Subject: [EXTERNAL] Re: [phdl-devel] PHDL 2.1 question

On Sunday, May 04, 2014 09:09:00 Peter Dudley wrote:
> Hello Guys,
>
> I am starting a new board design with PHDL.  I thought I would use
> version
> 2.1 since it is the latest and most popular version.
>
> Unfortunately,  I do not find any instructions in the tutorial about
> how to control REFDES assignments in the source HDL.  It seems to work
> fine if I let the compiler assign all the REFDES but I get an error
> when I try to add the REFDES attribute assignment or add REFPREFIX
> attributes to a subinst.

This might be an issue where you have to use "newattr" instead of "attr" or
vice-versa (the difference was well intentioned, but is a little wacky the
way it currently behaves).

If neither of those work let me know and I can look more closely in the PHDL
2.1 code.
----------------------------------------------------------------------------
--
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:

• 3 signs your SCM is hindering your productivity • Requirements
for releasing software faster • Expert tips and advice for migrating

your SCM now http://p.sf.net/sfu/perforce
_______________________________________________
phdl-devel mailing list
phd...@li...
https://lists.sourceforge.net/lists/listinfo/phdl-devel



------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs

_______________________________________________
phdl-devel mailing list
phd...@li...
https://lists.sourceforge.net/lists/listinfo/phdl-devel

 

Re: [phdl-devel] [EXTERNAL] Re: PHDL 2.1 question

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

Hey Guys,

Its been a while since I've said anything, but I still get all of the email
updates and read through them every now and then.

I just wanted to let you know that I looked into getting PHDL to work with
Altium pretty extensively about a year ago.
Altium actually doesn't use a netlist at all. The layout editor actually
has access to all of the information contained in the original schematic
and acts directly on that data rather than using a netlist as an
intermediary.

I looked into trying to import a netlist in another tool's netlist format
but I don't think Altium has that as an option. I then looked into possibly
writing a back end that generates a basic Altium schematic from a PHDL
design, but it would be quite a bit more complex than the generator we have
for PADS or Eagle. Its been a year or two since I worked on it, but If you
have any questions let me know and I would be happy to try and help. I
can't remember exactly how far I got. In the end we needed a board made
sooner than it would take to write the backend, so we put the project on
hold.

Let me know if there is anything I can help with.

Altium is quite a bit bigger than PADS however, and has some features that
make it easier than many other schematic capture programs. It is still a
schematic editor but if you had to use one, I would suggest Altium.

Joshua Mangelson
Brigham Young University





On Sat, May 17, 2014 at 5:55 AM, Peter Dudley <hd...@ho...> wrote:

> Chuck, Wes,
>
> Thanks for the help.  I was able to complete my design using PHDL but it
> looks like the board is not going to be produced.
>
> It contains a Xilinx Kintex part.  Originally I compiled it with Vivado but
> I found that they dramatically changed the pin-out CSV format. They removed
> or changed many of the entries I used to parse into the PHDL device
> definition format.  Luckily, ISE 14.7 still works for 7-Series parts and
> produces the CSV file in a format compatible with phdl_utils.Xilinx2PHDL.
>
> Anyway, in my day job, it looks like I will be required to learn yet
> another
> clickity-click EDA tool, Altium.  When I get a chance I will poke around in
> there to see if I can generate the a netlist from PHDL in the Altium
> netlist
> format.  I see that PHDL can generate an XML netlist. I have not
> investigated that but if it is complete I could probably use that to
> generate the Altium netlist.  There is also the PHDLTrans API though I have
> not looked at that.
>
>         Pete
>
> -----Original Message-----
> From: Graham, Charles W [mailto:cw...@sa...]
> Sent: Monday, May 05, 2014 2:31 PM
> To: Wesley J. Landaker; phd...@li...
> Cc: Peter Dudley
> Subject: Re: [phdl-devel] [EXTERNAL] Re: PHDL 2.1 question
>
> Pete,
>
> Wes is correct. In version 2.1 you use attr versus using newattr in version
> 1. So your part instance would look something like:
>  inst my_part of part {
>         attr REFDES = "...";
>         ...
>   }
>
> Another way of doing it would be to create a blank REFDES attribute in the
> device declaration and overwrite it in each part instance where you wanted
> to control it:
>
> device part {
>        attr REFDES = "";
>       ...
> }
>
> inst my_part of part {
>         REFDES = "...";
>         ...
>   }
>
> Unfortunately there doesn't seem to be a good way of automating refdes
> assignments if you wanted to prevent the compiler from reassigning them
> each
> time unless you manually constrain them.
>
> Good luck with your board design!
>
> Thanks,
> Chuck
>
> Charles W. Graham
> Sandia National Laboratories
> Embedded Signal Processors
> MS-0503 Dept. 5339
> P.O. Box 5800
> Albuquerque, NM 87185
> USA
> Phone: (505) 284-8019
> E-mail: cw...@sa...
>
> -----Original Message-----
> From: Wesley J. Landaker [mailto:wj...@ic...]
> Sent: Sunday, May 04, 2014 12:01 PM
> To: phd...@li...
> Cc: Peter Dudley
> Subject: [EXTERNAL] Re: [phdl-devel] PHDL 2.1 question
>
> On Sunday, May 04, 2014 09:09:00 Peter Dudley wrote:
> > Hello Guys,
> >
> > I am starting a new board design with PHDL.  I thought I would use
> > version
> > 2.1 since it is the latest and most popular version.
> >
> > Unfortunately,  I do not find any instructions in the tutorial about
> > how to control REFDES assignments in the source HDL.  It seems to work
> > fine if I let the compiler assign all the REFDES but I get an error
> > when I try to add the REFDES attribute assignment or add REFPREFIX
> > attributes to a subinst.
>
> This might be an issue where you have to use "newattr" instead of "attr" or
> vice-versa (the difference was well intentioned, but is a little wacky the
> way it currently behaves).
>
> If neither of those work let me know and I can look more closely in the
> PHDL
> 2.1 code.
>
> ----------------------------------------------------------------------------
> --
> Is your legacy SCM system holding you back? Join Perforce May 7 to find
> out:
> • 3 signs your SCM is hindering your productivity • Requirements
> for releasing software faster • Expert tips and advice for migrating
> your SCM now http://p.sf.net/sfu/perforce
> _______________________________________________
> phdl-devel mailing list
> phd...@li...
> https://lists.sourceforge.net/lists/listinfo/phdl-devel
>
>
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing platform
> available
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> phdl-devel mailing list
> phd...@li...
> https://lists.sourceforge.net/lists/listinfo/phdl-devel
>

Re: [phdl-devel] [EXTERNAL] Re: PHDL 2.1 question

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

Chuck, Wes,

Thanks for the help.  I was able to complete my design using PHDL but it
looks like the board is not going to be produced.

It contains a Xilinx Kintex part.  Originally I compiled it with Vivado but
I found that they dramatically changed the pin-out CSV format. They removed
or changed many of the entries I used to parse into the PHDL device
definition format.  Luckily, ISE 14.7 still works for 7-Series parts and
produces the CSV file in a format compatible with phdl_utils.Xilinx2PHDL.

Anyway, in my day job, it looks like I will be required to learn yet another
clickity-click EDA tool, Altium.  When I get a chance I will poke around in
there to see if I can generate the a netlist from PHDL in the Altium netlist
format.  I see that PHDL can generate an XML netlist. I have not
investigated that but if it is complete I could probably use that to
generate the Altium netlist.  There is also the PHDLTrans API though I have
not looked at that.

	Pete

-----Original Message-----
From: Graham, Charles W [mailto:cw...@sa...] 
Sent: Monday, May 05, 2014 2:31 PM
To: Wesley J. Landaker; phd...@li...
Cc: Peter Dudley
Subject: Re: [phdl-devel] [EXTERNAL] Re: PHDL 2.1 question

Pete,

Wes is correct. In version 2.1 you use attr versus using newattr in version
1. So your part instance would look something like:
 inst my_part of part {
        attr REFDES = "...";
        ...
  } 

Another way of doing it would be to create a blank REFDES attribute in the
device declaration and overwrite it in each part instance where you wanted
to control it:

device part {
       attr REFDES = "";
      ...
}

inst my_part of part {
        REFDES = "...";
        ...
  }  

Unfortunately there doesn't seem to be a good way of automating refdes
assignments if you wanted to prevent the compiler from reassigning them each
time unless you manually constrain them.

Good luck with your board design!

Thanks,
Chuck

Charles W. Graham
Sandia National Laboratories
Embedded Signal Processors
MS-0503 Dept. 5339
P.O. Box 5800
Albuquerque, NM 87185
USA
Phone: (505) 284-8019
E-mail: cw...@sa... 

-----Original Message-----
From: Wesley J. Landaker [mailto:wj...@ic...]
Sent: Sunday, May 04, 2014 12:01 PM
To: phd...@li...
Cc: Peter Dudley
Subject: [EXTERNAL] Re: [phdl-devel] PHDL 2.1 question

On Sunday, May 04, 2014 09:09:00 Peter Dudley wrote:
> Hello Guys,
> 
> I am starting a new board design with PHDL.  I thought I would use 
> version
> 2.1 since it is the latest and most popular version.
> 
> Unfortunately,  I do not find any instructions in the tutorial about 
> how to control REFDES assignments in the source HDL.  It seems to work 
> fine if I let the compiler assign all the REFDES but I get an error 
> when I try to add the REFDES attribute assignment or add REFPREFIX 
> attributes to a subinst.

This might be an issue where you have to use "newattr" instead of "attr" or
vice-versa (the difference was well intentioned, but is a little wacky the
way it currently behaves).

If neither of those work let me know and I can look more closely in the PHDL
2.1 code.
----------------------------------------------------------------------------
--
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
• 3 signs your SCM is hindering your productivity • Requirements
for releasing software faster • Expert tips and advice for migrating
your SCM now http://p.sf.net/sfu/perforce
_______________________________________________
phdl-devel mailing list
phd...@li...
https://lists.sourceforge.net/lists/listinfo/phdl-devel

Re: [phdl-devel] [EXTERNAL] Re: PHDL 2.1 question

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

 OK, thanks for the clarification.  I think we still need some more updated example code.
 
If this project is a go I will try to get the customer to share the design on the website.  I think that might be possible for this project.
 
    Pete
 
> From: cw...@sa...
> To: wj...@ic...; phd...@li...
> CC: hd...@ho...
> Subject: RE: [EXTERNAL] Re: [phdl-devel] PHDL 2.1 question
> Date: Mon, 5 May 2014 18:30:33 +0000
> 
> Pete,
> 
> Wes is correct. In version 2.1 you use attr versus using newattr in version 1. So your part instance would look something like:
>  inst my_part of part {
>         attr REFDES = "...";
>         ...
>   } 
> 
> Another way of doing it would be to create a blank REFDES attribute in the device declaration and overwrite it in each part instance where you wanted to control it:
> 
> device part {
>        attr REFDES = "";
>       ...
> }
> 
> inst my_part of part {
>         REFDES = "...";
>         ...
>   }  
> 
> Unfortunately there doesn't seem to be a good way of automating refdes assignments if you wanted to prevent the compiler from reassigning them each time unless you manually constrain them.
> 
> Good luck with your board design!
> 
> Thanks,
> Chuck
> 
> Charles W. Graham 
> Sandia National Laboratories 
> Embedded Signal Processors 
> MS-0503 Dept. 5339 
> P.O. Box 5800 
> Albuquerque, NM 87185 
> USA 
> Phone: (505) 284-8019 
> E-mail: cw...@sa... 
> 
> -----Original Message-----
> From: Wesley J. Landaker [mailto:wj...@ic...] 
> Sent: Sunday, May 04, 2014 12:01 PM
> To: phd...@li...
> Cc: Peter Dudley
> Subject: [EXTERNAL] Re: [phdl-devel] PHDL 2.1 question
> 
> On Sunday, May 04, 2014 09:09:00 Peter Dudley wrote:
> > Hello Guys,
> > 
> > I am starting a new board design with PHDL.  I thought I would use 
> > version
> > 2.1 since it is the latest and most popular version.
> > 
> > Unfortunately,  I do not find any instructions in the tutorial about 
> > how to control REFDES assignments in the source HDL.  It seems to work 
> > fine if I let the compiler assign all the REFDES but I get an error 
> > when I try to add the REFDES attribute assignment or add REFPREFIX 
> > attributes to a subinst.
> 
> This might be an issue where you have to use "newattr" instead of "attr" or vice-versa (the difference was well intentioned, but is a little wacky the way it currently behaves).
> 
> If neither of those work let me know and I can look more closely in the PHDL
> 2.1 code.
 		 	   		  

Re: [phdl-devel] [EXTERNAL] Re: PHDL 2.1 question

[Graham, C. W <cw...@sa...>]

Pete,

Wes is correct. In version 2.1 you use attr versus using newattr in version 1. So your part instance would look something like:
 inst my_part of part {
        attr REFDES = "...";
        ...
  } 

Another way of doing it would be to create a blank REFDES attribute in the device declaration and overwrite it in each part instance where you wanted to control it:

device part {
       attr REFDES = "";
      ...
}

inst my_part of part {
        REFDES = "...";
        ...
  }  

Unfortunately there doesn't seem to be a good way of automating refdes assignments if you wanted to prevent the compiler from reassigning them each time unless you manually constrain them.

Good luck with your board design!

Thanks,
Chuck

Charles W. Graham 
Sandia National Laboratories 
Embedded Signal Processors 
MS-0503 Dept. 5339 
P.O. Box 5800 
Albuquerque, NM 87185 
USA 
Phone: (505) 284-8019 
E-mail: cw...@sa... 

-----Original Message-----
From: Wesley J. Landaker [mailto:wj...@ic...] 
Sent: Sunday, May 04, 2014 12:01 PM
To: phd...@li...
Cc: Peter Dudley
Subject: [EXTERNAL] Re: [phdl-devel] PHDL 2.1 question

On Sunday, May 04, 2014 09:09:00 Peter Dudley wrote:
> Hello Guys,
> 
> I am starting a new board design with PHDL.  I thought I would use 
> version
> 2.1 since it is the latest and most popular version.
> 
> Unfortunately,  I do not find any instructions in the tutorial about 
> how to control REFDES assignments in the source HDL.  It seems to work 
> fine if I let the compiler assign all the REFDES but I get an error 
> when I try to add the REFDES attribute assignment or add REFPREFIX 
> attributes to a subinst.

This might be an issue where you have to use "newattr" instead of "attr" or vice-versa (the difference was well intentioned, but is a little wacky the way it currently behaves).

If neither of those work let me know and I can look more closely in the PHDL
2.1 code.

Re: [phdl-devel] PHDL 2.1 question

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

On Sunday, May 04, 2014 09:09:00 Peter Dudley wrote:
> Hello Guys,
> 
> I am starting a new board design with PHDL.  I thought I would use version
> 2.1 since it is the latest and most popular version.
> 
> Unfortunately,  I do not find any instructions in the tutorial about how
> to control REFDES assignments in the source HDL.  It seems to work fine
> if I let the compiler assign all the REFDES but I get an error when I try
> to add the REFDES attribute assignment or add REFPREFIX attributes to a
> subinst.

This might be an issue where you have to use "newattr" instead of "attr" or 
vice-versa (the difference was well intentioned, but is a little wacky the 
way it currently behaves).

If neither of those work let me know and I can look more closely in the PHDL 
2.1 code.

[phdl-devel] PHDL 2.1 question

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

Hello Guys,

I am starting a new board design with PHDL.  I thought I would use version
2.1 since it is the latest and most popular version.

Unfortunately,  I do not find any instructions in the tutorial about how to
control REFDES assignments in the source HDL.  It seems to work fine if I
let the compiler assign all the REFDES but I get an error when I try to add
the REFDES attribute assignment or add REFPREFIX attributes to a subinst.

What is the current state of REFDES control in PHDL 2.1?

Thanks,

     Pete 

[phdl-devel] Attribute types used by PCB tools

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

In one of my recent posts, I wrote about attribute values being extended 
from just strings to a variant data type:

On Saturday, January 25, 2014 10:42:30 Wesley J. Landaker wrote:
> 	Value ::= CHOICE {
> 		null    NULL,
> 		bool    BOOLEAN,
> 		number  INTEGER,
> 		string  UTF8String,
> 		bytes   OCTET STRING
> 	}

I wrote this kind of "just for example" when I converted this to ASN.1 -- 
we've always talked about attributes as only string-valued. I think that 
should work fine, and it's probably what we want to go with here unless 
there is a reason to do otherwise.

Does anyone know how PCB tools actually treat attributes? From what I've 
seen, they always treat them as strings (even for numerical things like 
resistor values, I believe they are still treated textually). Does anyone 
know of a counter-example?

Re: [phdl-devel] PHDLIF suggestion for connection

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

On Sunday, January 26, 2014 14:09:37 Peter Dudley wrote:
> OK, That brings up another sticky issue.
> 
> Where will you put the Reference Designator information?  The refdes
> breaks the model of normal hierarchical naming because it has to be very
> short and is often sequenced without regard to hierarchy of the design. 
> Also, layout netlists normally don't even want to see the hierarchical
> name of an instance, just the refdes.
> 
> I assume it will be an attribute in your Instance type.
> 
> 	Instance ::= SEQUENCE {
> 		name        Name,
> 		attributes  Attributes,
> 		device      Name
> 	}

Yes, I wanted the reference designator (refdes) to be stored in an instance 
attribute instead of being a structural part of PHDLIF because it allows 
several forward and backward refdes annotation workflows which we've either 
agreed in the past are desirable, or I have heard in the meantime are the 
way people wish things worked.

Here are some examples:

*---

Scenario #1: (No refdes annotation) The user does not specify any refdes and 
doesn't care what they are in the end.

The user's original PHDL doesn't contain any refdes attributes, but might 
contain refdes_prefix attributes in some devices. The refdes handler (a 
standard backend step we'll provide) will generate "traditional" sequential 
refdes attributes using refdes_prefix. (If there were refdes_prefix 
attributes on subdesigns, then we'll get our "newfangled" refdes', but 
otherwise everything else is the same). Automatically assigned refdes will 
be in some random order, but will be slightly smart about assigning 
sequential numbers to instances in the same level of hierarchy, etc.

*---

Scenario #2: (Backward refdes annotation) The user does not specify any 
refdes, but needs to know what 
they are (for debugging, etc).

Everything proceeds just like the first scenario. But now, the user re-runs 
PHDL pointing at the PHDLIF output from the refdes assignment pass, 
resulting in their original PHDL code being back-annotated with the assigned 
refdes.

*---

Scenario #3: (Forward refdes annotation) The user wants to directly specify 
all refdes assignments.

The user sets every single refdes attribute for everything by hand. 
Sometimes for small designs this actually lets the user do clever things 
easily.

*---

Scenario #4: (Bidirectional refdes annotation) The user does not originally 
specific any refdes, but needs to be able to tweak them after initial 
assignment.

Everything is just like scenario #2, but now once the user has back-
annotated PHDL, they can just directly edit the refdes attributes and run 
PHDL in a forward pass like in scenario #3.

*---

Scenario #5: (Bidirectional partial forward-, partial backward- annotation) 
[aka Real Life]. The user needs to specify some refdes directly, doesn't 
care about most of them, but wants to know what got assigned and maybe tweak 
them after the fact.

This is a combo of all of the above scenarios, is more like what happens in 
real life, and is easily supportable with refdes as optional (to the user) 
attributes plus an automatic refdes assignment pass and a back-annotation 
mode from PHDL(partially annotated)+PHDLIF(annotated) => PHDL(annotated).

Re: [phdl-devel] Device Attributes

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

I vote for FOOTPRINT for the physical layout shape to be associated with the part.

Other terms I have seen are PKG_TYPE (Mentor DxDesigner) and DECAL. 

-----Original Message-----
From: Wesley J. Landaker [mailto:wj...@ic...] 
Sent: Sunday, January 26, 2014 1:56 PM
To: phd...@li...
Cc: Peter Dudley
Subject: Device Attributes

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.

Re: [phdl-devel] PHDLIF suggestion for connection

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

OK, That brings up another sticky issue.

Where will you put the Reference Designator information?  The refdes breaks the model of normal hierarchical naming because it has to be very short and is often sequenced without regard to hierarchy of the design.  Also, layout netlists normally don't even want to see the hierarchical name of an instance, just the refdes.

I assume it will be an attribute in your Instance type.

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

-----Original Message-----
From: Wesley J. Landaker [mailto:wj...@ic...] 
Sent: Sunday, January 26, 2014 12:42 PM
To: phd...@li...
Cc: Peter Dudley
Subject: Re: [phdl-devel] PHDLIF suggestion for connection

On Sunday, January 26, 2014 09:43:28 Peter Dudley wrote:
> That looks very good.

Thanks for taking the time to look at it. 

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

I agree this is the right way to do it. I think this is already in there with what I've proposed, so let me walk through what I have in the design so it's clear what I'm thinking:

This distinction I've made in the proposed format between a "Net" and a "Connection". A "Net" is the wire or trace itself, which can connect a whole bunch of pins of various instances together. A "Connection" is one particular endpoint, and refers to a specific pin on a specific instance. 
Then a "Net" is basically just composed of a bunch of "Connections".

Here is what I posted with extra commentary:

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

As you can see above, a "Net" has a name. Obviously the original PHDL design could have had all sorts of aliases for a Net, especially when hierarchy is involved, in which case one of them will be picked to use here, hopefully somewhat intelligently. So this name is what backends that don't support net aliases should use as the basis for net name in whatever native format they are spitting out. It has attributes, which we'll ignore for the moment although they can contain potentially useful stuff, but it's not structural. 
And then it has a list of "Connection"s. Let's look at how I defined a
"Connection":

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

Like a "Net", a "Connection" has a name. This is one of the net's aliases, and specifically, it is the local name of the net right at the point where it is connected to an instance's pin. For backends that don't support net aliases, this can just be ignored, or spit out as a comment or something. 
Attributes again we can ignore for the moment. The instance field is just the name of the instance from the Device's "instances" section. The actual refdes used for "traditional" netlisting would probably not be this name itself, but it would be looked up in an the instance's "refdes" attribute (exact attribute names are TBD) attribute. The pin field here is also a name, which corresponds to a pin name in the device definition of the instance we've just looked up.

To illustrate this further, if you were writing a netlister and had everything in nice memory structures already, you'd do something like this
pseudo-code:

for net in design.nets: 
	printf("net %s:", net.name)
	for connection in net.connections:
		name          = connection.instance
		refdes        = design.instances[name].attributes["refdes"]
		pin_name      = connection.pin
		printf(" %s.%s", refdes, pin_name); // PADS-like
		printf(" (%s, %s)", refdes, pin_name); // KiCAD-like

I think this should cover pretty much all use-cases, but I appreciate the feedback if you think I'm overlooking something.

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

Re: [phdl-devel] PHDLIF suggestion for connection

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

On Sunday, January 26, 2014 09:43:28 Peter Dudley wrote:
> That looks very good.

Thanks for taking the time to look at it. 

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

I agree this is the right way to do it. I think this is already in there 
with what I've proposed, so let me walk through what I have in the design so 
it's clear what I'm thinking:

This distinction I've made in the proposed format between a "Net" and a 
"Connection". A "Net" is the wire or trace itself, which can connect a whole 
bunch of pins of various instances together. A "Connection" is one 
particular endpoint, and refers to a specific pin on a specific instance. 
Then a "Net" is basically just composed of a bunch of "Connections".

Here is what I posted with extra commentary:

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

As you can see above, a "Net" has a name. Obviously the original PHDL design 
could have had all sorts of aliases for a Net, especially when hierarchy is 
involved, in which case one of them will be picked to use here, hopefully 
somewhat intelligently. So this name is what backends that don't support net 
aliases should use as the basis for net name in whatever native format they 
are spitting out. It has attributes, which we'll ignore for the moment 
although they can contain potentially useful stuff, but it's not structural. 
And then it has a list of "Connection"s. Let's look at how I defined a 
"Connection":

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

Like a "Net", a "Connection" has a name. This is one of the net's aliases, 
and specifically, it is the local name of the net right at the point where 
it is connected to an instance's pin. For backends that don't support net 
aliases, this can just be ignored, or spit out as a comment or something. 
Attributes again we can ignore for the moment. The instance field is just 
the name of the instance from the Device's "instances" section. The actual 
refdes used for "traditional" netlisting would probably not be this name 
itself, but it would be looked up in an the instance's "refdes" attribute 
(exact attribute names are TBD) attribute. The pin field here is also a 
name, which corresponds to a pin name in the device definition of the 
instance we've just looked up.

To illustrate this further, if you were writing a netlister and had 
everything in nice memory structures already, you'd do something like this 
pseudo-code:

for net in design.nets: 
	printf("net %s:", net.name)
	for connection in net.connections:
		name          = connection.instance
		refdes        = design.instances[name].attributes["refdes"]
		pin_name      = connection.pin
		printf(" %s.%s", refdes, pin_name); // PADS-like
		printf(" (%s, %s)", refdes, pin_name); // KiCAD-like

I think this should cover pretty much all use-cases, but I appreciate the 
feedback if you think I'm overlooking something.