phdl-devel — PHDL General Development Discussion

Re: [phdl-devel] (no subject)

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

We are in agreement with Pete and our work going forward is in PADS…

Brent Nelson



From: Peter Dudley <hd...@ho...<mailto:hd...@ho...>>
Date: Monday, December 31, 2012 10:39 AM
To: 'phdl-devel' <phd...@li...<mailto:phd...@li...>>
Subject: Re: [phdl-devel] (no subject)

Hello Guys,

We spent the holidays down in Grenoble, France.  Grenoble is a spectacular city and much more fun than Geneva, Switzerland where we are currently living.

Anyway, I totally agree with Vitaly.  The standard DxD-Expedition flow does not allow an intermediate net-list input option.  The purpose of that tool is to totally control the customer from concept through production.  This approach is not designed to help the customer but to lock us into their flow, forever.

I really feel that if the layout tool does not have a published net-list format that we probably do not want to mess with it.  Mentor PADS is Mentor’s open tool.  Almost any schematic tool can work with PADS. Also, almost any competing layout tool can read PADS netlist format.  Also, almost all competing layout tools have translators to read in a complete PADS board layout.  For all these reasons targeting PADS Layout is probably still a very good idea. In effect, by supporting PADS we also support all other board layout tools on the market.

I know the BYU guys started out with Eagle but perhaps it would be worthwhile to come up to speed on PADS over there.  PADS has some quirky stuff but I know all the tricks and can help if you run into problems.  Also, the router that comes with PADS is pretty good.

A solid PADS net-list is  probably the best thing we can generate.

  Pete


From: av...@ma...<mailto:av...@ma...> [mailto:av...@ma...]
Sent: Sunday, December 30, 2012 8:33 AM
To: phdl-devel
Subject: [phdl-devel] (no subject)

Hello ALL!

> Do you guys know if there are any other tools out there that might have discontinued the use of a seperate netlist as the intermediate format?

Yes. This is Mentor DxD-Expedition iCDB flow.
Mentor supports netlist flow too, but in case of iCDB netlist is not created.

But i think this is not right way. This merges two views of design (logical and physical) into one tool. And this prevents us to manipulate these views.

Look on Cadence SCM. This is very good example of logical non-schematic desgin with PCB support. It has many useful features that PHDL can also implement, such associated components and terminations.

Good luck and happy new year!
---
Vitaly

Re: [phdl-devel] (no subject)

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

Hello Guys,

 

We spent the holidays down in Grenoble, France.  Grenoble is a spectacular city and much more fun than Geneva, Switzerland where we are currently living.

 

Anyway, I totally agree with Vitaly.  The standard DxD-Expedition flow does not allow an intermediate net-list input option.  The purpose of that tool is to totally control the customer from concept through production.  This approach is not designed to help the customer but to lock us into their flow, forever.

 

I really feel that if the layout tool does not have a published net-list format that we probably do not want to mess with it.  Mentor PADS is Mentor’s open tool.  Almost any schematic tool can work with PADS. Also, almost any competing layout tool can read PADS netlist format.  Also, almost all competing layout tools have translators to read in a complete PADS board layout.  For all these reasons targeting PADS Layout is probably still a very good idea. In effect, by supporting PADS we also support all other board layout tools on the market.

 

I know the BYU guys started out with Eagle but perhaps it would be worthwhile to come up to speed on PADS over there.  PADS has some quirky stuff but I know all the tricks and can help if you run into problems.  Also, the router that comes with PADS is pretty good.

 

A solid PADS net-list is  probably the best thing we can generate.

 

  Pete

 

 

From: av...@ma... [mailto:av...@ma...] 
Sent: Sunday, December 30, 2012 8:33 AM
To: phdl-devel
Subject: [phdl-devel] (no subject)

 

Hello ALL!

> Do you guys know if there are any other tools out there that might have discontinued the use of a seperate netlist as the intermediate format?

Yes. This is Mentor DxD-Expedition iCDB flow.
Mentor supports netlist flow too, but in case of iCDB netlist is not created.

But i think this is not right way. This merges two views of design (logical and physical) into one tool. And this prevents us to manipulate these views.

Look on Cadence SCM. This is very good example of logical non-schematic desgin with PCB support. It has many useful features that PHDL can also implement, such associated components and terminations.

Good luck and happy new year!
---
Vitaly

[phdl-devel] (no subject)

[<av...@ma...>]

 Hello ALL!

> Do you guys know if there are any other tools out there that might have discontinued the use of a seperate netlist as the intermediate format?

Yes. This is Mentor DxD-Expedition iCDB flow.
Mentor supports netlist flow too, but in case of iCDB netlist is not created.

But i think this is not right way. This merges two views of design (logical and physical) into one tool. And this prevents us to manipulate these views.

Look on Cadence SCM. This is very good example of logical non-schematic desgin with PCB support. It has many useful features that PHDL can also implement, such associated components and terminations.

Good luck and happy new year!
---
Vitaly

[phdl-devel] Altium Designer

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

Hey Everybody,

Here at BYU we've been looking into Altium quite a bit and working on
seeing if it were possible to integrate it into PHDL. And we just wanted to
let you know what we've found.

The main thing I've been focusing on however is trying to figure out a
format that we can output from the PHDL compiler which can then be imported
into Altium. However, unlike Eagle or PADS, Altium doesn't allow for the
import of a netlist alone. The linking between the schematic document and
pcb document in the editor is done directly without the intermediate
netlist. Because of this it only allows importing  of the schematic
documents or pcb documents.

The schematic documents are more complicated than the netlist because they
also contain all of the information required to create a schematic symbol,
and thus must include the library information for each individual part.
Similarly the pcb document also must contain the library information needed
for each individual footprint, as well as information about each individual
layer on the board.

Because of this additional complexity it will be a bit more complicated
than it was for PADS or Eagle.
It might be possible to create schematic symbol libraries from our PHDL
device declarations, though.

Also, Altium allows scripting to be used when generating schematic or PCB
documents, so I'm looking into that as well. However using scripting to
create the documents would probably require the symbols(for schematics) and
the footprints(for PCBs) to already present in the Altium libraries, so in
this case I think it would be more practical to look into generating a PCB
layout document since we already would have to create footprints for the
parts anyway.

