Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Oct 05 13:29

    umarcor on top-subtype

    (compare)

  • Oct 05 13:28

    umarcor on master

    2008: ad tb_top_generic_subtype cosim: add ref to aguinet/drago… (compare)

  • Sep 24 20:07

    umarcor on top-subtype

    2008: ad tb_top_generic_subtype (compare)

  • Sep 24 19:59

    umarcor on top-subtype

    2008: ad tb_top_generic_subtype (compare)

  • Sep 24 19:54

    umarcor on top-subtype

    2008: ad tb_top_generic_subtype (compare)

  • Sep 23 01:45

    umarcor on style

    (compare)

  • Sep 23 01:44

    umarcor on run_08

    (compare)

  • Sep 21 23:02

    umarcor on merge-support

    (compare)

  • Sep 21 22:59

    umarcor on master

    merge run_support.py into run.py (compare)

  • Sep 21 22:51

    umarcor on merge-support

    merge run_support.py into run.py (compare)

  • Sep 21 22:34

    umarcor on master

    style deprecate Travis (compare)

  • Sep 21 22:10

    umarcor on style

    test (compare)

  • Sep 21 21:51

    umarcor on style

    deprecate Travis TMP -k (compare)

  • Sep 21 21:47

    umarcor on style

    style deprecate Travis TMP -k (compare)

  • Sep 21 21:32

    umarcor on style

    pathlib support (compare)

  • Sep 21 21:18

    umarcor on runner-string

    (compare)

  • Sep 21 21:18

    umarcor on style

    pathlib (compare)

  • Sep 21 21:12

    umarcor on style

    style (compare)

  • Sep 21 19:48

    umarcor on master

    vhdl_2008: style use type 'string' for top-level… (compare)

  • Sep 21 19:34

    umarcor on runner-string

    use type 'string' for top-level… (compare)

