Creating new operators

[Colin Paul Gloster]

On Mon, 28 Jul 2008, Rickman wrote:
|-------------------------------------------------------------------------|
|"[..] |
| |
|A language does not need to protect you from yourself if you are any |
|good. I realized a long time ago that computer tools were initially |
|designed for computer designers. But there aren't enough good |
|designers to go around. So the tools were dumbed down so that the |
|masses could use them. I don't agree that this is even needed." |
|-------------------------------------------------------------------------|

I once read a claim in a book (unfortunately I can not rememember
which one and it shall be many months before I shall be able to
check), that Albert Einstein was once returning home via the visitors'
entrance of the complex in which he resided at in those days, and he
asked for Mr. or Dr. Einstein, and a few seconds later he admitted to
being embarrassed because after asking for Einstein, he remembered
that he was Einstein. People do not perform at their best at every
moment they are working. If I cycle a bike near broken glass on the
road, then I tend to cycle more cautiously than when the road is
clear. I almost never cycle without a helmet though I have never been
in a situation in which I would have been seriously injured or died if
I had not been wearing a helmet.

People who are not mountain climbers had been surprised to hear that I
have climbed without a rope. I do not usually climb high enough to die
from a fall on my own without a rope, but I have done it (without a
helmet). When doing so, I have paid a lot of attention to not making a
fatal mistake. (Much better climbers than I had died, so being
excellent at something does not guarantee that something unfortunate
shall never happen.) Even so, I tend to ordinarily deliberately go
towards a handrail when I am about to walk on a very wide staircase.

Electric sockets and plugs in every country in which I have resided
have been designed in such a way that they can not be easily connected
in a dangerous fashion.

|-------------------------------------------------------------------------|
|" What |
|is needed is a bit of education in how to write code that is not hard |
|to debug and then getting people to use those principles as well as |
|the principles of good test techniques. |
| |
|[..]" |
|-------------------------------------------------------------------------|

A little education does not go a long way.

C. P. G.

 

[Colin Paul Gloster]

On Mon, 28 Jul 2008, Diogratia wrote:

|-----------------------------------------------------------------------|
|"[..] |
| |
|The BNF for VHDL 93 for instance, isn't semantically complete, nor is |
|it non-ambiguous. You actually have to understand the language to |
|contemplate making changes to it, and the BNF isn't sufficient." |
|-----------------------------------------------------------------------|

True (as with any language which is not trivial) and you still need to
actually understand the language in order to accomplish...

|-----------------------------------------------------------------------|
|" It |
|seems a bit overkill to start anew then replicate most of VHDL. |
| |
|A preprocessor sufficient for Mr. Rickman's preferred concurrent |
|assignment statement form could easily be written in a small AWK or |
|Perl script, passing through elements of a source file not affected. |
|[..] |
| |
|You could also conceivably translate to your preferred syntax from |
|VHDL in an editor like emacs or joe, write in your preferred syntax |
|abstraction and store the file in VHDL. [..]" |
|-----------------------------------------------------------------------|

....any of these perfectly. A first-order approximation would be much
easier in one of those than modifying the BNF, but a proper
integration instead of a first-order approximation would not be any
easier.

|-----------------------------------------------------------------------|
|"[..] a preprocessor [..] |
|[..] a method shared with the first C++ |
|implementation." |
|-----------------------------------------------------------------------|

Indeed, and the programmer of the first C++ implementation devoted a
chapter in his book "The Design and Evolution of C++" against using
the C preprocessor. Furthermore, Brian W. Kernighan (co-inventor of
AWK) co-authored the book "The Practice of Programming" in which such
lexical substitution (changing the syntax underfoot, as it was
described) was also discouraged.

 

[Paul Taylor]

I see your point and I agree. I would like to write my programmable
logic in C as well. Neither VHDL or Verilog are easy to use.

For starters, standard C doesn't support threading + concatenation
+ arbitrary vectors sizes, but you could add those.

I checked out http://en.wikipedia.org/wiki/C_to_HDL and whilst browsing
there it seems some have added these sorts of features to a subset of C,
but then it isn't C anymore, and so you haven't really gained
much, if anything as far as I can see.

