phdl-devel — PHDL General Development Discussion

[phdl-devel] DxDesigner rant

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

Hey Guys, Wes found this rant.  Trust me. This guy is spot on with his criticism of that tool.  Really he is being kind.

The root cause of the DxDesigner problems is the use of a super complex tool to solve a very, very, very simple problem.  They destroyed themselves with featuritis and did a lot of harm to others in the process.

https://offlogic.wordpress.com/2009/08/12/why-does-mentor-graphics-suck-so-very-very-much/

Please remember that defining PCB connectivity (unlike logic design) is a very, very, very simple problem.  Let's not end up receiving this kind of attention with our tool.

  Pete

Re: [phdl-devel] benefits of language simplicity?

[Brad R. <bra...@gm...>]

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

Re: [phdl-devel] hierarchical packages

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

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.

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

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

Hi All,

Wes' example below is why we included the hierarchical probing feature in
the first place.  

Our thought was that having multiple copies of *almost* identical
sub-designs would not be an uncommon situation - Wes' resistor change is
exactly the scenario we envisioned.

Other HDL's have all recognized the need for instance customization by
providing generics or parameters that can be associated with a sub-module
instantiation.  They go much farther than PHDL does, however, by allowing
you to pass in arbitrary data types and then, inside the instantiation,
allow arithmetic using the provided generics or parameters for a variety
of purposes.  That approach adds a lot of complexity to VHDL and Verilog
(both language and tools) because they need to support multiple data types
as well as a full expression evaluation capability for working with the
generic values.  

Our thought was that the hierarchical probing provides a similar (but much
simpler) capability which handles the main cases that PHDL needs - the
ability to customize attributes in sub-instances.  We discussed that
without it, the use of hierarchy may be significantly reduced since all
copies would HAVE to be identical before hierarchy would be use-able.

Once again, I come back to my previous arguments about how to decide what
we put in the language.  The decision points seem to be: (a) how useful is
it? vs. (b) how much complexity to a tool chain will it add?  We see
significant value in it.  Its implementation in the current tools is not a
complex thing, suggesting that we are not paying a big complexity price
for it.  So, in my mind it would be a step backward to remove it.

On a related note - I would say the same thing about the need for some
kind of iteration construct.  Without the ability to iterate, PHDL would
be a much less desirable language from our viewpoint.  Copying, pasting,
and editing indices to make 32 or 64 of anything would be a pain.  For us,
the discussion is about what kind of syntax we want if some don't like the
instance array syntax we have.  Suggestions?

Brent



On 11/11/12 2:12 PM, "Wesley J. Landaker" <wj...@ic...> wrote:

>On Wednesday, November 07, 2012 03:46:20 Peter Dudley wrote:
>> 1.       Eliminate (for now) our implementation of the VHDL for.generate
>> feature.
>
>I opened a new thread about this.
> 
>> 2.       Eliminate (for now) the hierarchy probing feature of the
>> language, ie. 'inst.subinst.subinst2.value = "100";'.  Again, I have
>> difficulty seeing a case where this is necessary or desirable in a board
>> design.
>
>This feature can be quite useful in some situations. Here is an example.
>I 
>have a design that uses switching regulators that have their voltage
>programmed by setting a pair of resistors in a certain ratio. There is
>all 
>sorts of other complex stuff (inductors, other capacitors and resistors)
>that is necessary to hook up the regulator that doesn't change. I have to
>instance about 10 of these all with different voltages. The only part
>that 
>needs to change is the resistor.
>
>So my options are to bring the resistor connections out to ports in a
>subdesign, or use "heirarchy probing" to set the values of the resistors
>for 
>each instance.
>
>I could obviously design this without it, but this is one real-world
>example 
>where it's useful.
>
>(Sadly, the design is *actually* in DxDesigner, not in PHDL, but I've
>used 
>PHDL to describe parts of it as a human communication mechanism).
>
>> Is there a document on the wiki or in the repo for the language spec?
>> Should I start one?
>
>Unless anyone else says they're going to give it a go, sounds like we
>have a 
>volunteer! =)

Re: [phdl-devel] hierarchical packages

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

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.

Re: [phdl-devel] benefits of language simplicity?

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

On Friday, November 09, 2012 16:18:47 Joshua Mangelson wrote:
> Also, what does everyone think about hierarchical packages?

I agree with Pete that largely the use of pre-existing libraries is 
something of an anti-feature in current PCB design culture, so if that was 
our only motivation to having hierarchical packages, it's not a great 
argument.

That said, I could see hierarchical packages being useful for organizing 
things. I might use them in a design even when I'm hand-crafting my parts on 
the fly, just to keep them in a nice, organized, easy-to-review format.

I'm not strongly for or against hierarchical packages partly because I can 
always emulate them (e.g. using "__" as a de-facto hierarchy separator, or 
somthing like that).

One thing that comes to mind is that we have to make sure we understand how 
our "hierarchy probing", "package.instance instatiation", and hiearchical 
packages would interact (e.g. are packages in the same namespace as devices? 
and questions like that).

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

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

On Wednesday, November 07, 2012 20:50:21 Joshua Mangelson wrote:
> Here are my views with respect to these two issues:
> 
> 1. The Grammar
> 
> I feel somewhat partial to the 2.1 grammar, it is the one that I have had
> the most experience with and the one that I feel has the most kinks
> worked out. 

I absolutely agree. The 2.1 grammar is what I'm considering our "baseline" 
grammar. Let's start with that and move forward.

> That said, I'm not opposed to making slight modifications to the grammar
> before finalizing the language spec for the time being. It think we
> should have a discussion about specific changes to the grammar and once
> we come to a consensus in the next few days then begin working on
> finalizing the formal language specification, with:
>
>    - Grammar - or allowed syntax
>    - Detailed explanations of the interpretation of syntax
>    - Detailed explanations of the output that should be generated from
> the interpreted syntax
>    - Formats such as the PHDLIF spec that we have been discussing

Do I hear another volunteer to get this started? Pete just suggested 
starting this on the wiki. That's a reasonable way to do it. Do you agree?

Who is going to kick this off?
 
> 2. Implementation Choice to use as a Starting Point
[...]
> The view that seems the best in my view would be to use the 2.0 version
> of the compiler, and update it and document/test it to comply with a
> grammar similar to the 2.1 version of the grammar. This would allow for
> simplicity of development, while at the same time preserving at least
> some of the the work/time that Brad has applied in the past 4-5 months.
> 
> I think that we should come to a conclusion about what each of us think
> in these areas and then after this discussion, begin working on the
> specific language spec.

I think I'm going to wait to have a fairly finished language spec and hear 
more about people's long term plans and goals before I opine strongly about 
what implementation we should use a core compiler.

That said, if we are choosing between existing alternatives, I think the 
PHDL 2.0 code base with an updated grammar is unequivocally our best choice 
unless we have a strong, active maintainer who wishes to keep the Eclipse 
based version going long term.

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

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

On Wednesday, November 07, 2012 03:46:20 Peter Dudley wrote:
> 1.       Eliminate (for now) our implementation of the VHDL for.generate
> feature.

I opened a new thread about this.
 
> 2.       Eliminate (for now) the hierarchy probing feature of the
> language, ie. 'inst.subinst.subinst2.value = "100";'.  Again, I have
> difficulty seeing a case where this is necessary or desirable in a board
> design.

This feature can be quite useful in some situations. Here is an example. I 
have a design that uses switching regulators that have their voltage 
programmed by setting a pair of resistors in a certain ratio. There is all 
sorts of other complex stuff (inductors, other capacitors and resistors) 
that is necessary to hook up the regulator that doesn't change. I have to 
instance about 10 of these all with different voltages. The only part that 
needs to change is the resistor.

So my options are to bring the resistor connections out to ports in a 
subdesign, or use "heirarchy probing" to set the values of the resistors for 
each instance.

I could obviously design this without it, but this is one real-world example 
where it's useful.

(Sadly, the design is *actually* in DxDesigner, not in PHDL, but I've used 
PHDL to describe parts of it as a human communication mechanism).

> Is there a document on the wiki or in the repo for the language spec?
> Should I start one?

Unless anyone else says they're going to give it a go, sounds like we have a 
volunteer! =)

[phdl-devel] Instance Arrays (so called "Looping")

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

Guys,

Let's make a new thread to talk about looping.

Here's what looks like what we have so far is:

  * Arguments for eliminating looping:
    * It may be the source of a large amount of complexity in the language.
    * The syntax is not as immediately intuitive as the rest of PHDL.
    * It may not increase code density anyway.

  * Arguments for keeping looping:
    * The complexity it adds to the language is valuable in practice.
    * It doesn't make the language much more complex once you learn it.
    * It does increase code density if you use it right.

I do think either eliminating looping altogether, nor keeping looping 
exactly as is are satisfying solutions to everybody. But perhaps this is a 
part of the grammar we can fix! =)

Before we start bike-shedding over what the syntax looks like or why we do 
or don't like it as is, lets see if we can figure out what we want to get 
out of it. Here is what I see as the things we'd like to support:

  * Economy: instaniating multiple instances that largely have the same 
connections, without copy and paste, and without repeating ourselves in the 
code (both tedious and error prone).

  * Broadcast: hooking up each pin on each instance to the same thing. (This 
is currently our default syntax "pin = net".) This is a very common thing to 
do for common signals shared between an array of instances (e.g. power, 
ground, or clock to memory chips).

  * Vectorization: treating each pin of each instance as a vector/bus net. 
(This is currently our "combine(pin) = net" syntax). This is a very common 
thing to do to rip individual signals that vary over an array of instances 
(e.g. data, chip_select, address to memory chips).

  * Exceptions: making one instance in the array hook up differently than 
the others. (This is currently our "this(pin) = net" syntax). This is less 
common than the above, but gives a way to work with an array of instances 
with an *almost* regular connection structure).

I think all of these are important, because for most real examples (e.g. a 
set of memory chips) all three of latter features are necessary (broadcast, 
vectorization, expections), otherwise we can't use a loop at all and 
sacrifice the first feature (economy) and have to revert to cut and paste.