Lars Asplund
@LarsAsplund
With the risk of starting a flaming war the most common indentation on GitHub is 2 spaces. Research has shown that optimal indentation should be in the 2 - 4 range. Logically a common formatter would use 2 spaces without any option to change that. Agree?
Richard Head
@trickyhead_gitlab
@LarsAsplund someone will suggest tabs next and it goes nuclear
Patrick Lehmann
@Paebbels
tabs where made for indentation :)
GlenNicholls
@GlenNicholls
Agreed. If there was a formatter like black for VHDL, I would be more than happy to adjust my style based on recommendations. IMO, unless you have some way of enforcing or formatting code automatically, a recommended style guide for VHDL will not go very far.
Patrick Lehmann
@Paebbels
A formatter would be good, but black is a very bad example for "good" formatter as it produces lot's on inconsistencies in the output. At some point code becomes longer, unreadable and has an average line length auf 20-40 chars instead of 80 chars ...
GlenNicholls
@GlenNicholls
Well yeah, bad example. However, my point was that if there isn't a way to automate checking acceptable styles, developers are not going to be checking their code against the style guide before they commit.
Patrick Lehmann
@Paebbels
@GlenNicholls :thumbsup:
Lars Asplund
@LarsAsplund
Agree, black can be improved but the value of not having the style issues greatly exceeds the problems it has so I use it anyway. It's also limited in terms of configuration which prevents everyone from creating their own dialect. If someone comes up with a way to handle its issues then everyone will "automatically" align to that.
ktbarrett
@ktbarrett:matrix.org
[m]
There is VHDL style guide, which is somewhat mature. Unlike Black it gives the user a lot of options to tweak formatting. I'm not sure if that's a good thing.
GlenNicholls
@GlenNicholls
Luca Colombini
@lukipedio
VSG is what TesosHDL is using for example. They also cite VHDL formatter (https://github.com/g2384/VHDLFormatter)
Lars Asplund
@LarsAsplund
Let me put some gasoline on that fire. There is a study on casing that concludes that CamelCase improves readability. It was based on asking people mostly used to CamelCase what they thought was the style easiest to read. Then there was a follow-up study using eye tracking to measure the difficulty to read different styles. That study didn't have the CamelCase bias as the first study had. The conclusion was that snake_case was easier to read for beginners but that the difference disappears once you get used to a style. Scientifically there is no benefit of using one over the other. What's more common? On GitHub snake_case is more common (3/4). Logically a common style would be based on....
Luca Colombini
@lukipedio
snake_case ahah Well CamelCase doesn't make much sense for a "almost" case-insensitive language like VHDL. You don't only need to read your code, but to track signals in debug also for instance
Kaleb Barrett
@ktbarrett
@GlenNicholls Yeah VSG. One missing feature is that it doesn't seem to handle naming conventions.
Luca Colombini
@lukipedio
@LarsAsplund Thanks for reposrting data from different studies. My feeling is the same as it seems to emerge from them. Get a "good" style and stick to it.
Jim Lewis
@JimLewis
@LarsAsplund @umarcor @Paebbels Did you see that ARM came up with new terminology.
AXI: Regularized terminology to use Manager to indicate the agent that initiates transactions and Subordinate to indicate the agent that receives and responds to requests
AxiStream has a Transmitter and Receiver
Ironic definitions on AXI as I had decided that the appropriate name would be used in its definition - that is how I came up with responder - and they use responds in the definition. Missed opportunity to make some sense. Maybe it makes more sense in another language?
Will be updating AXI terminology in the next OSVVM release. Looks like I picked the obvious choice for AxiStream.
Jim Lewis
@JimLewis
WRT styles, some of the Ada styles I have seen seem to merge camel and snake: Camel_Snake_Case
Jim Lewis
@JimLewis
WRT styles, camel vs snake case, that is a great way to start a flame war.
It would not be possible to change even just the interface to OSVVM without some automated tool. Otherwise, what would the value be?
Lars Asplund
@LarsAsplund

@JimLewis

WRT styles, some of the Ada styles I have seen seem to merge camel and snake: Camel_Snake_Case

So many cases. Have no idea what this is called but I learned that we should differentiate between PascalCase and camelCase and that there is something called kebab-case

WRT styles, camel vs snake case, that is a great way to start a flame war.

It is, I try to raise this question once in a while to see what the state of the community is

It would not be possible to change even just the interface to OSVVM without some automated tool.

I don't think this particular formatting case would be very hard. Use pyVHDLParser to extract public APIs and then use something like these short Python functions to convert the names.

Otherwise, what would the value be?

The primary value I see in a community-wide style for things like indentation, casing and line endings is that it simplifies cooperation in developing open source code. If there is no common style for these things then any style is allowed which means that this will be a topic open for discussion in every code review. Such discussion tend to take focus from the more important things to review. Styles will also change back and forth when different developers update files. A small change looks like a large one just because the developer had another indentation setting in her editor.

Some automatically enforceable styles have been shown to have a measurable effect on things like readability and bug rate. Those are few, the only one I've seen been supported in research is the line length limitation.

Then there are rules which are hard to automatically enforce but have great value. Meaningful identifier names for examples.

There are also rules that have been shown to make things worse so there's no point in creating rules mindlessly just because we can.

Jim Lewis
@JimLewis

Some automatically enforceable styles have been shown to have a measurable effect on things like readability and bug rate. Those are few, the only one I've seen been supported in research is the line length limitation.

I would say trying to attribute lower bug rate to that is dubious. The people and teams who choose to use automatically enforced styles are likely to be more disciplined and have a lower bug rate anyway.

I have seen the Ada style. It would be a compromise. Which is likely what happened.
Jim Lewis
@JimLewis
While you make community by having a common naming style, with either VUnit or OSVVM we would break our community by changing what we are currently doing.
Lars Asplund
@LarsAsplund
@JimLewis

I would say trying to attribute lower bug rate to that is dubious. The people and teams who choose to use automatically enforced styles are likely to be more disciplined and have a lower bug rate anyway.

If that was the case there would be a statistically significant correlation between all rules and lower bug rate. That was not the case. What they did was to find the rules with a statistically positive/negative correlation. Most rules did not yield any significant difference.

I have seen the Ada style. It would be a compromise. Which is likely what happened.

The Ada 83 style guide provides the rationale. Had the early VHDL 87 documents included similar recommendations we would probably not have the situation of today.

When an identifier consists of more than one word, it is much easier to read if the words are separated by underscores. Indeed, there is precedent in English in which compound words are separated by a hyphen. In addition to promoting readability of the code, if underscores are used in names, a code formatter has more control over altering capitalization.

...

Make reserved words and other elements of the program visually distinct from each other

  • Use lower case for all reserved words (when used as reserved words).
  • Use mixed case for all other identifiers, a capital letter beginning every word separated by underscores.
  • Use upper case for abbreviations and acronyms (see automation note).

...

Visually distinguishing reserved words allows the reader to focus on program structure alone, if desired, and also aids scanning for particular identifiers.

...

In Section 2.1, Nissen and Wallis (1984) states that "The choice of case is highly debatable, and that chosen for the [Ada Language Reference Manual (Department of Defense 1983)] is not necessarily the best. The use of lower case for reserved words is often preferred, so that they do not stand out too much. However, lower case is generally easier to read than upper case; words can be distinguished by their overall shape, and can be found more quickly when scanning the text."

...

Ada names are not case sensitive. Therefore the names max_limit, MAX_LIMIT, and Max_Limit denote the same object or entity. A good code formatter should be able to automatically convert from one style to another as long as the words are delimited by underscores.

Lars Asplund
@LarsAsplund

While you make community by having a common naming style, with either VUnit or OSVVM we would break our community by changing what we are currently doing.

Agree, there is an initial disruptive change but there is also a long term change in the mindset for when code is updated. The Python linting tools are updated over time so what is correct today may not be correct tomorrow. The VUnit CI on GitHub runs regularly so even if we haven't push any changes the lint test can go red and we need to update

Kaleb Barrett
@ktbarrett

I would say trying to attribute lower bug rate to that is dubious.

It definitely depends. As an anecdote I recently discovered a bug in a Python script before running it by formatting it with black first. It was a complicated line, a generator expressions in a function call using keyword args in a for loop. After formatting, black split everything out on to different lines and it became very apparent there was an issue with my paren matching. I doubt such a problem could exist in a language like Ada/VHDL that is statically typed and isn't as expressive in a single line as Python can be. But I don't think it's something that can be totally discounted. And of course, it works by making code more readible, so you actually have to read the formatted code...

Jim Lewis
@JimLewis
@ktbarrett In VHDL (and Ada) lack of matching parens is an analysis (compile time) error.
1 reply
It would probably be noted by any of the modern editors that have the compiler built into them (Sigasii, TerosHDL, ...)
Off Topic: Anyone have a pdf tool they like? I primarily need to merge documents. In the past, I also needed to modify cropping, but that was a bug in powerpoint and hopefully my new setup will not need it. I would like to be able to script it - preferably in MSYS2.
I do need it to be robust - I just don't see the pricing of Acrobat to be reasonable for this anymore and I want to do the scripting outside of the tool and not inside the tool.
GlenNicholls
@GlenNicholls
@JimLewis I've used Pandoc in the past for converting documents (e.g. LaTeX->PDF). Note sure what document types you need to merge, but Pandoc can only convert to or from for certain docs noted at https://pandoc.org/
Last time I used it on Windows (~3 years ago) it was annoying to set up, but probably a breeze now with WSL
Jim Lewis
@JimLewis
@GlenNicholls I am going powerpoint to pdf and then combining multiple pdf files. I had an old version of Acrobat on an older machine that has crashed - and then I discovered I could still access it when I login into their website.
Love pandoc though.
Marlon James
@marlonjames
@JimLewis I haven't used it but i found a Python tool https://github.com/metaist/pdfmerge
Unai Martinez-Corral
@umarcor
Dear Colleague Letter: CISE RFI on Semiconductor Research and Education
https://www.nsf.gov/pubs/2021/nsf21112/nsf21112.jsp
/cc @JimLewis @GlenNicholls @LarsAsplund @Paebbels @ktbarrett
Unai Martinez-Corral
@umarcor
A Report on Semiconductor Foundry Access by US Academics
https://nsfedaworkshop.nd.edu/assets/429148/nsf20_foundry_meeting_report.pdf
references provided by Tim @mithro.
Jim Lewis
@JimLewis
@umarcor Wow. It would be nice to be able to tap into that funding for the open source we are doing
Lars Asplund
@LarsAsplund

@JimLewis

@LarsAsplund @umarcor @Paebbels Did you see that ARM came up with new terminology.

Didn't see that but I was expecting it to happen sooner or later. This was maybe a bit sooner than I though.

Lars Asplund
@LarsAsplund

@umarcor

Dear Colleague Letter: CISE RFI on Semiconductor Research and Education
https://www.nsf.gov/pubs/2021/nsf21112/nsf21112.jsp
/cc @JimLewis @GlenNicholls @LarsAsplund @Paebbels @ktbarrett

Interesting!

Jim Lewis
@JimLewis

@ktbarrett in today's VHDL meeting, Unai pointed me to your earlier post here: https://gitter.im/vhdl/General?at=60df3a674e325e6132b72b8f

What you are talking about sounds like tagged records. In the late 90's Peter Ashenden and some folks from Univ Cincinatti did a proposal called Suave. One of the things Suave added was tagged records. Ada has them. Ada also had protected types. Two different things.

When I first read tagged records, that is something that even engineers without an OO programming background can get their heads around.

I would be interested in seeing tagged records make it into a future revision of VHDL. I have many/most of the papers that were written. They just need to be sorted and organized - perhaps into what is unique material and what is a repeat.

That said, the more I use protected types the more I like them - however it is an acquired taste.
Kaleb Barrett
@ktbarrett

@JimLewis Thanks for the response! I read the paper on SUAVE and there are a lot of things I do like.

  • encapsulation of implementation using packages
  • creating subtypes of custom types
  • supporting dynamic dispatch on subtypes
  • generics (though they did not address constraining generics)

However, I'm not a fan of inheritance. I think that subtype assertion and implementation reuse should be provided as separate language features.