Because of this increase in complexity we're going to stick with PADS for
the time being, but the main thing we wanted to point out is that Altium
doesn't actually use the netlist as the midway point between schematic and
PCB. Do you guys know if there are any other tools out there that might
have discontinued the use of a seperate netlist as the intermediate format?

Hope your having a great christmas vacation,

Joshua

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

I haven't thought through it completely, but my first impression is that 
your idea is a good one. The current syntax is flexible, but also can be 
overly confusing.

I am totally in crunch mode at work and then will be in vacation mode 
for a couple weeks, but I plan to spin back up on PHDL stuff in January. =)

Re: [phdl-devel] Importing into Altium

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

Josh

Yes, I was able to get PADS to accept my .asc file from PHDL.  You can find that work here phdl-code/doc/refdesign within the git repository.

I did not use a .p file because phdl did not create that yet.  I had to create the device/footprint associations by hand in the PADS library manager.

I will output a .p file for that design in case it would be helpful to you.  The outputted .p file has some extra stuff in it but might be helpful.

    Pete

Date: Mon, 3 Dec 2012 18:21:07 -0700
From: jos...@gm...
To: phd...@li...
Subject: [phdl-devel] Importing into Altium

Hey Everybody,
I'm working on trying to get a design imported into Altium.
Altium however doesn't have an independent netlist format. I've been trying to get it to import a PADS netlist.

Pete, were you able to get PADS to accept your .asc file and a .p file?
Thanks,
Josh

------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
phdl-devel mailing list
phd...@li...
https://lists.sourceforge.net/lists/listinfo/phdl-devel 		 	   		  

[phdl-devel] Importing into Altium

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

Hey Everybody,

I'm working on trying to get a design imported into Altium.

Altium however doesn't have an independent netlist format. I've been trying
to get it to import a PADS netlist.

Pete, were you able to get PADS to accept your .asc file and a .p file?

Thanks,

Josh

Re: [phdl-devel] .p file info

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

Josh,

 

It is great to see so much going on over there. 

 

As far as an attribute for the device name I don't think we want to
introduce anything PADS specific.  One of the powerful ideas behind PHDL is
that you can write your design once and then output to a variety of back end
netlist formats.  If we start adding different attributes like
PADS_DEVICE_NAME and ALTIUM_PART_NUMBER our source code is not portable.  I
think  we want to come up with a superset of a few attributes that will
cover all layout backend tools.

 