Of course there's systemC. Although I don't see that has any advantages
over VHDL if you look at the examples here:

http://www.asic-world.com/examples/systemc/seq.html

Regards

Paul.

 

[Amal]

For starters, standard C doesn't support threading + concatenation
+ arbitrary vectors sizes, but you could add those.

I checked outhttp://en.wikipedia.org/wiki/C_to_HDLand whilst browsing
there it seems some have added these sorts of features to a subset of C,
but then it isn't C anymore, and so you haven't really gained
much, if anything as far as I can see.

Of course there's systemC. Although I don't see that has any advantages
over VHDL if you look at the examples here:

http://www.asic-world.com/examples/systemc/seq.html

Regards

Paul.

Each language has its merits and uses. SystemC is great for modeling
system-level, transaction-level and HW/SW interactions.

Although I love operator overloading when it makes sense, creating new
operators would just create a whole new language and make it
confusing. I would rather stick with operator overloading only for
cases that makes new constructs easier to use and understand.

Operator overloading is great with object-oriented languages like
SystemVerilog. Until vendors add operator overloading to
SystemVerilog, and OOP additions to VHDL are approved, I think you
just need to stick with what you have.

-- Amal

 

[rickman]

As a potential three-line solution:

signal BERTEn_mux_n : std_logic;
...
BERTEn_mux_n <= SyncPOSSel when (GenEn = '1') else GenPOSSel;
BERTEn <= BERTSel and (not BERTEn_mux_n);

And trust in your synthesis tools to fold the intermediate signal. It
certainly eliminates any ambiguity about what's going on where in what
order.

Why that as opposed to

BERTEn <= BERTSel and (GenEn ? not SyncPOSSel : not GenPOSSel);

???

Is this not unambiguous and readable? I guess you are pointing out
solutions that are available. Ok, thanks.

 

[rickman]

If you're so in love with Verilog's capabilities, use verilog.

The rest of us, who are apparently not any good since we prefer a
strong language like VHDL, will continue to use VHDL.

BTW, just in case you want to risk taking our inferior advice, if you
are dead set on a more concise notation in currently legal vhdl, then
create an array type indexed by boolean (or std_logic). Then create a
signal/variable and assign the two elements appropriately. Now you can
implement your concise expression by indexing the array with your
selection expression.

Ya know, I'm just having a conversation here. If you don't like the
topic or don't care for my opinions, why do you bother to
participate? The "attitude" you are showing is not appropriate.

Rick

 

[rickman]

Yes; the selection would have been an expression; unfortunately it would
have been a nasty wart in the syntax and probably broken the parsing
model. For very limited benefit; 2 is a special case of n.

I'm not sure why it would break the parsing model. If it were a built-
in operator, I would think it would be simple to handle, but then I am
not a parser writer (although this would be easy to code in Forth, the
selection operator is nearly an exact match to IF ELSE THEN).

The conditional assignment is a second best for usability, but fits the
big picture better. Assignment can take other characteristics; "after
4ns" or "guarded", so one more doesn't upset the cart, and it is not
limited to 2 inputs.

If selection is an operator it still fits the assignment model. I
don't think you would lose anything by having this available. It
doesn't preclude using the conditional assignment and you can add the
same types of modifiers to a simple assignment.

I think where we differ is that I side with keeping the big picture
simple and consistent; I believe it pays in the long run, despite the
short term cost, such as an occasional extra line (not 9 please!).
Unfortunately that makes VHDL a hard sell, because it doesn't come
across clearly in a little 1-month or 3-month project.

I am a firm believer in the big picture and the long term pay off. I
just see a lot of things in VHDL that I think do not make a
significant contribution to either of these things and can be
improved. There are others who see the same things and there are many
proposed improvements to VHDL. Just look at how string constants were
originally used and how they have been improved over the years. There
is another improvement coming having to do with based
constants ,IIRC.

Rick

 

[Mike Treseler]

Ya know, I'm just having a conversation here. If you don't like the
topic or don't care for my opinions, why do you bother to
participate? The "attitude" you are showing is not appropriate.

Attitude is what keeps things interesting.
Everybody's got one.

-- Mike Treseler

 

