Creating new operators

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.

On Mon, 28 Jul 2008 21:31:43 +0000, Nico Coesel wrote:

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

On Jul 29, 12:08=A0pm, Paul Taylor <pt@false_email.co.uk> wrote:
> On Mon, 28 Jul 2008 21:31:43 +0000, Nico Coesel wrote:
> > 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 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

On Jul 28, 12:22 pm, Rob Gaddi <rga...@technologyhighland.com> wrote:
> rickman wrote:
> > On Jul 26, 9:38 am, Mike Treseler <mtrese...@gmail.com> wrote:
> >> rickman wrote:
> >>>   BERTEn <=     BERTSel and GenEn ? not SyncPOSSel : not GenPOSSel;
> >>      if BERTSel and GenEn then
> >>         BERTEn <= not SyncPOSSel;
> >>      else
> >>         BERTEn <= not GenPOSSel;
> >>      end if;
>
> > One of us doesn't understand the precedence (I'm not sure which
> > one...).  That is always a good reason for not allowing precedence
> > defaults to define an expression...
>
> >    BERTEn <=     BERTSel and (GenEn ? not SyncPOSSel : not GenPOSSel);
>
> > Is that more clear?
>
> > Rick
>
> 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.

On Jul 28, 12:12 pm, Andy <jonesa...@comcast.net> wrote:
> On Jul 28, 9:41 am, rickman <gnu...@gmail.com> 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.  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.
>
> > Rick
>
> 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

On Jul 28, 9:04 pm, Brian Drummond <brian_drumm...@btconnect.com>
wrote:
>
> 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

rickman wrote:

> 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

On Jul 28, 5:31 pm, n...@puntnl.niks (Nico Coesel) wrote:
> rickman <gnu...@gmail.com> wrote:
>
> >The problem is not so much reading the code, but is writing.  I think
> >in the terms of the logic, usually a schematic/block diagram.  Then I
> >try to express that logic in the language.  It is not uncommon that it
> >is simply impossible to express the logic in the form I have drawn
> >it.  Then I have to convolute it to come up with something that is
> >what I have drawn, or at least I hope so.
>
> 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?


> >Example: A data mux controlled by the output of an AND of a signal and
> >the output of a mux.  This is four control signals gated together to
> >drive the control on the data mux.  Here is what I ended up with.
>
> >  BERTEn <=      '0' when BERTSel = '0' else
> >            not SyncPOSSel when GenEn = '0' else
> >            not GenPOSSel;
>
> >I don't think that the diagram I drew comes to mind when you see this
> >code.  Maybe a process with an IF statement would be slightly more
> >clear, but the verbosity presents an obfuscation of its own from the
> >"clutter" created.
>
> >process (  BERTSel, SyncPOSSel, GenEn, GenPOSSel) begin
> >  if (BERTSel = '0') then
> >    BERTEn <=    '0';
> >  elsif (GenEn = '0') then
> >    BERTEn <=    not SyncPOSSel
> >  else
> >    BERTEn <=    not GenPOSSel;
> >  end if;
> >end process;
>
> >The clutter is from the sheer size of the code.  The first three line
> >example is a bit obtuse, the 9 line example is large enough to make it
> >hard to see the rest of the code and so to see how it fits into the
> >big picture.  Compare the two examples to this code...
>
> >  BERTEn <=      BERTSel and GenEn ? not SyncPOSSel : not GenPOSSel;
>
> 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.

> >This is what I expect a concurrent statement to look like, not to
> >mention that it represents exactly the image I had in my head and on
> >the whiteboard, making it much easier to write.
>
> >I am sure there are those who disagree and much prefer the verbose
> >process.  Maybe I'm just not cut out for the regimen of VHDL.
>
> 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

> Nico Coesel wrote:
> >>  BERTEn <=  BERTSel and GenEn ? not SyncPOSSel : not GenPOSSel;
>
> > 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;

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

On Wed, 30 Jul 2008 08:23:03 -0700, Mike Treseler wrote:

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