Subject: RE: [vhdl-200x] Corrections to Minutes for VHDL-200X-FT meeting, San Jose Dec 4, 2003
From: Bailey, Stephen (SBailey@model.com)
Date: Wed Dec 17 2003 - 15:46:04 PST
Note that we have no plans on tabling this proposal. There have been no technical problems found with the proposal. The proposal is one of several issues needed to facilitate the incorporation of PSL as the property specification and temporal assertion capability in VHDL.
The complaints have all come down to subjectivity as to whether
if sl then
is more readable than
if sl = '1' then
For those who like the latter, they are free to continue using it. For those who see nothing wrong with the former and appreciate the fact that it is quicker to write, they can use it.
Additional comments embedded below.
-Steve Bailey
Is it proposed to include a standard COND operator definition in std_logic_1164? Would it convert 'H' to TRUE? What about 'X' or any other metavalue? If it is not defined as a standard, then different users may write it differently. Which now means the same code, with a different user's COND definition would simulate differently. Hmmm, sounds like verilog to me.
As things are currently organized, 1164 is a separate standard. They can choose to take advantage of this capability or not. If they do, it is up to 1164 to define the boolean mapping. It is my expectation that they would propose COND returning TRUE for '1' and 'H' only and FALSE for anything else. This would be consistent with the default behavior of the std_logic_1164.To_bit function (assuming all are in agreement that bit '1' is TRUE and bit '0' is FALSE).
Most of this would not make any difference for RTL code written for synthesis into an FPGA or ASIC, but when it is used to simulate the FPGA on the board, and the board has resistively driven inputs, these details matter big time. And it is these "details" that brought about the creation of std_logic in the first place; now we are going to throw away all that work for a little less typing?
No work is being thrown away. Keep coding the way you currently are and you won't use the new capability.
When only "clk" is in the sensitivity list (and there is no subordinance to another if clause, i.e. reset), many synthesizers will accept the following for a clock edge specification, and it will simulate correctly, assuming no weak or metavalues are involved (a shortcoming to every method but rising_edge() and falling_edge().)
main: process (clk)
begin
if clk = '1' then -- means rising edge clock
do_rising_edge_stuff(inputs, outputs);
end if;
end prodess;
By extension, it would be allowed to write (if a COND operator is defined for std_logic):
main: process (clk)
begin
if clk then -- means rising edge?
if enabled then -- clock enable?
do_rising_edge_stuff(inputs, outputs);
end if;
end if;
end prodess;
And, by further extension, it would be allowed to write the following:
main: process (clk)
begin
if not clk then -- means falling edge?
if not disable then -- clock enable?
do_falling_edge_stuff(inputs, outputs);
end if;
end if;
end prodess;
As you can see this usage makes it more difficult to distinguish between clock enables and clocks, an important distinction.
Seems clear to me. The clock is in the sensitivity list. The enable/disable is not. I don't see a problem that adding "= '1'" solves.
Furthermore, it has been proposed elsewhere that synthesis vendors accept the following as clock enable syntax (it already simulates like a clock enable):
main: process (clk)
begin
if rising_edge(clk) and enable = '1' then
do_rising_edge_stuff(inputs, outputs);
end if;
end prodess;
If this were rewritten under the new standard as the following, what would it mean?
main: process (clk)
begin
if clk and enable then -- = rising_edge(clk and enable) = gated clock, not clock enable!
do_rising_edge_stuff(inputs, outputs);
end if;
end prodess;
Again, I see no problems. Only clk is in the sensitivity list. Seems very clear to me. Jim has already answered questions about what is proposed in 1076.6 and the compatibility of this change with those proposals.
I used the term "allowed to write" above, even though we all know that, since it is the shorter syntax, it will become the de facto standard, and vhdl will lose valuable clarity as a result. If users want to write code like verilog lets them, tell them to use verilog (and tell them to look out!). Otherwise, write vhdl.
The popularity of vhdl (and thus its survival) is not dependent on trivial shortcuts like this. It is dependent on archaic, but still taught practices like using component definitions/configurations/instantiations instead of entity instantiation. Like using std_logic and std_logic_vector everywhere when integer and boolean are simpler, easier to read and write, and faster to simulate. These are the things that will make and keep vhdl vibrant and healthy, not dumbing it down for the masses. The proposed implicit call to COND is a terrible idea, providing precious little benefit for a monumental loss in clarity.
You are making assertions that have not been substantiated by any tangible example. We are not "dumbing it down for the masses." Quite the opposite. We are making the language more sophisticated in its ability to recognize commonly used code snippets and not require the user to explicitly cover everything. Any step up in abstraction level (including this relatively minor move up) requires the removal of some detail.
Did anyone see the quote attributed to Cliff Cummings in a SystemVerilog article this week or last (I believe it was EE Times, but I can't find the article now)? Cliff stated that, with SystemVerilog, it will be possible to write the same functional model in 70% less code than what is required in Verilog. The important point is not whether 70% is an accurate number. The point is that Cliff is correct in that SystemVerilog requires less code than Verilog. This is our competition. If people can design and write testbenches ?x times faster in Verilog than VHDL, VHDL will shrink to irrelevance.
This does not mean that VHDL must blindly mimic Verilog. It does mean we need to make VHDL more efficient. Readability and maintainability remain key value differentiators. So far, no one has demonstrated how a proposal objectively violates these language values. It has been demonstrated how the proposals improve efficiency.
I've said it before and I'll say it again: If you love everything about your day-to-day experience with VHDL, then make sure we make everything backward compatible so you can continue your life unchanged. Otherwise, stand aside (as long as we are doing no objective damage) and allow us to make it a higher productivity tool for a broader user class. If you stand in the way of progress, you'll find that you'll have no VHDL tools 5-10 years from now. Is that a future you want to see?
-Steve Bailey
This archive was generated by hypermail 2b28 : Wed Dec 17 2003 - 15:48:27 PST