[rickman]

I don't think drawing logic is a good way to start. Using flow charts
usually leads to more simple solutions because it is easier for a
human to optimize a flow chart than a bunch of logic symbols.

So are you suggesting that my entire approach to logic design is
inappropriate? In other words, I am doing it *all* wrong? We all
work differently. I would hope that you could understand that.

To be honest, I'm not even sure how I would use a flow chart to design
data flow. I can draw a block diagram to show the data flow and the
control points as well as noting the logic involved in the control
points. If the logic is involved and requires state analysis, then I
would use a flow chart or design the state machine. But how would a
flow chart be used to design the data path?

This construction wouldn't be very clear for people that are
relatively new to a programming language. I'd try to avoid it.

How about:

process ( BERTSel, SyncPOSSel, GenEn, GenPOSSel) begin
if (BETRSel and Genen)='0' then
BERTEn <= not SyncPOSSel
else
BERTEn <= not GenPOSSel;
end if;
end process;

The code above makes perfectly clear what you are doing. Besides, I
doubt your examples are describing the same logic.

No, your code above is not what I intended. But then I think I
covered that before with someone else. I should have used parenthesis
to show precedence, which I typically do. But given the context with
the other examples, instead of suggesting that my examples didn't
match, I think you could have understood the precedence that would
have made them match.

I see your point and I agree. I would like to write my programmable
logic in C as well. Neither VHDL or Verilog are easy to use.

Yet, you could run your VHDL code through a C pre-processor. This
would allow macro substitution.

I don't really want to write in C. I would just like to see VHDL de-
verbosed in some cases.

Rick

 

[rickman]

One other point. I don't write code for beginners to understand. I
write for a typical programmer or sometimes just for myself. I do
want the code to be readable, but I don't feel a need to "dumb" it
down for others.

Rick

 

[Paul Taylor]

Attitude is what keeps things interesting.
Everybody's got one.

Well I guess that's borne out by the Big Brother TV show here in the UK.
It basically consists of, well attitude - take that out of the show
and there's nothing left and a lot do find it interesting.

Regards,

Paul.

 

[Paul Taylor]

I don't really want to write in C. I would just like to see VHDL de-
verbosed in some cases.

You get used to it - I can now type downto faster than my name ;-)

Paul.

 

[Paul Taylor]

(even for FSMs, I found good and clean code even easier to read than an
huge bubble diagram...)

I guess someone must find state-machine diagram software useful, that will
auto-generate code from a diagram for you.

Especially for long chains of pipelined stages... keeping track of how
many delays I need to put for that long forgotten control signal..

That's why FPGA design is really harder than writing C programs,
because all your signals have to come out at the right time in relation to
each other. Even if your had a perfect HDL, FPGA design would still be
difficult compared to software. VHDL's verbose, but on a file by file
basis, the verbosity I don't think obscures the intention of the code - the
verbosity is just tedious.

The other thing that makes FPGA design hard is that the tools implement
different parts of the VHDL standard. Like recently when I had to take
variables out of a process, and convert them to signals, because XST
didn't like them, but the simulator did - pain in the arse.

Paul.

 

[Andy]

One other point. I don't write code for beginners to understand. I
write for a typical programmer or sometimes just for myself. I do
want the code to be readable, but I don't feel a need to "dumb" it
down for others.

Rick

I think that's one of the points some of us are trying to get at. The
verilog syntax you seek is not well understood by a vhdl audience..
Write your code where only you can read it, and you will have to
maintain it, because no one else can (that may be a goal, but not for
me). Many of us work in environments which require peer reviews, where
making the code more easily readable by others (programmers, but maybe
not experts) pays dividends.

I prefer to write code that expresses the behavior more clearly, if
not necessarily the implemented structure. Different synthesis tools,
target architectures or optimization goals may result in different
implementations, which is fine as long as they meet timing/resource
requirements and match the RTL behavior. When they do not meet timing
or resource requirements, then (and only then) I revert to trying to
coax the implementation I have in mind out of the synthesis tool, by
modifying the code structure to get the implementation I want.

Andy

 

[rickman]

I think that's one of the points some of us are trying to get at.