I have some ideas about how we can improve this syntax, but first let's 
discuss if this is really what we want to get out of looping. This this list 
complete? Are there more features that done fall in these groups? Should we 
argue that one of these features (e.g. expections) isn't worth supporting? 
Are there existing features of the language that make some of these features 
unnecessary (e.g. our "<net>" syntax vs. broadcast, but how does that effect 
vector nets?).

If we're interested in getting this whipped into shape, let's discuss!

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

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

On Tuesday, November 06, 2012 14:32:22 Brent Nelson wrote:
> What are people's feelings and thoughts?  Comments and flames welcomed. 
> Is there a version that others are going to use moving forward?  Our
> view that we would rather throw in as a group rather than have different
> efforts going on at this point.

Hi guys,

Let me just try to respond to this discussion in one big e-mail (I may snipe 
a few direct comments into other parts of the thread, but please look here 
if you're wondering about my vision in particular).

First of all, we should definitely try to work together, but that's really 
othogonal to what code is used and what people are working on. Right now 
what I see as the most difficult communication problem we have is that we 
may not all understand what each other's ultimate goals and plans are.

For *MY* point of view, the most important things we could possibly do right 
now is to define and start using a good intermediate format that is not tied 
to any specific language or technology, then work on ironing out a full 
specification of the PHDL language, without any particular bias towards the 
state of the implementation(s) will eventually support it.

Let me make some comments as I quote myself my e-mail a month ago when I 
proposed a project roadmap <201...@ic...> (nobody 
replied to this e-mail, BTW!):

On Wednesday, October 10, 2012 18:24:22 Wesley J. Landaker wrote:
> I'd propose the following roadmap:
> 
>   1. Create a document that defines how the PHDL compiler currently works
> (Joshua already started documenting the changes between PHDL 2.0 and PHDL
> 2.1).

We've got our grammar posted, and I've initiated some discussion on some 
particulars that I think need changes or work (no replies yet!).

Pete suggested tossing out instance arrays ("looping") which admittedly do 
have a bit of an ugly syntax compared to the rest of PHDL. I don't think we 
can toss looping, nor would we gain a whole lot by doing so *in general*, 
but maybe we should discuss the particulars of it.

>   2. Discuss and modify the above document until it sufficiently
> describes how we want the PHDL language to be. We don't want any major
> changes at this point, but we may need to clarify rules and semantics
> that currently are enforced by the compiler but are not implicit in the
> grammar.

I still think this is probably one of the most important places we can 
focus. We keep talking about implementation code bases, but seriously, 
implement WHAT?! We don't even really know what PHDL "is", until we write up 
a spec.

My goal would be to see a PHDL 3.0 (or 2.2 if it's really backwards 
compatible) specification that has nothing to do with any implementation, 
but just talks about what the language is.

I am even willing to *write* large partions of this document, but obviously 
either we need to try to work toward concensus as much as possible, 
otherwise people are going to feel like their being shut out and aren't 
going to want to keep working together.

>   3. Add to the above document the definiton of our generic netlist
> output format (e.g. our current XML *.net netlist output is probably a
> good choice, but maybe call it *.phdl_netlist or something).

This is the PHDL Intermediate Format effort I've been pushing. I actually 
think since this is *so* *much* *simpler* than PHDL, and can immediately be 
applies to existing implementations to allow more flexible back-end tools, 
that this is a really good place to start, even before we look at changes to 
PHDL, which is why I've drafted a spec and am hoping to get buy-in from all 
interested parties soon! =)

>   5. Now, we have the option of doing any or all of the following,
> possibly in parallel, possibly by different folks with different
> interests:
>   * Update the current PHDL 2.1 Eclipse-based compiler to
> PHDLv3, made to output only our generic format.
>   * Update the previous PHDL 2.0 plain antlr+java compiler to PHDLv3,
> made to output only our generic format.
>   * Create a new C++ implementation, made to output only our generic
> format.
>   * Create a new XYZ implementation, made to ... etc ... you get
> the idea.
> 6. At this point, we have made it possible for any compiler in
> any implementation language or environment to compile the language from
> .phdl to .phdl_netlist; these compilers can share code, or not, whatever
> best suits their implementations.
>   7. Convert our current netlist backends to all read from the
> .phdl_netlist format to output their individual formats (e.g. PADS,
> Eagle, Osmond, Altium, ad-hoc statistics generators, whatever people
> want to make). Like #5, all of these can be done, perhaps in parallel,
> by interested parties, in any implementation language they wish.

Once we have specifications written up (we know we input PHDL, and we know 
we output PHDLIF, and we know exactly what those are because they are 
specified well), we are in very good shape.

I think what code base we use to actually implement them is going to fall 
out somwhat naturally from who really is interested in pushing things along.

I see the following data points from discussion and impressions so far:

  * If BYU folks are going to keep being highly active, primary 
contributors, either the Eclipse+Xtext version vs. the much simpler 
Java+Antlr code base will decided mostly by them.

  * There seems to be a lot of suggestion that going to the PHDL 2.0 
implementation code base (Java + Antlr) is a good path. I think Pete and I 
both agree for sure that if we are goint to select any existing code base to 
move forward, that one has the most ... let's call it, "maintainability 
potential".

  * I will, regardless of any other code base decisions, want to generate 