If I were starting now from scratch I would suggest the following system.

 

    device CUI_2.5mm_circular_SMT {

 

        attr LIBRARY = "power_jack_lib";                        // This
would be used for the Eagle interface.  

 
//  My guess is it is not supposed to be a unique identifier but really a
library name in Eagle.

 

        attr DEVICE = "CUI_2.5mm_circular_SMT";   // This is the unique
device name, used for PADS or any other backend that wants a unique device
name.

 
// It is a little redundant since it will usually be the name in the device
declaration above.

 

        attr FOOTPRINT = "PJ-002AH-SMT_DECAL";    // Here is the physical
layout footprint name. I like this.

 

        attr PARTNUMBER = "PJ-002AH-SMT";             // This just goes to
the BOM.

 

        attr REFPREFIX = "J";

        attr REFDES = "";

        attr MFGR = "CUI";

 

        pin CENTER_POST =  {1};

        pin SIDE_CONTACT = {2};

        pin PLUG_DETECT =  {3};

 

Is it still possible to retrofit our language to work more like this?

 

    Pete

    

From: Joshua Mangelson [mailto:jos...@gm...] 
Sent: Thursday, November 29, 2012 6:00 AM
To: Peter Dudley
Subject: Re: [phdl-devel] .p file info

 

Hey Everybody,

 

We are going to need to take a  look at the LIBRARY attribute a bit it seems
like.

 

We chose the name LIBRARY because in eagle the package is referenced in the
following format:

<package_name>@<library_name>

 

The package keyword was already taken by the x-text frame work (and has thus
become a keyword in PHDL) so we ended up using FOOTPRINT for that.

 

It seems that PADS needs to have a link between the device and the package. 

 

The nice thing is that since we are hoping to create back-ends that could
hopefully do individual and very different things, we can pretty-much pick
any attribute name we want and have our individual back-end look for that
specific attribute name.

 

If we do however want to put these special required attributes into the
language spec we do need to look into this in the near future.

 

Personally, I would also like to look a bit into Altium and see if there is
anything special it would require as well.

 

Fortunately though, for the time being with the exception of the .p file,
the LIBRARY keyword works.

 

Let us know what you guys think about this.

 

Josh

 

 

On Tue, Nov 27, 2012 at 4:02 AM, Peter Dudley <hd...@ho...> wrote:

Guys,

 

I paste here the .p file for the little test design I did. It looks like
just the "*PADS-LIBRARY-PART-TYPES-V9*" section is required. In the .pdf
file that is called Part Type Definition.

 

For each part type there is an entry.  The first item comes from the
DxDesigner DEVICE attribute.  I think we decided to use an attribute called
LIBRARY in PHDL (Let's reconsider that sooner or later.)

 

The second item comes from the DxDesigner PKG_TYPE attribute. We use the
FOOTPRINT attribute in PHDL.  

 

In the specification there is some historical cruft.  I don't think we ever
want more than one "pcbdecals".  The rest can always be "I TTL 0 1 0 0 0".

 

In the Gate Format, I think we want to make everything a "normal part" and
avoid gate swapping. That is:

GATE 0 N 1 

where N is the number of pins on the part.  Then there is a list of pins by
alphanumeric pin number. We don't want to allow pinswap and we don't care
whether the pin is source, load, ground or whatever. We can make them all
source (S).

 

So below CAP_0603 should come from our LIBRARY attribute and CC0603 should
come from the FOOTPRINT attribute.

 

***************************************************

 

*PADS-LIBRARY-PART-TYPES-V9*

ATX12V ATX12V I TTL 0 1 0 0 0

GATE 0 6 1

6 0 S

5 0 S

4 0 S

1 0 L

2 0 L

3 0 L

 

CAP_0603 CC0603 I TTL 0 1 0 0 0

GATE 0 2 1

2 0 L

1 0 L

 

PC28F128P30 PC28F128P30 I TTL 0 1 0 0 0

GATE 0 64 1

A1 0 L

C3 0 L

D3 0 L

C4 0 L

A5 0 L

B5 0 L

C5 0 L

D7 0 L

D8 0 L

A7 0 L

B7 0 L

B1 0 L

C7 0 L

C8 0 L

A8 0 L

G1 0 L

C1 0 L

D1 0 L

D2 0 L

A2 0 L

C2 0 L

A3 0 L

B3 0 L

F6 0 L

B4 0 L

E6 0 L

F2 0 B

E2 0 B

F3 0 B

F4 0 B

F5 0 B

H5 0 B

G7 0 B

E7 0 B

G3 0 B

E4 0 B

E5 0 B

G5 0 B

G6 0 B

H7 0 B

E1 0 B

E3 0 B

F8 0 L

B6 0 S

B8 0 S

E8 0 S

F1 0 S

G2 0 S

H1 0 S

H8 0 S

D4 0 L

A6 0 L

H3 0 L

D5 0 L

D6 0 L

G4 0 L

A4 0 L

B2 0 L

H2 0 L

H4 0 L

H6 0 L

F7 0 S

G8 0 L

C6 0 L

*END*

 

 

 

From: Joshua Mangelson [mailto:jos...@gm...] 
Sent: Monday, November 26, 2012 11:53 PM
To: Peter Dudley
Cc: <phd...@li...>
Subject: Re: [phdl-devel] .p file info

 

Here is the PADS documentation for the the .p file.

 

Josh

 

On Wed, Nov 21, 2012 at 4:22 AM, Peter Dudley <hd...@ho...> wrote:

Guys,

I pulled up my Mentor tools to see how the .p file works.  I also contacted
the Mentor support line to see if they have a document describing that
format.

Right now I can give you an example file. 

Here is the simple schematic.

<<...>> 

Here is the .asc file that came out of it.

<<...>> 

And here is the .p file that came out.

<<...>> 

I tried deleting parts of the .p file but it seems to all be needed.  The
last column on the pin listings is either S, L or B but I don't know what
that column means.  I tried changing them all to L and that worked fine.

     Pete Dudley

     hd...@ho...

     www.HDLGuy.com


----------------------------------------------------------------------------
--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
phdl-devel mailing list
phd...@li...
https://lists.sourceforge.net/lists/listinfo/phdl-devel

 


----------------------------------------------------------------------------
--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
phdl-devel mailing list
phd...@li...
https://lists.sourceforge.net/lists/listinfo/phdl-devel

 

Re: [phdl-devel] .p file info

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

Guys,

 

I paste here the .p file for the little test design I did. It looks like
just the "*PADS-LIBRARY-PART-TYPES-V9*" section is required. In the .pdf
file that is called Part Type Definition.

 

For each part type there is an entry.  The first item comes from the
DxDesigner DEVICE attribute.  I think we decided to use an attribute called
LIBRARY in PHDL (Let's reconsider that sooner or later.)

 

The second item comes from the DxDesigner PKG_TYPE attribute. We use the
FOOTPRINT attribute in PHDL.  

 

In the specification there is some historical cruft.  I don't think we ever
want more than one "pcbdecals".  The rest can always be "I TTL 0 1 0 0 0".

 

In the Gate Format, I think we want to make everything a "normal part" and
avoid gate swapping. That is:

GATE 0 N 1 

where N is the number of pins on the part.  Then there is a list of pins by
alphanumeric pin number. We don't want to allow pinswap and we don't care
whether the pin is source, load, ground or whatever. We can make them all
source (S).

 

So below CAP_0603 should come from our LIBRARY attribute and CC0603 should
come from the FOOTPRINT attribute.

 

***************************************************

 

*PADS-LIBRARY-PART-TYPES-V9*

ATX12V ATX12V I TTL 0 1 0 0 0

GATE 0 6 1

6 0 S

5 0 S

4 0 S

1 0 L

2 0 L

3 0 L

 

CAP_0603 CC0603 I TTL 0 1 0 0 0

GATE 0 2 1

2 0 L

1 0 L

 

PC28F128P30 PC28F128P30 I TTL 0 1 0 0 0

GATE 0 64 1

A1 0 L

C3 0 L

D3 0 L

C4 0 L

A5 0 L

B5 0 L

C5 0 L

D7 0 L

D8 0 L

A7 0 L

B7 0 L

B1 0 L

C7 0 L

C8 0 L

A8 0 L

G1 0 L

C1 0 L

D1 0 L

D2 0 L

A2 0 L

C2 0 L

A3 0 L

B3 0 L

F6 0 L

B4 0 L

E6 0 L

F2 0 B

E2 0 B

F3 0 B

F4 0 B

F5 0 B

H5 0 B

G7 0 B

E7 0 B

G3 0 B

E4 0 B

E5 0 B

G5 0 B

G6 0 B

H7 0 B

E1 0 B

E3 0 B

F8 0 L

B6 0 S

B8 0 S

E8 0 S

F1 0 S

G2 0 S

H1 0 S

H8 0 S

D4 0 L

A6 0 L

H3 0 L

D5 0 L

D6 0 L

G4 0 L

A4 0 L

B2 0 L

H2 0 L

H4 0 L

H6 0 L

F7 0 S

G8 0 L

C6 0 L

*END*

 

 

 

From: Joshua Mangelson [mailto:jos...@gm...] 
Sent: Monday, November 26, 2012 11:53 PM
To: Peter Dudley
Cc: <phd...@li...>
Subject: Re: [phdl-devel] .p file info

 

Here is the PADS documentation for the the .p file.

 

Josh

 

On Wed, Nov 21, 2012 at 4:22 AM, Peter Dudley <hd...@ho...> wrote:

Guys,

I pulled up my Mentor tools to see how the .p file works.  I also contacted
the Mentor support line to see if they have a document describing that
format.

Right now I can give you an example file. 

Here is the simple schematic.

<<...>> 

Here is the .asc file that came out of it.

<<...>> 

And here is the .p file that came out.

<<...>> 

I tried deleting parts of the .p file but it seems to all be needed.  The
last column on the pin listings is either S, L or B but I don't know what
that column means.  I tried changing them all to L and that worked fine.

     Pete Dudley

     hd...@ho...

     www.HDLGuy.com


----------------------------------------------------------------------------
--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
phdl-devel mailing list
phd...@li...
https://lists.sourceforge.net/lists/listinfo/phdl-devel

 

Re: [phdl-devel] .p file info

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

On Monday, November 26, 2012 15:53:02 Joshua Mangelson wrote:
> Here is the PADS documentation for the the .p file.

Thanks, Joshua, great find! (I'm actually pleasantly surprised that Mentor 
actually documented this.)

Re: [phdl-devel] [phdl:bugs] Re: #37 PADS .asc output incorrect.

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

Ok, 

 

I understand how it works.  I guess LIBRARY is a little bit of a misnomer. I
had no idea what it did. 

 

It is not a bad idea to have a completely unconstrained attribute for this
purpose. Perhaps, PARTNAME or something would be more natural. On the other
hand, we could probably just use the name of the device.  Perhaps, that
would be the default and only if a LIBRARY (or PARTNAME) attribute is
defined it would override the device name in the netlist generation.

 

Let's do nothing for now until we figure out what happens with PHDLIF.

 

  Pete

 

From: Brad [mailto:bri...@us...] 
Sent: Tuesday, November 20, 2012 10:16 PM
To: [phdl:bugs] 
Subject: [phdl:bugs] Re: #37 PADS .asc output incorrect.

 

I seem to remember this change happening when it was requested that the
device name needed to support all sorts of special characters to allow
consistency with the names from PADS libraries. We thought at the time the
best way to fix it would be to pull from a quoted attribute (which didn't
have any restrictions on characters) instead of using the device name which
was constrained to conventional identifier rules in traditional programming
languages. Hence the LIBRARY attribute was born. If you modify the
library attribute in each device and give it your device name, it should
fix the problem.

On Tue, Nov 20, 2012 at 12:51 PM, Joshua Mangelson
jos...@us...:

Hey Pete,

When I looked at it, it looks like the generator is working correctly.

The "devices" string is being pulled from the LIBRARY attribute in each of
your device definitions in the devices.phdl file, which all seem to be set
to "devices". The generator pulls from the FOOTPRINT and LIBRARY required
attributes to create the .asc file.

The generated output looks like this:
REFDES LIBRARY@FOOTPRINT

Looking at your email and the devices.phdl file in the refdesign folder, it
looks like this is happening correctly.

Is this the format you think is correct for a .asc file?

Josh

On Tue, Nov 20, 2012 at 11:06 AM, Joshua Mangelson jos...@us...
wrote:

Hey Pete,

I'll take a look at it.
I think it should be a fairly simple fix.
I think the bug probably hadn't been found yet since we've been mainly
using eagle and just now looking into altium.

Josh

On Tue, Nov 20, 2012 at 8:24 AM, peter dudley pa...@us... wrote:

Guys, I talked to Chuck and he has basically the same problem in the 2.0
compiler.

I bumped up the priority because he is ready to go into layout and he
needs to be able to generate a correct netlist (.asc) file.

  _____  



*	bugs:37 http://sourceforge.net/../bugs:37 PADS .asc output
incorrect.*

Status: Open
Created: Tue Nov 20, 2012 01:26 PM UTC by peter dudley
Last Updated: Tue Nov 20, 2012 01:26 PM UTC
Owner: nobody

it looks like PHDL compiler 2.1 has a bug. In the PART section all the
parts are listed like this (refdes devices@footprint):

PART
J1 devices@PJ-002AH-SMT
MTG1 devices@MOUNT_HOLE_125
OSC1 devices@CB3LV-3I
PS1/C3 devices@CC0805
PS2/C43 devices@TANT3528
PS2/C5 devices@CC0603
X/D8 devices@LED_1113F
X/D9 devices@LED_1113F
X/P1 devices@MOLEX-87332-1420

The "devices" is coming from the file name, devices.phdl, that holds the
device definitions. The "devices" string should be the device name. For
example:

X/P1 devices@MOLEX-87332-1420

should be

X/P1 JTAG_CONN@MOLEX-87332-1420

How are you guys working with this?
Pete

Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/phdl/bugs/37/

To unsubscribe from further messages, please visit
https://sourceforge.net/auth/prefs/

  _____  



*	bugs:37 http://sourceforge.net/../bugs:37 PADS .asc output
incorrect.*

Status: Open
Created: Tue Nov 20, 2012 01:26 PM UTC by peter dudley
Last Updated: Tue Nov 20, 2012 03:24 PM UTC
Owner: nobody

it looks like PHDL compiler 2.1 has a bug. In the PART section all the
parts are listed like this (refdes devices@footprint):

PART
J1 devices@PJ-002AH-SMT
MTG1 devices@MOUNT_HOLE_125
OSC1 devices@CB3LV-3I
PS1/C3 devices@CC0805
PS2/C43 devices@TANT3528
PS2/C5 devices@CC0603
X/D8 devices@LED_1113F
X/D9 devices@LED_1113F
X/P1 devices@MOLEX-87332-1420

The "devices" is coming from the file name, devices.phdl, that holds the
device definitions. The "devices" string should be the device name. For
example:

X/P1 devices@MOLEX-87332-1420

should be

X/P1 JTAG_CONN@MOLEX-87332-1420

How are you guys working with this?
Pete

Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/phdl/bugs/37/

To unsubscribe from further messages, please visit
https://sourceforge.net/auth/prefs/

  _____  



*	bugs:37 http://sourceforge.net/../bugs:37 PADS .asc output
incorrect.*

Status: Open
Created: Tue Nov 20, 2012 01:26 PM UTC by peter dudley
Last Updated: Tue Nov 20, 2012 03:24 PM UTC
Owner: nobody

it looks like PHDL compiler 2.1 has a bug. In the PART section all the
parts are listed like this (refdes devices@footprint):

PART
J1 devices@PJ-002AH-SMT
MTG1 devices@MOUNT_HOLE_125
OSC1 devices@CB3LV-3I
PS1/C3 devices@CC0805
PS2/C43 devices@TANT3528
PS2/C5 devices@CC0603
X/D8 devices@LED_1113F
X/D9 devices@LED_1113F
X/P1 devices@MOLEX-87332-1420

The "devices" is coming from the file name, devices.phdl, that holds the
device definitions. The "devices" string should be the device name. For
example:

X/P1 devices@MOLEX-87332-1420

should be

X/P1 JTAG_CONN@MOLEX-87332-1420

How are you guys working with this?


Pete


Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/phdl/bugs/37/

To unsubscribe from further messages, please visit
https://sourceforge.net/auth/prefs/

  _____  

bugs:37 <http://sourceforge.net/../bugs:37>  PADS .asc output incorrect.

Status: Open
Created: Tue Nov 20, 2012 01:26 PM UTC by peter dudley
Last Updated: Tue Nov 20, 2012 03:24 PM UTC
Owner: nobody

it looks like PHDL compiler 2.1 has a bug. In the PART section all the parts
are listed like this (refdes devices@footprint):

PART
J1 devices@PJ-002AH-SMT
MTG1 devices@MOUNT_HOLE_125
OSC1 devices@CB3LV-3I
PS1/C3 devices@CC0805
PS2/C43 devices@TANT3528
PS2/C5 devices@CC0603
X/D8 devices@LED_1113F
X/D9 devices@LED_1113F
X/P1 devices@MOLEX-87332-1420

The "devices" is coming from the file name, devices.phdl, that holds the
device definitions. The "devices" string should be the device name. For
example:

X/P1 devices@MOLEX-87332-1420

should be

X/P1 JTAG_CONN@MOLEX-87332-1420

How are you guys working with this?

Pete

  _____  

Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/phdl/bugs/37/

To unsubscribe from further messages, please visit
https://sourceforge.net/auth/prefs/

Re: [phdl-devel] PHDL workaround

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

Thanks for the work around. 

I will take the action item to figure out what goes into the .p file. Also, I can test it here with my PADS software.

-----Original Message-----
From: Wesley J. Landaker [mailto:wj...@sa...] 
Sent: Tuesday, November 20, 2012 9:47 PM
To: pe...@hd...
Cc: Graham, Charles W
Subject: PHDL workaround

Hey Pete,

Thanks for the call earlier!

We figured out a workaround for the problem Chuck was seeing with PADS netlist output, using PHDL 2.0. Basically he just had to fill in the "LIBRARY" 
attribute with the device name. Was the problem you were seeing with PHDL 2.0 or 2.1? It might be a different, but related problem.

Anyway, the other thing Chuck wants to do, which I know you mentioned like 100 times, is to spit out a ".p" file. I think I can add that functionality pretty easily in a quick fix for Chuck (and it might help you as well!) rather than wait to "do it right" based on PHDLIF (which I also want to do eventually). 
But the big thing is, what is in that file?! I see it's mapping part/pin to something about the footprint, but I don't know what all the indices and letter types mean. Do you know anything about that format?

--
Wesley J. Landaker <wj...@sa...>
Sandia National Laboratories, Embedded Signal Processors 05339

Re: [phdl-devel] [phdl:bugs] Re: #36 REFPREFIX operation with subinst

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

Josh

 

To be useful, reference designators must be very, very short.   For that
reason I believe the compiler should not put any extra characters into the
refdes that are not requested by the designer.  For example if I make
REFPREFIX = "X/" then I will get the slash.  If I make it REFPREFIX = "X"
then I do not get it.

 

  Pete

 

Re: [phdl-devel] PHDL spec mods

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

On 11/15/2012 06:12 PM, Joshua Mangelson wrote:
> Thanks, that makes a lot of sense. I think I was mainly confused by the
> notation, but making it more standard, sounds good to me. 

Yeah, we definitely will need to clearly describe what notation we are
using in our spec. For now as long as we are writing it in fairly
de-facto standard EBNF and/or typical "Regex" syntax I think we should
be able to communicate clearly to each other at least while we work on
what we want the grammar to be and we can clean it up real good in a
final pass.

> One of the main things for many of our Identifiers is just making sure
> certain characters such as ".", "/", or "\" are not included because  it
> could cause problems later on down the road, as these characters are
> often used as delimiters, so I just thought I would ask. 

Yeah, we definitely want to exclude any characters like that which might
be used for language syntax. The nice thing about the Unicode identifier
standard (and the related properties, ID_Start/ID_Continue) is that this
has already been taken into account, so we don't have to do anything
special to pick up all these benefits. There are no characters in those
categories that would ever generally be used for language syntax.

On the other side of things, we can *extend* the characters we allow in
identifiers by adding specific additions beyond the "identifier"
character set from the standard. (This may actually be a good idea, but
I'm not proposing that we do this at this point, as it complicates things).

Re: [phdl-devel] PHDL spec mods

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

On Thursday, November 15, 2012 10:31:49 Joshua Mangelson wrote:
> Could you explain a little more about what yuo changed, especially with
> respect to the ID/ Identifier rule,
> and with white space as well?

Sure. I started with some of our most common terminals, which are the 
lexical elements that are part of our current parsing implementation, and 
looked at how they could be defined in a more standardized fashion.

Let me go ahead and walk through the changes:

From the document:
> > Identifiers
> > ~~~~~~~~~~~
> > 
> > All identifiers are like standard Unicode identifiers, but are 
additionally
> > allowed to start with connectors such as underscore.

Our previous identifiers were very spartan and anglocentric, which was fine 
for a first cut, but since we are turning this into a real spec, there is no 
reason not to follow good, modern standards. In this case, the standard in 
Unicode, and specifically, "Unicode Standard Annex #31: Unicode Identifier 
and Pattern Syntax".

There are a lot of ways to apply this to language identifiers, but the 
simplest definition is just that identifiers can start with a character with 
the Unicode "ID_Start" property, and can be followed by identifiers with the 
Unicode "ID_Continue" property. This gives the usual "abcd123" is an 
identifier, but "1234abcd" is not rules that most languages have, but with 
zero effort, this is extended to sanely support all languages in a uniform 
and standardized way.

Since we actually want to support connectors, such as underscore, at the 
beginning of our identifiers, we also allow any characters in the Unicode 
"Pc" (punctuation, connectors) class. This is a very common extension.

We could allow additional identifiers if we wished -- for instance, we could 
allow identifiers that start with numbers if that would be useful (and in a 
PCB design, it arguably could be), but I left things very similar to what we 
already had.

> > ------------
> > Identifier = (\p{ID_Start} | \p{Pc}) \p{ID_Continue}*
> > ------------

For notational convenience, I've written this along the lines of Unicode 
regulator expression syntax (as described in "Unicode Technical Standard 
#18: Unicode Regular Expressions"), but most often seen in any even somewhat 
Perl-compatible regular expression (PCRE is a de-facto standard). There is 
no reason we have to use a really iron-clad syntax in our specification 
document -- as long as we explain our notation (I didn't, as I figured we'd 
have a section at the beginning that did that) and we don't have anything 
ambiguous once we're done! =)

In this particular spot, the \p{xxx} means a character with the property or 
class "xxx". So here, this means that we have to start with an ID_Start 
character or connector punctuation, then the rest of the characters can be 
any ID_Continue characters. If you "ASCII-ify" this, it's basically the same 
as:

[_A-Za-z][_A-Za-z0-9]*

> > Integers
> > ~~~~~~~~
> > 
> > All integers are in decimal. Leading zeros are explicitly allowed.
> > 
> > ------------
> > Integer = [0-9]+
> > ------------
> > 

I simplified integers. We should allow leading zeros and always treat them 
as decimal. We definitely should not propagate the silly C-ism that numbers 
that start with 0 are in octal, and prohibiting numbers starting with 0 is 
mathematically incorrect and additionally is more complex to implement.

As I stated in the commit log, if we wish to add other-based numbers (e.g. 
octal or hexadecimal), we can decide how that should be indicated (the de-
facto "0xdeadbeef" "0o644" aren't bad, but I'm not proposing anything at 
this time, as we currently only have decimal numbers, and I'm making minor 
changes to start).

> > Comments
> > ~~~~~~~~
> > 
> > PHDL allows C\+\+-style single line and multi-line comments. Single-line
> > comments start with +//+ and ends at any Unicode line-ending sequence.
> > 
> > Multi-line comments start with +/\*+ and end with +*/+.
> > 
> > Neither kind of comments can be nested in any way.
> > 
> > ----------------
> > Line_Ending =
> >  | \x0A       // LINE FEED (LF)
> >  | \x0B       // LINE TABULATION
> >  | \x0C       // FORM FEED (FF)
> >  | \x0D       // CARRIAGE RETURN (CR)
> >  | \x85       // NEXT LINE (NEL)
> >  | \x2028     // LINE SEPARATOR
> >  | \x2029     // PARAGRAPH SEPARATOR
> > Single_Line_Comment = "//" (!Line_Ending)* Line_Ending
> > Multi_Line_Comment = "/*" !("*/") "*/"
> > ----------------

This doesn't change comment syntax at all, it just brings it into 
compatibility with Unicode standards, primarily by adding to the set of line 
endings.

> > Whitespace
> > ~~~~~~~~~~
> > 
> > All whitespace characters between (but not part of) individual lexical 
elements
> > are ignored. Whitespace consists of one or more Unicode characters in a 
row
> > with the "Pattern_White_Space" property.
> > 
> > ---------------
> > Whitespace = \p{Pattern_White_Space}+
> > ---------------

This also doesn't really change anything, except for treating all Unicode 
pattern white space as white space. I think I'd actually prefer to use 
"White_Space" rather than "Pattern_White_Space", as it's a more complete 
class, but picked "Pattern_White_Space" in the interest of minimal changes 
for now. The main difference is that White_Space covers all Unicode white 
space, and Pattern_White_Space covers only certain Unicode white space and 
can never be extended.

On Thursday, November 15, 2012 10:31:49 Joshua Mangelson wrote:
> In alot of grammars, the Lexical rules are defined in all caps, is that
> something we want to continue with?

Keep in mind that "lexing" is in most grammars really an implementation 
detail. I think it can be useful to talk about conceptually, but there is no 
theoritical basis for a lexer/parser split (as opposed to the fundamental 
idea of layered grammars).

The ALL_CAPS thing is a convention that got picked up mostly due to a lot of 
grammars identifying lexical types by enums, which typically use all caps in 
C in an attempt at namespace deconflicting. I don't think that's especially 
helpful in modern languages or in a specification document.

We can write them all in caps if anyone feels especially strongly about it, 
but I'd suggest we just follow normal English convension, where we 
capitalize our terms that we have defined as essentally New Proper Nouns 
(e.g. "whitespace" is a general term, but "Whitespace" is the specific type 
of whitespace defined by our language).

Anyway if anyone has any more questions, this is good discussion! Let's talk 
this stuff through and end up with a non-buggy PHDL spec that really says 
what we want. =)

Re: [phdl-devel] PHDL spec mods

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

How do you think is best to define it?



On Thu, Nov 15, 2012 at 10:31 AM, Joshua Mangelson <jos...@gm...>wrote:

> Hey Wes,
>
> Could you explain a little more about what yuo changed, especially with
> respect to the ID/ Identifier rule,
> and with white space as well?
>
> In alot of grammars, the Lexical rules are defined in all caps, is that
> something we want to continue with?
>
> Thanks,
>
> Josh
>
>
> On Wed, Nov 14, 2012 at 11:32 PM, Wesley J. Landaker <wj...@ic...>wrote:
>
>> Guys,
>>
>> FYI, I modified the spec a bit in the lexical elements area to start
>> giving us a nice, solid lexical baseline that better follows standards
>> (such as Unicode). I've also started formating our document in asciidoc
>> a little better.
>>
>> I think everything I've changed so far is uncontroversial. I do have
>> some more major changes that I'm going to propose when I get a chance to
>> work on this more later. (One example that I've brought up before is
>> getting a handle on our many and varied string escapes sequences.)
>>
>>
>> ------------------------------------------------------------------------------
>> Monitor your physical, virtual and cloud infrastructure from a single
>> web console. Get in-depth insight into apps, servers, databases, vmware,
>> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
>> Pricing starts from $795 for 25 servers or applications!
>> http://p.sf.net/sfu/zoho_dev2dev_nov
>> _______________________________________________
>> phdl-devel mailing list
>> phd...@li...
>> https://lists.sourceforge.net/lists/listinfo/phdl-devel
>>
>
>

Re: [phdl-devel] PHDL spec mods

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

Hey Wes,

Could you explain a little more about what yuo changed, especially with
respect to the ID/ Identifier rule,
and with white space as well?

In alot of grammars, the Lexical rules are defined in all caps, is that
something we want to continue with?

Thanks,

Josh


On Wed, Nov 14, 2012 at 11:32 PM, Wesley J. Landaker <wj...@ic...>wrote:

> Guys,
>
> FYI, I modified the spec a bit in the lexical elements area to start
> giving us a nice, solid lexical baseline that better follows standards
> (such as Unicode). I've also started formating our document in asciidoc
> a little better.
>
> I think everything I've changed so far is uncontroversial. I do have
> some more major changes that I'm going to propose when I get a chance to
> work on this more later. (One example that I've brought up before is
> getting a handle on our many and varied string escapes sequences.)
>
>
> ------------------------------------------------------------------------------
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from $795 for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov
> _______________________________________________
> phdl-devel mailing list
> phd...@li...
> https://lists.sourceforge.net/lists/listinfo/phdl-devel
>

[phdl-devel] PHDL spec mods

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

Guys,

FYI, I modified the spec a bit in the lexical elements area to start
giving us a nice, solid lexical baseline that better follows standards
(such as Unicode). I've also started formating our document in asciidoc
a little better.

I think everything I've changed so far is uncontroversial. I do have
some more major changes that I'm going to propose when I get a chance to
work on this more later. (One example that I've brought up before is
getting a handle on our many and varied string escapes sequences.)

[phdl-devel] PHDL Feedback

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

Guys, I did a quick reply about PHDL on a rant posting about Mentor Graphics
schematic editor.  I think we have a responsibility to succeed.  Here is
some feedback we got.


"I wish you (and all of us) luck with the open source approach!
management where I work refuses to understand that you have to maintain the
discarded schematic packages when you start using a new one.
If I had a nickel for every archive of design files no longer readable at
this firm, I'd have several nickels."

Re: [phdl-devel] 3.0 Language Grammar Spec

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

Will do.


On Mon, Nov 12, 2012 at 5:51 PM, Wesley J. Landaker <wj...@ic...>wrote:

> On Monday, November 12, 2012 17:31:26 Joshua Mangelson wrote:
> > Dr. Nelson and I will start working on a formal language specification
> > for the 3.0 version of the language grammar. I'll check it in to the git
> > repository.
> >
> > We'll make it mainly based on the 2.1 grammar since thats the most
> > updated grammar we have and then in a few days, when we've finished it,
> > I'll send out an email and we can all discuss and vote on specific
> > changes to that grammar, so we'll have a finalized language
> > specification.
>
> Awesome, guys!
>
> I'm not sure what your plan is for file format, but I'd encourage the use
> of
> something easy to work with in version control, such as asciidoc (or HTML,
> or LaTeX, or whatever). (Or, if you've just got to use a word processor, at
> least use the OpenDocument standard format rather than a proprietary
> format!)
>
> Also, take a look in git/doc/PHDL_spec.txt, where Pete already wrote a
> little bit of intro text in asciidoc format. There may be some verbage
> there
> worth incorporating.
>
>
> ------------------------------------------------------------------------------
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from $795 for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov
> _______________________________________________
> phdl-devel mailing list
> phd...@li...
> https://lists.sourceforge.net/lists/listinfo/phdl-devel
>
>

Re: [phdl-devel] 3.0 Language Grammar Spec

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

On Monday, November 12, 2012 17:31:26 Joshua Mangelson wrote:
> Dr. Nelson and I will start working on a formal language specification
> for the 3.0 version of the language grammar. I'll check it in to the git
> repository.
> 
> We'll make it mainly based on the 2.1 grammar since thats the most
> updated grammar we have and then in a few days, when we've finished it,
> I'll send out an email and we can all discuss and vote on specific
> changes to that grammar, so we'll have a finalized language
> specification.

Awesome, guys!

I'm not sure what your plan is for file format, but I'd encourage the use of 
something easy to work with in version control, such as asciidoc (or HTML, 
or LaTeX, or whatever). (Or, if you've just got to use a word processor, at 
least use the OpenDocument standard format rather than a proprietary 
format!)

Also, take a look in git/doc/PHDL_spec.txt, where Pete already wrote a 
little bit of intro text in asciidoc format. There may be some verbage there 
worth incorporating.

[phdl-devel] 3.0 Language Grammar Spec

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

Hey Everybody,

Dr. Nelson and I will start working on a formal language specification for
the 3.0 version of the language grammar. I'll check it in to the git
repository.

We'll make it mainly based on the 2.1 grammar since thats the most updated
grammar we have and then in a few days, when we've finished it, I'll send
out an email and we can all discuss and vote on specific changes to that
grammar, so we'll have a finalized language specification.

Once we have the formal specs it'll be easier to decide where to go after
that.

Josh

Re: [phdl-devel] hierarchical packages

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

Alright, that makes sense.

The device definitions you end up using are most likely ones you've used
before that you know are correct. And if you do end up using a footprint
from a predefined library you will need to check the footprint leayout very
well to make sure it would work anyway, and since the syntax is so simple,
it would make sense to just write the part definition at this time anyway.

Thanks.


On Sun, Nov 11, 2012 at 9:59 PM, Brent Nelson <bre...@by...> wrote:

> Hi All,
>
> My take on hierarchical packages is I tend with Pete on this - copying and
> pasting the components for a board into a single file seems like a
> reasonable approach to me.
>
> Brent
>
>
>
> On 11/11/12 2:29 PM, "Wesley J. Landaker" <wj...@ic...> wrote:
>
> >On Sunday, November 11, 2012 01:45:30 peter dudley wrote:
> >> When I do use some kind of library with PHDL or schematics I like to
> >> remove all the components that are not actually used in the design.  The
> >> library gets very small that way and I can just version control it along
> >> with the design.  I don't like all the cruft of questionable and
> >> obsolete components to be versioned alog with my design work.
> >
> >I absolutely agree here. Nothing belongs in a design except the design
> >itself and information specifically connected to it, especially when
> >version
> >control comes into play.
> >
> >That said, I would might use (or emulate) hierarchical packages just to
> >organize things and keep the global namespace clean.
>
>
>
> ------------------------------------------------------------------------------
> 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_nov
> _______________________________________________
> phdl-devel mailing list
> phd...@li...
> https://lists.sourceforge.net/lists/listinfo/phdl-devel
>

Re: [phdl-devel] PHDL Directions: Grammar, Tool, IF

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

Hierarchy probing is useful and I remember that our syntax for it is pretty
natural.

Let's talk more about inst arrays.

[phdl-devel] package hierarchy and forking

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

Brad, Josh,

 

Package hierarchy and inheritance are examples of interesting stuff that
should be tried.  

 

On the other hand, to save people like me from schematic editing we only
need device declaration, device instantiation and hierarchy. Remember, there
are a lot of people who just type their PADS netlist by hand.  That is how
desperate they are for simplicity.

 

We could have a production fork for the simple bug-free text-to-text
converter that designers need.  

 

We could have an experimental fork with a lot of features.

 

 

 

From: Brad Riching [mailto:bra...@gm...] 
Sent: Monday, November 12, 2012 6:24 AM
To: Joshua Mangelson
Cc: peter dudley; <phd...@li...>
Subject: Re: [phdl-devel] benefits of language simplicity?

 

Hi everyone,

 

I like the idea of design units in packages, because it helps me stay
organized with "golden" designs.  I'm probably a lot different from the
typical hardware designer when I use VHDL because once I get something
solidified, I migrate it over into it's own library.  I then make all of my
compiler toolchains aware of the physical location containing my library.  I
realize PCB designs are quite different in that each tends to be a custom
solution to the problem at hand.  But for designers managing a modular
product line with many re-usable circuits, it might be nice to store the
solidified connectivity in a library, especially since it gives a more
robust interface when it comes time to instantiation, versus just
copy-and-paste.

 

I had an idea last week about device inheritance last week.  If the language
was modified to allow devices to inherit from other devices, it would make
special case definitions simple.  It would also allow for a root device
(like everything extends from object in Java) that would already have the
three necessary attributes required to generate valid output.  This could
also be implied by the language as every device extends from Device.
Attributes inside of devices that inherited could then just reassign the
attribute previously declared in the super-device.  The syntax could be as
simple as this:

 

// everything inherits from Device

device Device {

  attr REFPREFIX = "";

  attr FOOTPRINT = "";

  attr LIBRARY= "";

}

 

// a device for resistors caps and inductors in an 0603 footprint

device rcl_0603 of Device {

  FOOTPRINT = "0603";

  LIBRARY = "rcl";

  pin a = {1};

  pin b = {2};

}

 

// an 0603 resistor (pins inherit from above)

device R0603 of rcl_0603 {

  REFPREFIX = "R";

}

 

// an 0603 capacitor

device C0603 of rcl_0603 {

  REFPREFIX = "C";

}

 

I would also suggest right now while the syntax is being formally defined
that we get rid of the "of" keyword in favor of a colon.  This is really an
implementation-specific request, because the eclipse IDE and Xtext tools do
not support content-assist keying off of keywords.  They only support
content-assist auto-invocation from individual characters (such as a period,
colon, etc.).  In other words, it is impossible to get the content-assist to
make suitable proposals after typing "of".  You must invoke the
content-assist manually with CTRL-Space.  For these reasons I suggest we
switch over to a colon.

 

Furthermore, I suggest that we have the option to integrate the REFPREFIX
attribute into the declaration of the device, with the option to end the
declaration with a semicolon vs. braces if nothing else is needed.  I can
see libraries being much more readable and maintainable if this style is
introduced in the syntax.  

 

device R0603 : rcl_0603 "R";

device C0603 : rcl_0603 "C";

 

I would really like to see the option to specify the other mandatory
attributes in the declaration of a device as well, almost like a function
prototype.  However, I can also see the ordering becoming a problem if no
keywords are used.  Maybe something like this would solve any ambiguity:

 

device R0603 : rcl_0603 (pre:"R", foot:"0603", lib:"rcl");

 

I am used to getting more features as software gets better, so I naturally
expect more capability to come out of PHDL evolves.  I think if we leave the
language too simple, then everyone is going to think of it more as a toy
than something they can really switch over to.  Since we are approaching the
project from a much different perspective with maintenance and development,
I can also understand how we would want to scale back.  What does everyone
think?

 

Brad

 

On Sat, Nov 10, 2012 at 6:15 PM, Joshua Mangelson <jos...@gm...>
wrote:

That makes sense.

I was thinking was about using it to organize parts as well. For example, if
you were to use a parser to grab all of the package definitions found within
eagle's libraries, it would be useful to group them all within a package
called eaglelibs, and then into subpackages according to their eagle library
name. I think it could make things much easier to organize, but what do you
think about this possibility?

 

On Sat, Nov 10, 2012 at 1:44 AM, peter dudley <hd...@ho...> wrote:

If I understand your question about hierarchical packages, I see packages as
a place to put device definitions, nothing more.  I don't see myself wanting
to put subdesigns into packages.
 
Our simple text based approach to design entry far exceeds the utility of
schematic tools for design re-use.  This re-use would generally be of the
"cut-paste-modify" form rather than to instantiate a subdesign unmodified.
 
For these reasons I don't think we need to have a package refer to other
packages.  

 

  _____  

Date: Fri, 9 Nov 2012 16:18:47 -0700
Subject: Re: [phdl-devel] benefits of language simplicity?
From: jos...@gm...
To: hd...@ho...
CC: phd...@li...



I think that could definetly be a possible solution to the situation.

 

But its a trade off between the losing the features of the language that
make it so useful and simplifying the design. 

 

In my opinion, the array and vector capabilities are what makes the language
so useful and powerful, I don't think it is worth it to lose those
capabilities for what we would gain in return. Also, if we decide to use
either the 2.0 or 2.1 versions of the compiler, they both already implement
these capabilities. 

 

The major increase in complexity from 2.0 to 2.1 is because of the process
of developing for a plug-in to eclipse rather than any specific change in
the grammar.

 

Also, what does everyone think about hierarchical packages?

 

 

 

 

 

On Fri, Nov 9, 2012 at 9:38 AM, peter dudley <hd...@ho...> wrote:

It sounds right, that the complexity of the compiler is in the elaboration.
I was just hoping that a much simpler language would simplify the entire
compiler, including elaboration.

Do we think that is the situation?





----------------------------------------------------------------------------
--
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_nov
_______________________________________________
phdl-devel mailing list
phd...@li...
https://lists.sourceforge.net/lists/listinfo/phdl-devel

 

 


----------------------------------------------------------------------------
--
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_nov
_______________________________________________
phdl-devel mailing list
phd...@li...
https://lists.sourceforge.net/lists/listinfo/phdl-devel