I understand the point, very well. I just don't agree. No one has
made any significant argument to support that point. I just see a lot
of hand waving and overstatement.

The
verilog syntax you seek is not well understood by a vhdl audience..

Duh! It is not part of VHDL. I am suggesting that it become part of
VHDL. Then no one would have the excuse that it is not VHDL so I
don't know it.

Write your code where only you can read it, and you will have to
maintain it, because no one else can (that may be a goal, but not for
me). Many of us work in environments which require peer reviews, where
making the code more easily readable by others (programmers, but maybe
not experts) pays dividends.

Here is an example of overstatement. Are you really suggesting that
the code we are discussing would be so obtuse that "only you can read
it"??? I think that is overstated to the point of absurdity. Yes, it
may take someone a few seconds or possibly even minutes the first time
to look up the command. But if they have to look it up more than once
or can't remember it, then the problem is not due to my use of the
command...

I prefer to write code that expresses the behavior more clearly, if
not necessarily the implemented structure. Different synthesis tools,
target architectures or optimization goals may result in different
implementations, which is fine as long as they meet timing/resource
requirements and match the RTL behavior. When they do not meet timing
or resource requirements, then (and only then) I revert to trying to
coax the implementation I have in mind out of the synthesis tool, by
modifying the code structure to get the implementation I want.

I agree. The behavior I wanted to describe was a mux feeding an AND
gate. Obviously this was not an implementation since these constructs
don't exist in the FPGA. I just want the simplest and concise
description that is easy to read and I think that the sel?a:b
construct fits that need.

Rick

 

[rickman]

I think my main problem with the ?: operator is the same as my problem
with goto statements and implicit type casting. It's not an inherently
problematic device, and can at times be the clearest way of getting the
point across, but it lends itself to abuse. I've certainly seen 10x as
much C code obfuscated by some "clever" use of ?: than I've seen code
clarified by it.

It's like a driver notification device that warns you you're going over
70 mph by crescendoing "Ride of the Valkyries". Theoretically it's a
fine tool, but practically it's just begging you floor it for maximum
effect.

Nice illustration. But I don't see how it applies??? What construct
in VHDL or Verilog can't be misused??? The reason that I prefer
the ?: operator is because the resulting use of the conditional
assignment or the required IF ELSE THEN construct can be "misused" in
that it can obscure the purpose of what you are doing.

Can you give a reasonable example of how the ?: operator has been
misused in a way that can't be done with other operators?

Rick

 

[Paul Taylor]

I think my main problem with the ?: operator is the same as my problem
with goto statements and implicit type casting. It's not an inherently
problematic device, and can at times be the clearest way of getting the
point across, but it lends itself to abuse. I've certainly seen 10x as
much C code obfuscated by some "clever" use of ?: than I've seen code
clarified by it.

I've only seen the ?: badly used once. It was in C code, coded by a guy
who used to have all his C code in one file, and who when designed his
FPGAs had loads of clocks everywhere resulting in asynchronous problems.
I don't think people like that should be the reason why abusable
constructs shouldn't find there way into a language, expecially if there
are just a few of them - if there were loads of abusable fetaures then
that's different.

In a work environment, if you have coding standards and reviews as part of
the design process, then problems shouldn't occur. Maybe lint could also
help?

Most recently, my use of the ?: operator has been when writing some
Tcl programs, and I wouldn't want to give it up there.

Paul

 

[Paul Taylor]

Can you give a reasonable example of how the ?: operator has been
misused in a way that can't be done with other operators?

They can be chained, it can make a right mess. Do a google search for
chained ternary operator.

Paul.

 

[Paul Taylor]

They can be chained, it can make a right mess. Do a google search for
chained ternary operator.

From searching the net, other use of ?: that can cause confusion is when it
spans more than one line

 

[rickman]

From searching the net, other use of ?: that can cause confusion is when it
spans more than one line

I can't say that I give either of these examples much importance.
Both examples of poor usage can create messes of logic no matter what
operator is being used. This just seems to me to be a specious
argument.

a <= alongvariablename or blongvariablename and
clongvariablename xor dlongvariablename and elongvariablename
or flongvariablename;

Rick