back-end tools that read PHDLIF and do fun things with it (graphviz-based 
schematic generation, report generators for reviews, exploring possible 
hooks into Mentor's Tcl engine for auto-conversion into DxDesigner) in 
various pragmatic languages (C++, Python, Tcl).

  * If BYU folks as a group "drop the ball" so to speak in the long term 
(i.e. who is going to be working on this in, say, 2013 and 2014?), Pete and 
I will probably rather convert code and/or generate new code for, a simpler, 
more modular set of compiler tools, rather than a monolithic compiler with 
gobs of dependencies.

In the end, I think what we largely have is worries about long-term 
maintainability, versus short term worries about getting things done 
pragmatically and soon. There is no reason we can't attack both of these 
goals simultaneously. Pete mentioned "a friendly fork", which is one way to 
accomplish this goal while still ultimately working together on the project.

I honestly think we are premature working on any code at all until we get 
our specifications in order, but of course other folks may have different 
perspectives. (Example: Chuck, who I believe is firmly in the "guys, I have 
real production design, so whatever you do, DON'T BREAK IT" camp).

Finally, here are the advantage and disadvantages to the whole general plan 
of "first write specs, then go implement them":

> Advantages to this plan:
>   * We get a language spec out of it, which we need long term anyway.
>   * Parallel implementations are a sure sign of a more mature language.
>   * It devides up the work into modular pieces for easier contributions.
>   * It completely decouples frontends and backends for easier
> maintenance.
> 
> Disadvantages to this plan:
>   * We may have to temporarily break the current PHDL implementation.
>   * There may be a need to forgo partial features that aren't yet
> finished.
>   * We will have (at least temporarily) a less homogeneous code
> base.

There are alternatives, like continuing with the "the implementation is the 
specification" de-facto method we have right now. This was great for the 
first iteration, but it means that if we do fork any part of the code for 
any reason, we really have in effect stopped working together. I think this 
is where we have gotten into the idea that there is a either-or choice.

Re: [phdl-devel] intermediate format

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

On Friday, November 02, 2012 19:12:39 Wesley J. Landaker wrote:
> If anyone has any comments about this or the PHDLIF requirements I wrote
> up previously, let's hear them! =) In a few days I plan to write up a
> full specification and an accompanying working libphdlif reference
> implementation.

I've pushed the specification in commit 2f37495. In the end, I've made this 
as dirt simple as possible, so that it's trival to both generate and parse 
with any language, without using any frameworks or libraries.

I'm still planning to make a reference library to read and write this 
format, partially to illustrate it's function, but mostly to be real usable 
code for additional backend tools, but the specification as is I think is 
quite self-explanitory.

Do you guys like this format? Is anyone interested in making the existing 
PHDL code use this format? For example, either making the front-end write 
it, or the backends read it?

I don't think there are any holes, but it would be good to answer questions 
and iron out any concerns if anyone sees anything!

[phdl-devel] hierarchical packages

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

Josh

In my view the power of PHDL is in its very simplicity, it's anti-complexity if you will.  One of the big mistakes I see in industry is over-investment in libraries.  People think that they have capture all these great parts in a library and that will really help in the future.  The payoff will be in the future.  The problem with this view is that in the future I will use different parts for all the obvious reasons.  

I prefer the idea of just-in-time component creation.  PHDL syntax makes it super efficient to create new device definitions for instantiation therefore there is little reason to dig through libraries for a component.  Library components have to be carefully checked for correctness just like any other part so the savings is not great.  Libraries can often be hindrances to productivity because folks feel required to use components that are in some library.  I prefer to just type it in real quick because that is so easy in PHDL.  On the other hand, I do grab device definitions from previous designs that I know from experience are correct.  This results in practical re-use.

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.

So to answer your question, in my opinion, for PHDL, it does not make sense to add hierarchical capability to packages.

I think we are in a complexity hole on this open source project so I don't want to dig ourselves any deeper.

    Pete


Date: Sat, 10 Nov 2012 18:15:19 -0700
From: jos...@gm...
To: hd...@ho...; phd...@li...
Subject: Re: [phdl-devel] benefits of language simplicity?

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 		 	   		  

Re: [phdl-devel] benefits of language simplicity?

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

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

[phdl-devel] FW: benefits of language simplicity?

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

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



 		 	   		   		 	   		  

Re: [phdl-devel] benefits of language simplicity?

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

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

[phdl-devel] benefits of language simplicity?

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

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?



 		 	   		  

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

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

Hi Guys,

I think Josh hit the nail on the head – the elaboration is where the complexity comes in.  The grammar is pretty trivial – I am confident I could whack out a function 2.0 language parser in 2-3 evenings using Lex/Yacc or Flex/Bison.  The complexity comes later in the tool chain.

Thanks,

Brent




From: Joshua Mangelson <jos...@gm...<mailto:jos...@gm...>>
Date: Thursday, November 8, 2012 12:29 PM
To: peter dudley <hd...@ho...<mailto:hd...@ho...>>
Cc: "<phd...@li...<mailto:phd...@li...>>" <phd...@li...<mailto:phd...@li...>>
Subject: Re: [phdl-devel] [EXTERNAL] Re: PHDL Directions: Grammar, Tool, IF

I actually don't think that this is a major point that complicates the code. I would think that the major complicating part of the code comes at elaboration, which is when we take the inputted source code generate an in memory representation of the design which we can then walk in-order to create the netlist.

But Brad would probably be able to better explain than I would be able to as well.

In my opinion, the elaboration process as-well as validation (making sure the inputted syntax though valid, actually makes logical sense), are the two most complicated parts of the code.

Josh




On Thu, Nov 8, 2012 at 9:20 AM, peter dudley <hd...@ho...<mailto:hd...@ho...>> wrote:
That is pretty good, 5 lines instead of 16 and you don't have to individually enumerate the bus signal.

On the other hand, these days termination resistors are usually included inside the I/O of integrated circuits so this situation is getting rarer.

Also, fewer and fewer decoupling capacitors are required these days.  The big chips include much of the decoupling on their packages. Good power planes replace most of the smaller caps too. For an example look at the decoupling recommendations for Xilinx Virtex-6 FPGA's.

The question is how simple do we want to get to make this code maintainable as open-source.

Is it true that we can get very simple by eliminating the inst(N:M) syntax?

  Pete

________________________________
From: cw...@sa...<mailto:cw...@sa...>
To: jos...@gm...<mailto:jos...@gm...>; hd...@ho...<mailto:hd...@ho...>
CC: phd...@li...<mailto:phd...@li...>
Subject: RE: [EXTERNAL] Re: [phdl-devel] PHDL Directions: Grammar, Tool, IF
Date: Thu, 8 Nov 2012 15:09:29 +0000



Hey guys,



Just wanted to add my $.02 to the debate over inst loops. I actually used them quite a bit in the breadboard design I’m working on now for termination resistors and decoupling capacitors. For example I have quite a few statements like this:



                inst(15:0) Serdes_0_RXD_Series_Term of Resistor {

                                VALUE = "33";

                                combine(a) = SERDES_0_RXD;

                                combine(b) = SERDES_0_RXD_TERM;

                }



to implement 16 series termination resistors on a 16-bit data bus. I understand Pete’s point about simplifying the compiler, but as one of your early adopters I find this feature somewhat helpful and time-saving.



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<tel:%28505%29%20284-8019>
E-mail: cw...@sa...<mailto:cw...@sa...>



From: Joshua Mangelson [mailto:jos...@gm...<mailto:jos...@gm...>]
Sent: Wednesday, November 07, 2012 8:50 PM
To: Peter Dudley
Cc: phd...@li...<mailto:phd...@li...>
Subject: [EXTERNAL] Re: [phdl-devel] PHDL Directions: Grammar, Tool, IF



Hey Everybody,



Sorry this is so long, but there are alot of things that have been on my mind in the past few months about this project and I wanted to get it all out there so, we can have a discussion about what all our views are at this point.



I agree with the three alternatives that Dr. Nelson has suggested.



In my mind there are two major decisions that are the most important for us to make at this time, if we are all going to move forward in one direction:



1. Deciding on a "canonized" grammar.

2. Deciding on an existing implementation as a starting point, so we can move forward with the development we decided to use.



Here are my views with respect to these two issues:



1. The Grammar

I feel somewhat partial to the 2.1 grammar, it is the one that I have had the most experience with and the one that I feel has the most kinks worked out. Brad has been working on the project for more than year almost full time and all along the way has been finding little things here and there that could be a little better or that need a little fixing. The 2.1 grammar is the result of each of these fixes and all of this work.



That said, I'm not opposed to making slight modifications to the grammar before finalizing the language spec for the time being. It think we should have a discussion about specific changes to the grammar and once we come to a consensus in the next few days then begin working on finalizing the formal language specification, with:

  *   Grammar - or allowed syntax
  *   Detailed explanations of the interpretation of syntax
  *   Detailed explanations of the output that should be generated from the interpreted syntax
  *   Formats such as the PHDLIF spec that we have been discussing

With respect to Pete's comment about simplifying the grammar, it's ok with me if we try to simplify the grammar, especially with respect to the import/package rules. We need to have a good discussion about these two rules, especially if the consensus implementation choice is something other than eclipse/x-text. In eclipse/x-text namespaces and packages are automatically handled for you. In 2.1, the package and import rules replaced the include rule, because of the capabilities of eclipse. We need to have a discussion for the future language spec. We could either revert back to the include in the interest of simplicity or decide to try and write an implementation of the import/package rules because of the great capability it provides for organizing large numbers of device definitions.

With respect to the inst(15:0) feature of the language, I feel strongly that this rule is one of the strongest capabilities the language provides. When I first came on the project, what stood out to me most was that I could create 16 resistors and tie them to two 16-trace buses, with three lines of code rather than manually adding 16 resisters to a schematic. One of the first boards I was asked to redo the schematic for when I started, was Spartan6 Atlys Demo-board, it had 100s of resisters and caps and the array capability stood out to me as one of the fundamental features/capabilities of the language.

I also found the hierarchy capabilities and the ability to reach down into the hierarchy and modify attributes of a specific instance very useful, especially in the case where you have two sections of a board that are entirely identical except for the value of one resistor or capacitor being used as an rc filter for an audio jack or something similar. Though, this is probably less critical than the inst() array rule above as it is used much less frequently. We could leave it unimplemented or remove it from the grammar for simplicity sake, if necessary.

What do each of you think about these three specific parts of the grammar, as well as any other specific changes necessary? It would be good to know what everyone is thinking with respect to specific grammar rules/modifications. I also have another comment or two about a possible modification to the import/package rules, but it would probably be good to see what each of you think about the rule as a whole before suggesting any modifications.

As a whole I think, the 2.1 grammar (with a few modifications as per this discussion) is probably the best option, because it is the end result of a year or so of progress.

2. Implementation Choice to use as a Starting Point

As Dr. Nelson was saying, I think the best options we have for an implementation starting point moving forward, would be either the 2.0 or the 2.1-plugin existing compilers.  We have been talking about opensource for quite some time and I think we've been learning a whole lot thanks to Wes and it seems like Pete might have some experience in this area as well. Here at BYU, we've all read parts of the book The Cathedral and The Bazaar, as Wes suggested. What has stood out to me most about the strengths of the Bazaar system is that you keep things simple and make it available so that as many people as possible can start using (and developing) the tool if they so wish. One of the strengths of Git as a revision control system is that it allows for individual people to clone the repository and take their own initiatives in whatever direction they so desire. This is really good because it allows people to take whatever paths they so decide and try out any ideas they have with the option of merging them back into the main repository if their idea turns out to work out as they intended.

I think this is definitely the direction we should be moving as we are hoping for PHDL to catch on and continue to grow. I feel that this is the main reason we are also pushing for specific language definitions and specs, independent of implementation.

However, currently since we only have a user/developer base of about 4-6, it seems to me that it would probably not be a very good idea for us to split the development into two different lines of progress at this point. There is a possibility that this would result in PHDL only becoming a tool used by a few people here and there, and never really expanding or catching on. The best thing would be for us all to come to a consensus as a group and move forward working together on the development in a common direction at least until we have a common, maintainable, working implementation of whatever we determine the language specifications to be.  Once we have this stable, working, "main" repository created, then the project will be able to sustain itself, if in the future, people desire to move in individual directions.

I think that it is with this in mind, that we should make a choice between either the 2.0 or 2.1 implementations as a starting point for our 3.0 version.
Starting over with a completely new version of the compiler would probably take months to do at this point when you take into account the complexity that is required to perform hierarchy and elaboration correctly with no errors.


2.1 is implemented in x-text, a language specifically created for implementing languages in eclipse. It is the most debugged/tested and best working version of the compiler we currently have, but it would also be hard for anyone not interested in learning x-text/eclipse to develop or maintain. Due to a possibly significant learning curve required for development within eclipse, it seems that it would also be quite difficult for anyone else besides those currently working on the project to jump in and begin development as we hope to happen in the future.
Though it seems that x-text also does more for you even than Antlr does, it made the language implementation much easier. Brad commented often about things that were automatically taken care of in x-text that he had spent long hours implementing in Antlr.

Brad, could you comment about this? You can probably explain more about the possible learning curve as well as the benefits of implementation in x-text than anyone else.


2.0 is implemented in Antlr. As I understand it, a big benefit of Antlr is that almost anyone who has taken a compiler class or who has done any work with compilers/grammars will have used Antlr. I'm still learning quite a bit. I am not as familiar with Antlr as I am with x-text now, (because this is the first real exposure I've had to compilers) but I understand that most potential developers will have either experience with Antlr or no experience with compilers.

One problem once again with choosing the 2.0 compiler is the loss of an entire summer of work by both me and Brad of testing, debugging, and fixing bugs in the 2.1 compiler. Over the course of the summer we've found many bugs in the 2.1 compiler implementation/grammar and have been fixing them all along the way. There is no way of knowing how many of these bugs (especially with hierarchy) are possibly lurking still in the 2.0 version of the compiler.

We do have a functional working board created with the 2.0 version of the compiler!, but this design also did not use hierarchy which leaves room to worry slightly about bugs that may be lurking within the compiler.

The view that seems the best in my view would be to use the 2.0 version of the compiler, and update it and document/test it to comply with a grammar similar to the 2.1 version of the grammar. This would allow for simplicity of development, while at the same time preserving at least some of the the work/time that Brad has applied in the past 4-5 months.



I think that we should come to a conclusion about what each of us think in these areas and then after this discussion, begin working on the specific language spec.



If everyone could comment and let me know what you think, that would be great.



Thanks,



Josh



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

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

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

I actually don't think that this is a major point that complicates the
code. I would think that the major complicating part of the code comes at
elaboration, which is when we take the inputted source code generate an in
memory representation of the design which we can then walk in-order to
create the netlist.

But Brad would probably be able to better explain than I would be able to
as well.

In my opinion, the elaboration process as-well as validation (making sure
the inputted syntax though valid, actually makes logical sense), are the
two most complicated parts of the code.

Josh




On Thu, Nov 8, 2012 at 9:20 AM, peter dudley <hd...@ho...> wrote:

>  That is pretty good, 5 lines instead of 16 and you don't have to
> individually enumerate the bus signal.
>
> On the other hand, these days termination resistors are usually included
> inside the I/O of integrated circuits so this situation is getting rarer.
>
> Also, fewer and fewer decoupling capacitors are required these days.  The
> big chips include much of the decoupling on their packages. Good power
> planes replace most of the smaller caps too. For an example look at the
> decoupling recommendations for Xilinx Virtex-6 FPGA's.
>
> The question is how simple do we want to get to make this code
> maintainable as open-source.
>
> Is it true that we can get very simple by eliminating the inst(N:M) syntax?
>
>   Pete
>
> ------------------------------
> From: cw...@sa...
> To: jos...@gm...; hd...@ho...
> CC: phd...@li...
> Subject: RE: [EXTERNAL] Re: [phdl-devel] PHDL Directions: Grammar, Tool, IF
> Date: Thu, 8 Nov 2012 15:09:29 +0000
>
>
>  Hey guys,
>
>
>
> Just wanted to add my $.02 to the debate over inst loops. I actually used
> them quite a bit in the breadboard design I’m working on now for
> termination resistors and decoupling capacitors. For example I have quite a
> few statements like this:
>
>
>
>                 inst(15:0) Serdes_0_RXD_Series_Term of Resistor {
>
>                                 VALUE = "33";
>
>                                 combine(a) = SERDES_0_RXD;
>
>                                 combine(b) = SERDES_0_RXD_TERM;
>
>                 }
>
>
>
> to implement 16 series termination resistors on a 16-bit data bus. I
> understand Pete’s point about simplifying the compiler, but as one of your
> early adopters I find this feature somewhat helpful and time-saving.
>
>
>
> 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...
>
>
>
> *From:* Joshua Mangelson [mailto:jos...@gm...]
> *Sent:* Wednesday, November 07, 2012 8:50 PM
> *To:* Peter Dudley
> *Cc:* phd...@li...
> *Subject:* [EXTERNAL] Re: [phdl-devel] PHDL Directions: Grammar, Tool, IF
>
>
>
> Hey Everybody,
>
>
>
> Sorry this is so long, but there are alot of things that have been on my
> mind in the past few months about this project and I wanted to get it all
> out there so, we can have a discussion about what all our views are at this
> point.
>
>
>
> I agree with the three alternatives that Dr. Nelson has suggested.
>
>
>
> In my mind there are two major decisions that are the most important for
> us to make at this time, if we are all going to move forward in one
> direction:
>
>
>
> 1. Deciding on a "canonized" grammar.
>
> 2. Deciding on an existing implementation as a starting point, so we can
> move forward with the development we decided to use.
>
>
>
> Here are my views with respect to these two issues:
>
>
>
> 1. The Grammar
>
>  I feel somewhat partial to the 2.1 grammar, it is the one that I have
> had the most experience with and the one that I feel has the most kinks
> worked out. Brad has been working on the project for more than year almost
> full time and all along the way has been finding little things here and
> there that could be a little better or that need a little fixing. The 2.1
> grammar is the result of each of these fixes and all of this work.
>
>
>
> That said, I'm not opposed to making slight modifications to the grammar
> before finalizing the language spec for the time being. It think we should
> have a discussion about specific changes to the grammar and once we come to
> a consensus in the next few days then begin working on finalizing the
> formal language specification, with:
>
>
>    - Grammar - or allowed syntax
>    - Detailed explanations of the interpretation of syntax
>    - Detailed explanations of the output that should be generated from
>    the interpreted syntax
>    - Formats such as the PHDLIF spec that we have been discussing
>
>   With respect to Pete's comment about simplifying the grammar, it's ok
> with me if we try to simplify the grammar, especially with respect to the*import/package
> * rules. We need to have a good discussion about these two rules,
> especially if the consensus implementation choice is something other than
> eclipse/x-text. In eclipse/x-text namespaces and packages are automatically
> handled for you. In 2.1, the *package* and *import* rules replaced the *
> include* rule, because of the capabilities of eclipse. We need to have a
> discussion for the future language spec. We could either revert back to the
> * include *in the interest of simplicity or decide to try and write an
> implementation of the *import/package* rules because of the great
> capability it provides for organizing large numbers of device definitions.
>
> With respect to the* inst(15:0)* feature of the language, I feel strongly
> that this rule is one of the strongest capabilities the language provides.
> When I first came on the project, what stood out to me most was that I
> could create 16 resistors and tie them to two 16-trace buses, with three
> lines of code rather than manually adding 16 resisters to a schematic. One
> of the first boards I was asked to redo the schematic for when I started,
> was Spartan6 Atlys Demo-board, it had 100s of resisters and caps and the
> array capability stood out to me as one of the fundamental
> features/capabilities of the language.
>
> I also found the hierarchy capabilities and the ability to reach down into
> the hierarchy and modify attributes of a specific instance very useful,
> especially in the case where you have two sections of a board that are
> entirely identical except for the value of one resistor or capacitor being
> used as an rc filter for an audio jack or something similar. Though, this
> is probably less critical than the inst() array rule above as it is used
> much less frequently. We could leave it unimplemented or remove it from the
> grammar for simplicity sake, if necessary.
>
> What do each of you think about these three specific parts of the grammar,
> as well as any other specific changes necessary? It would be good to know
> what everyone is thinking with respect to specific grammar
> rules/modifications. I also have another comment or two about a possible
> modification to the *import/package* rules, but it would probably be good
> to see what each of you think about the rule as a whole before suggesting
> any modifications.
>
> As a whole I think, the 2.1 grammar (with a few modifications as per this
> discussion) is probably the best option, because it is the end result of a
> year or so of progress.
>
> 2. Implementation Choice to use as a Starting Point
>
>
> As Dr. Nelson was saying, I think the best options we have for an
> implementation starting point moving forward, would be either the 2.0 or
> the 2.1-plugin existing compilers.  We have been talking about opensource
> for quite some time and I think we've been learning a whole lot thanks to
> Wes and it seems like Pete might have some experience in this area as well.
> Here at BYU, we've all read parts of the book The Cathedral and The Bazaar,
> as Wes suggested. What has stood out to me most about the strengths of the
> Bazaar system is that you keep things simple and make it available so that
> as many people as possible can start using (and developing) the tool if
> they so wish. One of the strengths of Git as a revision control system is
> that it allows for individual people to clone the repository and take their
> own initiatives in whatever direction they so desire. This is really good
> because it allows people to take whatever paths they so decide and try out
> any ideas they have with the option of merging them back into the main
> repository if their idea turns out to work out as they intended.
>
> I think this is definitely the direction we should be moving as we are
> hoping for PHDL to catch on and continue to grow. I feel that this is the
> main reason we are also pushing for specific language definitions and
> specs, independent of implementation.
>
> However, currently since we only have a user/developer base of about 4-6,
> it seems to me that it would probably not be a very good idea for us to
> split the development into two different lines of progress at this point.
> There is a possibility that this would result in PHDL only becoming a tool
> used by a few people here and there, and never really expanding or catching
> on. The best thing would be for us all to come to a consensus as a group
> and move forward working together on the development in a common direction
> at least until we have a common, maintainable, working implementation of
> whatever we determine the language specifications to be.  Once we have this
> stable, working, "main" repository created, then the project will be able
> to sustain itself, if in the future, people desire to move in individual
> directions.
>
> I think that it is with this in mind, that we should make a choice between
> either the 2.0 or 2.1 implementations as a starting point for our 3.0
> version.
> Starting over with a completely new version of the compiler would probably
> take months to do at this point when you take into account the complexity
> that is required to perform hierarchy and elaboration correctly with no
> errors.
>
>
> 2.1 is implemented in x-text, a language specifically created for
> implementing languages in eclipse. It is the most debugged/tested and best
> working version of the compiler we currently have, but it would also be
> hard for anyone not interested in learning x-text/eclipse to develop or
> maintain. Due to a possibly significant learning curve required for
> development within eclipse, it seems that it would also be quite difficult
> for anyone else besides those currently working on the project to jump in
> and begin development as we hope to happen in the future.
> Though it seems that x-text also does more for you even than Antlr does,
> it made the language implementation much easier. Brad commented often about
> things that were automatically taken care of in x-text that he had spent
> long hours implementing in Antlr.
>
> Brad, could you comment about this? You can probably explain more about
> the possible learning curve as well as the benefits of implementation in
> x-text than anyone else.
>
>
> 2.0 is implemented in Antlr. As I understand it, a big benefit of Antlr is
> that almost anyone who has taken a compiler class or who has done any work
> with compilers/grammars will have used Antlr. I'm still learning quite a
> bit. I am not as familiar with Antlr as I am with x-text now, (because this
> is the first real exposure I've had to compilers) but I understand that
> most potential developers will have either experience with Antlr or no
> experience with compilers.
>
> One problem once again with choosing the 2.0 compiler is the loss of an
> entire summer of work by both me and Brad of testing, debugging, and fixing
> bugs in the 2.1 compiler. Over the course of the summer we've found many
> bugs in the 2.1 compiler implementation/grammar and have been fixing them
> all along the way. There is no way of knowing how many of these bugs
> (especially with hierarchy) are possibly lurking still in the 2.0 version
> of the compiler.
>
> We do have a functional working board created with the 2.0 version of the
> compiler!, but this design also did not use hierarchy which leaves room to
> worry slightly about bugs that may be lurking within the compiler.
>
> The view that seems the best in my view would be to use the 2.0 version of
> the compiler, and update it and document/test it to comply with a grammar
> similar to the 2.1 version of the grammar. This would allow for simplicity
> of development, while at the same time preserving at least some of the the
> work/time that Brad has applied in the past 4-5 months.
>
>
>
> I think that we should come to a conclusion about what each of us think in
> these areas and then after this discussion, begin working on the specific
> language spec.
>
>
>
> If everyone could comment and let me know what you think, that would be
> great.
>
>
>
> Thanks,
>
>
>
> Josh
>
>
>
>
>
> ------------------------------------------------------------------------------
> 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] [EXTERNAL] Re: PHDL Directions: Grammar, Tool, IF

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

That is pretty good, 5 lines instead of 16 and you don't have to individually enumerate the bus signal.

On the other hand, these days termination resistors are usually included inside the I/O of integrated circuits so this situation is getting rarer.

Also, fewer and fewer decoupling capacitors are required these days.  The big chips include much of the decoupling on their packages. Good power planes replace most of the smaller caps too. For an example look at the decoupling recommendations for Xilinx Virtex-6 FPGA's.  

The question is how simple do we want to get to make this code maintainable as open-source.  

Is it true that we can get very simple by eliminating the inst(N:M) syntax?

  Pete

From: cw...@sa...
To: jos...@gm...; hd...@ho...
CC: phd...@li...
Subject: RE: [EXTERNAL] Re: [phdl-devel] PHDL Directions: Grammar, Tool, IF
Date: Thu, 8 Nov 2012 15:09:29 +0000









Hey guys,
 
Just wanted to add my $.02 to the debate over inst loops. I actually used them quite a bit in the breadboard design I’m working on now for termination resistors
 and decoupling capacitors. For example I have quite a few statements like this:
 
                inst(15:0) Serdes_0_RXD_Series_Term of Resistor {
                                VALUE = "33";
                                combine(a) = SERDES_0_RXD;
                                combine(b) = SERDES_0_RXD_TERM;
                }
 
to implement 16 series termination resistors on a 16-bit data bus. I understand Pete’s point about simplifying the compiler, but as one of your early adopters
 I find this feature somewhat helpful and time-saving.
 
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...

 
From: Joshua Mangelson [mailto:jos...@gm...]


Sent: Wednesday, November 07, 2012 8:50 PM

To: Peter Dudley

Cc: phd...@li...

Subject: [EXTERNAL] Re: [phdl-devel] PHDL Directions: Grammar, Tool, IF
 
Hey Everybody,

 


Sorry this is so long, but there are alot of things that have been on my mind in the past few months about this project and I wanted to get it all out there so, we can have a discussion about what all our views are at this point.


 


I agree with the three alternatives that Dr. Nelson has suggested. 


 


In my mind there are two major decisions that are the most important for us to make at this time, if we are all going to move forward in one direction:


 


1. Deciding on a "canonized" grammar.


2. Deciding on an existing implementation as a starting point, so we can move forward with the development we decided to use.


 


Here are my views with respect to these two issues:


 


1. The Grammar



I feel somewhat partial to the 2.1 grammar, it is the one that I have had the most experience with and the one that I feel has the most kinks worked out. Brad has been working on the project for more than year almost full time and all along
 the way has been finding little things here and there that could be a little better or that need a little fixing. The 2.1 grammar is the result of each of these fixes and all of this work. 


 


That said, I'm not opposed to making slight modifications to the grammar before finalizing the language spec for the time being. It think we should have a discussion about specific changes to the grammar and once we come to a consensus
 in the next few days then begin working on finalizing the formal language specification, with:









Grammar - or allowed syntax
Detailed explanations of the interpretation of syntax
Detailed explanations of the output that should be generated from the interpreted syntax
Formats such as the PHDLIF spec that we have been discussing




With respect to Pete's comment about simplifying the grammar, it's ok with me if we try to simplify the grammar, especially with respect to the import/package rules. We need to have a good discussion
 about these two rules, especially if the consensus implementation choice is something other than eclipse/x-text. In eclipse/x-text namespaces and packages are automatically handled for you. In 2.1, the
package and import rules replaced the include rule, because of the capabilities of eclipse. We need to have a discussion for the future language spec. We could either revert back to the include
in the interest of simplicity or decide to try and write an implementation of the
import/package rules because of the great capability it provides for organizing large numbers of device definitions. 



With respect to the inst(15:0) feature of the language, I feel strongly that this rule is one of the strongest capabilities the language provides. When I first came on the project, what stood out to me most was that I could create 16 resistors and tie
 them to two 16-trace buses, with three lines of code rather than manually adding 16 resisters to a schematic. One of the first boards I was asked to redo the schematic for when I started, was Spartan6 Atlys Demo-board, it had 100s of resisters and caps and
 the array capability stood out to me as one of the fundamental features/capabilities of the language.



I also found the hierarchy capabilities and the ability to reach down into the hierarchy and modify attributes of a specific instance very useful, especially in the case where you have two sections of a board that are entirely identical except for the value
 of one resistor or capacitor being used as an rc filter for an audio jack or something similar. Though, this is probably less critical than the inst() array rule above as it is used much less frequently. We could leave it unimplemented or remove it from the
 grammar for simplicity sake, if necessary.



What do each of you think about these three specific parts of the grammar, as well as any other specific changes necessary? It would be good to know what everyone is thinking with respect to specific grammar rules/modifications. I also have another comment
 or two about a possible modification to the import/package rules, but it would probably be good to see what each of you think about the rule as a whole before suggesting any modifications.



As a whole I think, the 2.1 grammar (with a few modifications as per this discussion) is probably the best option, because it is the end result of a year or so of progress.

2. Implementation Choice to use as a Starting Point




As Dr. Nelson was saying, I think the best options we have for an implementation starting point moving forward, would be either the 2.0 or the 2.1-plugin existing compilers.  We have been talking about opensource for quite some time and I think we've been learning
 a whole lot thanks to Wes and it seems like Pete might have some experience in this area as well. Here at BYU, we've all read parts of the book The Cathedral and The Bazaar, as Wes suggested. What has stood out to me most about the strengths of the Bazaar
 system is that you keep things simple and make it available so that as many people as possible can start using (and developing) the tool if they so wish. One of the strengths of Git as a revision control system is that it allows for individual people to clone
 the repository and take their own initiatives in whatever direction they so desire. This is really good because it allows people to take whatever paths they so decide and try out any ideas they have with the option of merging them back into the main repository
 if their idea turns out to work out as they intended.



I think this is definitely the direction we should be moving as we are hoping for PHDL to catch on and continue to grow. I feel that this is the main reason we are also pushing for specific language definitions and specs, independent of implementation.



However, currently since we only have a user/developer base of about 4-6, it seems to me that it would probably not be a very good idea for us to split the development into two different lines of progress at this point. There is a possibility that this would
 result in PHDL only becoming a tool used by a few people here and there, and never really expanding or catching on. The best thing would be for us all to come to a consensus as a group and move forward working together on the development in a common direction
 at least until we have a common, maintainable, working implementation of whatever we determine the language specifications to be.  Once we have this stable, working, "main" repository created, then the project will be able to sustain itself, if in the future,
 people desire to move in individual directions.



I think that it is with this in mind, that we should make a choice between either the 2.0 or 2.1 implementations as a starting point for our 3.0 version.


Starting over with a completely new version of the compiler would probably take months to do at this point when you take into account the complexity that is required to perform hierarchy and elaboration correctly with no errors. 





2.1 is implemented in x-text, a language specifically created for implementing languages in eclipse. It is the most debugged/tested and best working version of the compiler we currently have, but it would also be hard for anyone not interested in learning x-text/eclipse
 to develop or maintain. Due to a possibly significant learning curve required for development within eclipse, it seems that it would also be quite difficult for anyone else besides those currently working on the project to jump in and begin development as
 we hope to happen in the future.

Though it seems that x-text also does more for you even than Antlr does, it made the language implementation much easier. Brad commented often about things that were automatically taken care of in x-text that he had spent long hours implementing in Antlr.



Brad, could you comment about this? You can probably explain more about the possible learning curve as well as the benefits of implementation in x-text than anyone else.





2.0 is implemented in Antlr. As I understand it, a big benefit of Antlr is that almost anyone who has taken a compiler class or who has done any work with compilers/grammars will have used Antlr. I'm still learning quite a bit. I am not as familiar with Antlr
 as I am with x-text now, (because this is the first real exposure I've had to compilers) but I understand that most potential developers will have either experience with Antlr or no experience with compilers. 



One problem once again with choosing the 2.0 compiler is the loss of an entire summer of work by both me and Brad of testing, debugging, and fixing bugs in the 2.1 compiler. Over the course of the summer we've found many bugs in the 2.1 compiler implementation/grammar
 and have been fixing them all along the way. There is no way of knowing how many of these bugs (especially with hierarchy) are possibly lurking still in the 2.0 version of the compiler.



We do have a functional working board created with the 2.0 version of the compiler!, but this design also did not use hierarchy which leaves room to worry slightly about bugs that may be lurking within the compiler.

The view that seems the best in my view would be to use the 2.0 version of the compiler, and update it and document/test it to comply with a grammar similar to the 2.1 version of the grammar. This would allow for simplicity of development,
 while at the same time preserving at least some of the the work/time that Brad has applied in the past 4-5 months.


 


I think that we should come to a conclusion about what each of us think in these areas and then after this discussion, begin working on the specific language spec.


 


If everyone could comment and let me know what you think, that would be great.


 


Thanks,


 


Josh










 		 	   		  

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

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

Hey guys,

Just wanted to add my $.02 to the debate over inst loops. I actually used them quite a bit in the breadboard design I'm working on now for termination resistors and decoupling capacitors. For example I have quite a few statements like this:

                inst(15:0) Serdes_0_RXD_Series_Term of Resistor {
                                VALUE = "33";
                                combine(a) = SERDES_0_RXD;
                                combine(b) = SERDES_0_RXD_TERM;
                }

to implement 16 series termination resistors on a 16-bit data bus. I understand Pete's point about simplifying the compiler, but as one of your early adopters I find this feature somewhat helpful and time-saving.

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

From: Joshua Mangelson [mailto:jos...@gm...]
Sent: Wednesday, November 07, 2012 8:50 PM
To: Peter Dudley
Cc: phd...@li...
Subject: [EXTERNAL] Re: [phdl-devel] PHDL Directions: Grammar, Tool, IF

Hey Everybody,

Sorry this is so long, but there are alot of things that have been on my mind in the past few months about this project and I wanted to get it all out there so, we can have a discussion about what all our views are at this point.

I agree with the three alternatives that Dr. Nelson has suggested.

In my mind there are two major decisions that are the most important for us to make at this time, if we are all going to move forward in one direction:

1. Deciding on a "canonized" grammar.
2. Deciding on an existing implementation as a starting point, so we can move forward with the development we decided to use.

Here are my views with respect to these two issues:

1. The Grammar
I feel somewhat partial to the 2.1 grammar, it is the one that I have had the most experience with and the one that I feel has the most kinks worked out. Brad has been working on the project for more than year almost full time and all along the way has been finding little things here and there that could be a little better or that need a little fixing. The 2.1 grammar is the result of each of these fixes and all of this work.

That said, I'm not opposed to making slight modifications to the grammar before finalizing the language spec for the time being. It think we should have a discussion about specific changes to the grammar and once we come to a consensus in the next few days then begin working on finalizing the formal language specification, with:

  *   Grammar - or allowed syntax
  *   Detailed explanations of the interpretation of syntax
  *   Detailed explanations of the output that should be generated from the interpreted syntax
  *   Formats such as the PHDLIF spec that we have been discussing
With respect to Pete's comment about simplifying the grammar, it's ok with me if we try to simplify the grammar, especially with respect to the import/package rules. We need to have a good discussion about these two rules, especially if the consensus implementation choice is something other than eclipse/x-text. In eclipse/x-text namespaces and packages are automatically handled for you. In 2.1, the package and import rules replaced the include rule, because of the capabilities of eclipse. We need to have a discussion for the future language spec. We could either revert back to the include in the interest of simplicity or decide to try and write an implementation of the import/package rules because of the great capability it provides for organizing large numbers of device definitions.

With respect to the inst(15:0) feature of the language, I feel strongly that this rule is one of the strongest capabilities the language provides. When I first came on the project, what stood out to me most was that I could create 16 resistors and tie them to two 16-trace buses, with three lines of code rather than manually adding 16 resisters to a schematic. One of the first boards I was asked to redo the schematic for when I started, was Spartan6 Atlys Demo-board, it had 100s of resisters and caps and the array capability stood out to me as one of the fundamental features/capabilities of the language.

I also found the hierarchy capabilities and the ability to reach down into the hierarchy and modify attributes of a specific instance very useful, especially in the case where you have two sections of a board that are entirely identical except for the value of one resistor or capacitor being used as an rc filter for an audio jack or something similar. Though, this is probably less critical than the inst() array rule above as it is used much less frequently. We could leave it unimplemented or remove it from the grammar for simplicity sake, if necessary.

What do each of you think about these three specific parts of the grammar, as well as any other specific changes necessary? It would be good to know what everyone is thinking with respect to specific grammar rules/modifications. I also have another comment or two about a possible modification to the import/package rules, but it would probably be good to see what each of you think about the rule as a whole before suggesting any modifications.

As a whole I think, the 2.1 grammar (with a few modifications as per this discussion) is probably the best option, because it is the end result of a year or so of progress.
2. Implementation Choice to use as a Starting Point

As Dr. Nelson was saying, I think the best options we have for an implementation starting point moving forward, would be either the 2.0 or the 2.1-plugin existing compilers.  We have been talking about opensource for quite some time and I think we've been learning a whole lot thanks to Wes and it seems like Pete might have some experience in this area as well. Here at BYU, we've all read parts of the book The Cathedral and The Bazaar, as Wes suggested. What has stood out to me most about the strengths of the Bazaar system is that you keep things simple and make it available so that as many people as possible can start using (and developing) the tool if they so wish. One of the strengths of Git as a revision control system is that it allows for individual people to clone the repository and take their own initiatives in whatever direction they so desire. This is really good because it allows people to take whatever paths they so decide and try out any ideas they have with the option of merging them back into the main repository if their idea turns out to work out as they intended.

I think this is definitely the direction we should be moving as we are hoping for PHDL to catch on and continue to grow. I feel that this is the main reason we are also pushing for specific language definitions and specs, independent of implementation.

However, currently since we only have a user/developer base of about 4-6, it seems to me that it would probably not be a very good idea for us to split the development into two different lines of progress at this point. There is a possibility that this would result in PHDL only becoming a tool used by a few people here and there, and never really expanding or catching on. The best thing would be for us all to come to a consensus as a group and move forward working together on the development in a common direction at least until we have a common, maintainable, working implementation of whatever we determine the language specifications to be.  Once we have this stable, working, "main" repository created, then the project will be able to sustain itself, if in the future, people desire to move in individual directions.

I think that it is with this in mind, that we should make a choice between either the 2.0 or 2.1 implementations as a starting point for our 3.0 version.
Starting over with a completely new version of the compiler would probably take months to do at this point when you take into account the complexity that is required to perform hierarchy and elaboration correctly with no errors.


2.1 is implemented in x-text, a language specifically created for implementing languages in eclipse. It is the most debugged/tested and best working version of the compiler we currently have, but it would also be hard for anyone not interested in learning x-text/eclipse to develop or maintain. Due to a possibly significant learning curve required for development within eclipse, it seems that it would also be quite difficult for anyone else besides those currently working on the project to jump in and begin development as we hope to happen in the future.
Though it seems that x-text also does more for you even than Antlr does, it made the language implementation much easier. Brad commented often about things that were automatically taken care of in x-text that he had spent long hours implementing in Antlr.

Brad, could you comment about this? You can probably explain more about the possible learning curve as well as the benefits of implementation in x-text than anyone else.


2.0 is implemented in Antlr. As I understand it, a big benefit of Antlr is that almost anyone who has taken a compiler class or who has done any work with compilers/grammars will have used Antlr. I'm still learning quite a bit. I am not as familiar with Antlr as I am with x-text now, (because this is the first real exposure I've had to compilers) but I understand that most potential developers will have either experience with Antlr or no experience with compilers.

One problem once again with choosing the 2.0 compiler is the loss of an entire summer of work by both me and Brad of testing, debugging, and fixing bugs in the 2.1 compiler. Over the course of the summer we've found many bugs in the 2.1 compiler implementation/grammar and have been fixing them all along the way. There is no way of knowing how many of these bugs (especially with hierarchy) are possibly lurking still in the 2.0 version of the compiler.

We do have a functional working board created with the 2.0 version of the compiler!, but this design also did not use hierarchy which leaves room to worry slightly about bugs that may be lurking within the compiler.
The view that seems the best in my view would be to use the 2.0 version of the compiler, and update it and document/test it to comply with a grammar similar to the 2.1 version of the grammar. This would allow for simplicity of development, while at the same time preserving at least some of the the work/time that Brad has applied in the past 4-5 months.

I think that we should come to a conclusion about what each of us think in these areas and then after this discussion, begin working on the specific language spec.

If everyone could comment and let me know what you think, that would be great.

Thanks,

Josh

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

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

Guys,

 

Package/Libraries

 

I really like the idea of having packages.  In fact I would like the ability
to control the package right at the instantiation line.  For example I would
like to be able to say this.

 

    inst C3  of foo_package.capnp_0603 { refdes="C3";  value="1UF/X7R/10V";
a=+1V5;  b=gnd; };

 

Question: Is there a way we can keep the package capability yet make it
simple to use and implement?

 

Mea Culpa

 

I know I pushed for include statements early on and now I like packages.  My
goal was to make everything super simple to use and implement.  Einstein
said, "Make your solution as simple as possible and no simpler."  Well I
pushed for too simple at the beginning.

 

INST Loops

 

On the inst(15:0) syntax I still don't see many useful applications where it
makes sense.  Also, my gut tells me that 90% of the compiler complexity
comes from that one feature.

 

Here is my reasoning. Instantiation of a resistor or capacitor requires one
line of code.  On that one line of code you can control all the attributes
and all the connections so the equation for lines of code is LC = N, where N
is the number of components.

 

Inside an inst loop you need two lines to start the loop and an additional
line of code for each an additional line of code for each attribute or
connection you want to control.  This means that LC = 2+N*A, where A is the
number of attributes or connections you want to control on each instance.
If you are instantiating 16 devices and want to control just one attribute
per device the lines of code are LC = 2+1*16 = 18.  Without the inst loop we
could do it in 16 lines.

 

Also, inst loop syntax can get a little complicated and can result in
component names that are a little bit machine generated in appearance.

 

Implementation

 

If it is true that most of the complexity of the compiler can go away by
just removing the inst loop feature then the implementation options open up.


 

Question: If we are able to achieve a major simplification of the language,
does it still make sense to start with one of our existing implementations
and cut it down or start over fresh?

 

    Pete

 

From: Joshua Mangelson [mailto:jos...@gm...] 
Sent: Thursday, November 08, 2012 4:50 AM
To: Peter Dudley
Cc: phd...@li...
Subject: Re: [phdl-devel] PHDL Directions: Grammar, Tool, IF

 

Hey Everybody,

 

Sorry this is so long, but there are alot of things that have been on my
mind in the past few months about this project and I wanted to get it all
out there so, we can have a discussion about what all our views are at this
point.

 

I agree with the three alternatives that Dr. Nelson has suggested. 

 

In my mind there are two major decisions that are the most important for us
to make at this time, if we are all going to move forward in one direction:

 

1. Deciding on a "canonized" grammar.

2. Deciding on an existing implementation as a starting point, so we can
move forward with the development we decided to use.

 

Here are my views with respect to these two issues:

 

1. The Grammar

I feel somewhat partial to the 2.1 grammar, it is the one that I have had
the most experience with and the one that I feel has the most kinks worked
out. Brad has been working on the project for more than year almost full
time and all along the way has been finding little things here and there
that could be a little better or that need a little fixing. The 2.1 grammar
is the result of each of these fixes and all of this work. 

 

That said, I'm not opposed to making slight modifications to the grammar
before finalizing the language spec for the time being. It think we should
have a discussion about specific changes to the grammar and once we come to
a consensus in the next few days then begin working on finalizing the formal
language specification, with:

*	Grammar - or allowed syntax
*	Detailed explanations of the interpretation of syntax
*	Detailed explanations of the output that should be generated from
the interpreted syntax
*	Formats such as the PHDLIF spec that we have been discussing

With respect to Pete's comment about simplifying the grammar, it's ok with
me if we try to simplify the grammar, especially with respect to the
import/package rules. We need to have a good discussion about these two
rules, especially if the consensus implementation choice is something other
than eclipse/x-text. In eclipse/x-text namespaces and packages are
automatically handled for you. In 2.1, the package and import rules replaced
the include rule, because of the capabilities of eclipse. We need to have a
discussion for the future language spec. We could either revert back to the
include in the interest of simplicity or decide to try and write an
implementation of the import/package rules because of the great capability
it provides for organizing large numbers of device definitions. 

With respect to the inst(15:0) feature of the language, I feel strongly that
this rule is one of the strongest capabilities the language provides. When I
first came on the project, what stood out to me most was that I could create
16 resistors and tie them to two 16-trace buses, with three lines of code
rather than manually adding 16 resisters to a schematic. One of the first
boards I was asked to redo the schematic for when I started, was Spartan6
Atlys Demo-board, it had 100s of resisters and caps and the array capability
stood out to me as one of the fundamental features/capabilities of the
language.

I also found the hierarchy capabilities and the ability to reach down into
the hierarchy and modify attributes of a specific instance very useful,
especially in the case where you have two sections of a board that are
entirely identical except for the value of one resistor or capacitor being
used as an rc filter for an audio jack or something similar. Though, this is
probably less critical than the inst() array rule above as it is used much
less frequently. We could leave it unimplemented or remove it from the
grammar for simplicity sake, if necessary.

What do each of you think about these three specific parts of the grammar,
as well as any other specific changes necessary? It would be good to know
what everyone is thinking with respect to specific grammar
rules/modifications. I also have another comment or two about a possible
modification to the import/package rules, but it would probably be good to
see what each of you think about the rule as a whole before suggesting any
modifications.

As a whole I think, the 2.1 grammar (with a few modifications as per this
discussion) is probably the best option, because it is the end result of a
year or so of progress.

2. Implementation Choice to use as a Starting Point


As Dr. Nelson was saying, I think the best options we have for an
implementation starting point moving forward, would be either the 2.0 or the
2.1-plugin existing compilers.  We have been talking about opensource for
quite some time and I think we've been learning a whole lot thanks to Wes
and it seems like Pete might have some experience in this area as well. Here
at BYU, we've all read parts of the book The Cathedral and The Bazaar, as
Wes suggested. What has stood out to me most about the strengths of the
Bazaar system is that you keep things simple and make it available so that
as many people as possible can start using (and developing) the tool if they
so wish. One of the strengths of Git as a revision control system is that it
allows for individual people to clone the repository and take their own
initiatives in whatever direction they so desire. This is really good
because it allows people to take whatever paths they so decide and try out
any ideas they have with the option of merging them back into the main
repository if their idea turns out to work out as they intended.

I think this is definitely the direction we should be moving as we are
hoping for PHDL to catch on and continue to grow. I feel that this is the
main reason we are also pushing for specific language definitions and specs,
independent of implementation.

However, currently since we only have a user/developer base of about 4-6, it
seems to me that it would probably not be a very good idea for us to split
the development into two different lines of progress at this point. There is
a possibility that this would result in PHDL only becoming a tool used by a
few people here and there, and never really expanding or catching on. The
best thing would be for us all to come to a consensus as a group and move
forward working together on the development in a common direction at least
until we have a common, maintainable, working implementation of whatever we
determine the language specifications to be.  Once we have this stable,
working, "main" repository created, then the project will be able to sustain
itself, if in the future, people desire to move in individual directions.

I think that it is with this in mind, that we should make a choice between
either the 2.0 or 2.1 implementations as a starting point for our 3.0
version. 
Starting over with a completely new version of the compiler would probably
take months to do at this point when you take into account the complexity
that is required to perform hierarchy and elaboration correctly with no
errors. 


2.1 is implemented in x-text, a language specifically created for
implementing languages in eclipse. It is the most debugged/tested and best
working version of the compiler we currently have, but it would also be hard
for anyone not interested in learning x-text/eclipse to develop or maintain.
Due to a possibly significant learning curve required for development within
eclipse, it seems that it would also be quite difficult for anyone else
besides those currently working on the project to jump in and begin
development as we hope to happen in the future.
Though it seems that x-text also does more for you even than Antlr does, it
made the language implementation much easier. Brad commented often about
things that were automatically taken care of in x-text that he had spent
long hours implementing in Antlr.

Brad, could you comment about this? You can probably explain more about the
possible learning curve as well as the benefits of implementation in x-text
than anyone else.


2.0 is implemented in Antlr. As I understand it, a big benefit of Antlr is
that almost anyone who has taken a compiler class or who has done any work
with compilers/grammars will have used Antlr. I'm still learning quite a
bit. I am not as familiar with Antlr as I am with x-text now, (because this
is the first real exposure I've had to compilers) but I understand that most
potential developers will have either experience with Antlr or no experience
with compilers. 

One problem once again with choosing the 2.0 compiler is the loss of an
entire summer of work by both me and Brad of testing, debugging, and fixing
bugs in the 2.1 compiler. Over the course of the summer we've found many
bugs in the 2.1 compiler implementation/grammar and have been fixing them
all along the way. There is no way of knowing how many of these bugs
(especially with hierarchy) are possibly lurking still in the 2.0 version of
the compiler.

We do have a functional working board created with the 2.0 version of the
compiler!, but this design also did not use hierarchy which leaves room to
worry slightly about bugs that may be lurking within the compiler.

The view that seems the best in my view would be to use the 2.0 version of
the compiler, and update it and document/test it to comply with a grammar
similar to the 2.1 version of the grammar. This would allow for simplicity
of development, while at the same time preserving at least some of the the
work/time that Brad has applied in the past 4-5 months.

 

I think that we should come to a conclusion about what each of us think in
these areas and then after this discussion, begin working on the specific
language spec.

 

If everyone could comment and let me know what you think, that would be
great.

 

Thanks,

 

Josh

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

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

Hey Everybody,

Sorry this is so long, but there are alot of things that have been on my
mind in the past few months about this project and I wanted to get it all
out there so, we can have a discussion about what all our views are at this
point.

I agree with the three alternatives that Dr. Nelson has suggested.

In my mind there are two major decisions that are the most important for us
to make at this time, if we are all going to move forward in one direction:

1. Deciding on a "canonized" grammar.
2. Deciding on an existing implementation as a starting point, so we can
move forward with the development we decided to use.

Here are my views with respect to these two issues:

1. The Grammar

I feel somewhat partial to the 2.1 grammar, it is the one that I have had
the most experience with and the one that I feel has the most kinks worked
out. Brad has been working on the project for more than year almost full
time and all along the way has been finding little things here and there
that could be a little better or that need a little fixing. The 2.1 grammar
is the result of each of these fixes and all of this work.

That said, I'm not opposed to making slight modifications to the grammar
before finalizing the language spec for the time being. It think we should
have a discussion about specific changes to the grammar and once we come to
a consensus in the next few days then begin working on finalizing the
formal language specification, with:


   - Grammar - or allowed syntax
   - Detailed explanations of the interpretation of syntax
   - Detailed explanations of the output that should be generated from the
   interpreted syntax
   - Formats such as the PHDLIF spec that we have been discussing

With respect to Pete's comment about simplifying the grammar, it's ok with
me if we try to simplify the grammar, especially with respect to
the*import/package
* rules. We need to have a good discussion about these two rules,
especially if the consensus implementation choice is something other than
eclipse/x-text. In eclipse/x-text namespaces and packages are automatically
handled for you. In 2.1, the *package* and *import* rules replaced the *
include* rule, because of the capabilities of eclipse. We need to have a
discussion for the future language spec. We could either revert back
to the*include
*in the interest of simplicity or decide to try and write an implementation
of the *import/package* rules because of the great capability it provides
for organizing large numbers of device definitions.

With respect to the* inst(15:0)* feature of the language, I feel strongly
that this rule is one of the strongest capabilities the language provides.
When I first came on the project, what stood out to me most was that I
could create 16 resistors and tie them to two 16-trace buses, with three
lines of code rather than manually adding 16 resisters to a schematic. One
of the first boards I was asked to redo the schematic for when I started,
was Spartan6 Atlys Demo-board, it had 100s of resisters and caps and the
array capability stood out to me as one of the fundamental
features/capabilities of the language.

I also found the hierarchy capabilities and the ability to reach down into
the hierarchy and modify attributes of a specific instance very useful,
especially in the case where you have two sections of a board that are
entirely identical except for the value of one resistor or capacitor being
used as an rc filter for an audio jack or something similar. Though, this
is probably less critical than the inst() array rule above as it is used
much less frequently. We could leave it unimplemented or remove it from the
grammar for simplicity sake, if necessary.

What do each of you think about these three specific parts of the grammar,
as well as any other specific changes necessary? It would be good to know
what everyone is thinking with respect to specific grammar
rules/modifications. I also have another comment or two about a possible
modification to the *import/package* rules, but it would probably be good
to see what each of you think about the rule as a whole before suggesting
any modifications.

As a whole I think, the 2.1 grammar (with a few modifications as per this
discussion) is probably the best option, because it is the end result of a
year or so of progress.

2. Implementation Choice to use as a Starting Point


As Dr. Nelson was saying, I think the best options we have for an
implementation starting point moving forward, would be either the 2.0 or
the 2.1-plugin existing compilers.  We have been talking about opensource
for quite some time and I think we've been learning a whole lot thanks to
Wes and it seems like Pete might have some experience in this area as well.
Here at BYU, we've all read parts of the book The Cathedral and The Bazaar,
as Wes suggested. What has stood out to me most about the strengths of the
Bazaar system is that you keep things simple and make it available so that
as many people as possible can start using (and developing) the tool if
they so wish. One of the strengths of Git as a revision control system is
that it allows for individual people to clone the repository and take their
own initiatives in whatever direction they so desire. This is really good
because it allows people to take whatever paths they so decide and try out
any ideas they have with the option of merging them back into the main
repository if their idea turns out to work out as they intended.

I think this is definitely the direction we should be moving as we are
hoping for PHDL to catch on and continue to grow. I feel that this is the
main reason we are also pushing for specific language definitions and
specs, independent of implementation.

However, currently since we only have a user/developer base of about 4-6,
it seems to me that it would probably not be a very good idea for us to
split the development into two different lines of progress at this point.
There is a possibility that this would result in PHDL only becoming a tool
used by a few people here and there, and never really expanding or catching
on. The best thing would be for us all to come to a consensus as a group
and move forward working together on the development in a common direction
at least until we have a common, maintainable, working implementation of
whatever we determine the language specifications to be.  Once we have this
stable, working, "main" repository created, then the project will be able
to sustain itself, if in the future, people desire to move in individual
directions.

I think that it is with this in mind, that we should make a choice between
either the 2.0 or 2.1 implementations as a starting point for our 3.0
version.
Starting over with a completely new version of the compiler would probably
take months to do at this point when you take into account the complexity
that is required to perform hierarchy and elaboration correctly with no
errors.


2.1 is implemented in x-text, a language specifically created for
implementing languages in eclipse. It is the most debugged/tested and best
working version of the compiler we currently have, but it would also be
hard for anyone not interested in learning x-text/eclipse to develop or
maintain. Due to a possibly significant learning curve required for
development within eclipse, it seems that it would also be quite difficult
for anyone else besides those currently working on the project to jump in
and begin development as we hope to happen in the future.
Though it seems that x-text also does more for you even than Antlr does, it
made the language implementation much easier. Brad commented often about
things that were automatically taken care of in x-text that he had spent
long hours implementing in Antlr.

Brad, could you comment about this? You can probably explain more about the
possible learning curve as well as the benefits of implementation in x-text
than anyone else.


2.0 is implemented in Antlr. As I understand it, a big benefit of Antlr is
that almost anyone who has taken a compiler class or who has done any work
with compilers/grammars will have used Antlr. I'm still learning quite a
bit. I am not as familiar with Antlr as I am with x-text now, (because this
is the first real exposure I've had to compilers) but I understand that
most potential developers will have either experience with Antlr or no
experience with compilers.

One problem once again with choosing the 2.0 compiler is the loss of an
entire summer of work by both me and Brad of testing, debugging, and fixing
bugs in the 2.1 compiler. Over the course of the summer we've found many
bugs in the 2.1 compiler implementation/grammar and have been fixing them
all along the way. There is no way of knowing how many of these bugs
(especially with hierarchy) are possibly lurking still in the 2.0 version
of the compiler.

We do have a functional working board created with the 2.0 version of the
compiler!, but this design also did not use hierarchy which leaves room to
worry slightly about bugs that may be lurking within the compiler.

The view that seems the best in my view would be to use the 2.0 version of
the compiler, and update it and document/test it to comply with a grammar
similar to the 2.1 version of the grammar. This would allow for simplicity
of development, while at the same time preserving at least some of the the
work/time that Brad has applied in the past 4-5 months.

I think that we should come to a conclusion about what each of us think in
these areas and then after this discussion, begin working on the specific
language spec.

If everyone could comment and let me know what you think, that would be
great.

Thanks,

Josh

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

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

Brent

 

Thanks for kicking this off. I think we should consider some other
alternatives.  

 

In my opinion, we should dramatically simplify the language grammar and then
think about implementation.

 

Here are some simplifications I suggest.

 

1.       Eliminate (for now) our implementation of the VHDL for.generate
feature.  It looks to me that 90% of the complexity (and testing) of the
compiler is due to the inst(15:0) looping syntax.   Also, the looping syntax
has crept up into tutorials, example code and presentation slides.  I still
believe it would be a very rare case where using this syntax would reduce
lines of code or improve readability in a board design.

2.       Eliminate (for now) the hierarchy probing feature of the language,
ie. 'inst.subinst.subinst2.value = "100";'.  Again, I have difficulty seeing
a case where this is necessary or desirable in a board design.

 

Both of these language features make a great deal of sense when designing IC
logic. In VHDL, I use "for-gen" all the time.  I also use generic's to pass
parameterization down the hierarchy.  Logic designs are much more complex
than board designs so they need for-gen and generic features to manage that
complexity.  Also, in logic design you can edit, compile and simulate till
you get all that fancy syntax correct.  

 

Board designs are smaller but depend on careful inspection before
fabrication to avoid errors.  The syntax should be very simple to support
direct human visual verification.

 

In addition to the language simplification we should really plan to
implement Wes' suggestions .

 

3.       Create a concise language specification.

4.       Create an intermediate format specification and use it to separate
the compiler from the netlist generators.

 

I think if we plan to do all four of these things the way forward will
become clear.  It seems reasonable to use the 2.0 Antlr->java as the
starting point.

 

Is there a document on the wiki or in the repo for the language spec?
Should I start one?

 

Pete

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

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

Dear PHDL Users,

Here at BYU we have been meeting and talking about directions for PHDL.  I would like to initiate a discussion amongst the PHDL community and see what people are thinking.

While it is true that the beauty of an open source project like this is that everyone is a volunteer and anyone can take it any direction they want, it seems to us that with our current small PHDL user community that we would be well served if we could pool our efforts at this early stage to come up with a simple version of PHDL that can be maintained and modified moving forward.

The first question revolves around a grammar and version of tools to be using.  The tool candidates are the  2.0, and 2.1 tools.  The reason for not even considering the 1.0 tools is that the grammar they implement lacks hierarchy and had a number of verbose features.  Upgrading the 1.0 tools to use the newer grammar of 2.0 IS why the 2.0 tools give you.

My take on the two existing tools include the following:

2.0: Pros: simple, based on ANTLR, stand-alone executable.  Cons: missing the ability to reach inside the hierarchy and do probing (change parameters on devices) as in: 'inst.subinst.subinst2.value = "100";' (but otherwise fully supports hierarchy).

2.1: Pros: wrapped in an IDE which makes lots of things easy and error checking much more immediate, has had the most debugging done on it here at BYU on designs, implements packages and hierarchical probing.  Cons: wrapped in an IDE which raises the bar for users to start using, would seem to be much harder to maintain and support due to the collection of technologies one must wrap their head around (I say "would seem" because only Brad and Josh have wrapped their heads around those technologies – they could comment and help us understand this).

Really, however, this boils down to whether we want to go with a simpler parser generator approach or a more complex one.  ANTLR (2.0) is the simpler of the two implementations and can be easily modified for any grammar we settle on.

The reason we have not brought up the obvious proposal of writing a new tool based on a different parser generator, is that the parser generation is just the tip of the iceberg.  The previous work on elaboration (which PHDL designs require just like other HDLs), error checking/verification, and backend net listing is THE big part of the project and it seems dumb to throw away that work.

Barring a decision to start over with a new approach, there seem 3 candidate approaches for a starting point:


  1.  Document the 2.0 grammar and adopt the 2.0 tools as the starting point going forward.
  2.  Document the 2.1 grammar (which we have done), adopt the 2.0 tools as the basis for the toolchain, and update them to process the 2.1 grammar.
  3.  Document the 2.1 grammar (which we have done) and adopt the Eclipse-based tool as the starting point going forward.

Regarding these 3 choices, the choice between #1 and #2 above could merit some elaboration.  The main thing missing from the 2.0 grammar are packages.  Adding them could take some work if they were done like VHDL and Verilog do it (a 'work' library with precompiled modules in it).  The real questions relate to how valuable packages are vs. the complexity they introduce.

What are people's feelings and thoughts?  Comments and flames welcomed.  Is there a version that others are going to use moving forward?  Our view that we would rather throw in as a group rather than have different efforts going on at this point.

Thanks,

Brent

Re: [phdl-devel] intermediate format

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

Guys,

The most important purpose for PHDLIF is for output netlist generation.  The netlist format that I know is for Mentor PADS.  This is a netlist file for a little FMC board that I did earlier using PHDL 1.0.  It is asscii text an might trigger some thoughts on the Intermediate Formati.

https://sourceforge.net/p/phdl/svn/495/tree/trunk/misc/projects/Old.v1.0-projects/FMC_DAC/phdl/fmc_dac.asc

    Pete


From: wj...@ic...
To: phd...@li...
Date: Fri, 2 Nov 2012 19:12:39 -0600
Subject: Re: [phdl-devel] intermediate format

On Tuesday, October 30, 2012 17:40:16 Wesley J. Landaker wrote:
> In this draft I am explicitly *NOT* trying to define, yet, how things are
> encoded or exactly what format or order things are in. Instead, the goal
> is to first identify what absolutely needs to be in our PHDLIF files,
> and what we might want to support in the future.
> 
> I believe if you take a look at this document you will see that I've
> tried to capture this in a very simple and straightforward manner. I
> believe that everything that everyone has mentioned so far can be
> elegantly supported without needing to complicate anything further than
> necessary.
 
To support this, I've also just pushed a header file into Git that shows a 
simple C++ API to read and write PHDLIF (there is no implementation yet, we 
first want to make sure the interface looks nice).
 
Although the language is C++, the important point is what is contained in 
the PHDLIF data model itself.
 
(As for this specific interface, other languages could use this directly 
(it's easy to call C++ code from any language), or could make their own 
simple implementation.)
 
If anyone has any comments about this or the PHDLIF requirements I wrote up 
previously, let's hear them! =) In a few days I plan to write up a full 
specification and an accompanying working libphdlif reference 
implementation.

------------------------------------------------------------------------------
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d
_______________________________________________
phdl-devel mailing list
phd...@li...
https://lists.sourceforge.net/lists/listinfo/phdl-devel