Sometimes I think they just wanted to mess with people when they designed VHDL. I recall some long ago conversations with one of the guys who helped design VHDL and while he understood the language well, he understood it the same way a newly hired legal
associate understands the law. He knew most of the rules, but didn't understand how to usefully apply them to do what needed to be done. That's what senior partners are for. More recently it seems like they've changed VHDL in ways that make it much
more usable, but not always. Sometime there are things that seem like they should work, but just don't.

So my most recent issue is this statement...

Sound_Run <= Alarm_Src ?/= (others => '0');

The compiler complains that it doesn't understand what size the aggregate should be. Is that because while Alarm_Src is well defined, the comparison operator can accept many different operand widths and the tool can't see across the operator???

Alarm_Src is defined as Alarm_Type which is defined

subtype Alarm_Type is unsigned (Technical_Sel downto Tidal_Vol_Sel);

Where the two values in the range are integer constants.

This works...

Sound_Run <= Alarm_Src ?/= (Alarm_Src'range => '0');

I should understand this, but I don't.

--

Rick C.

- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Friday, September 18, 2020 at 12:51:23 PM UTC-4, KJ wrote:

On Thursday, September 17, 2020 at 8:35:17 PM UTC-4, gnuarm.del...@gmail.com wrote:

Sound_Run <= Alarm_Src ?/= (others => '0');

The compiler complains that it doesn't understand what size the aggregate should be. Is that because while Alarm_Src is well defined, the comparison operator can accept many different operand widths and the tool can't see across the operator???

Basically, yes. However, if all somebody told you is "(others => '0')", and asked how wide the vector is, you wouldn't be able to answer the question. The compiler is the same way. It needs to know the width of the vector. While the operator can

work with any size vectors, those vectors still must have defined ranges. Otherwise, how can it check that the vectors are the same size?

Kevin Jennings

The vector is as wide as the other input to the ?/= operator. I would expect that to be obvious to anyone looking at the code. But it's not obvious to the tool. That's my point. Many times in the past I recall the tool not being able to under stand
an intent that is patently obvious which was eventually fixed in the language like "000" being assigned to a std_logic_vector because the tools didn't know you weren't trying to assign a bit vector to an slv.

This would seem to be another case of the tools not being able to understand what is actually rather obvious. I keep saying I'm going to learn Verilog. Maybe I should have used this project as my learning curve.

--

Rick C.

+ Get 1,000 miles of free Supercharging
+ Tesla referral code - https://ts.la/richard11209

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, September 17, 2020 at 8:35:17 PM UTC-4, gnuarm.del...@gmail.com wrote:

Sound_Run <= Alarm_Src ?/= (others => '0');

The compiler complains that it doesn't understand what size the aggregate should be. Is that because while Alarm_Src is well defined, the comparison operator can accept many different operand widths and the tool can't see across the operator???

Basically, yes. However, if all somebody told you is "(others => '0')", and asked how wide the vector is, you wouldn't be able to answer the question. The compiler is the same way. It needs to know the width of the vector. While the operator can work
with any size vectors, those vectors still must have defined ranges. Otherwise, how can it check that the vectors are the same size?

Kevin Jennings

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 18/09/2020 18:01, Rick C wrote:

On Friday, September 18, 2020 at 12:51:23 PM UTC-4, KJ wrote:

On Thursday, September 17, 2020 at 8:35:17 PM UTC-4, gnuarm.del...@gmail.com wrote:

Sound_Run <= Alarm_Src ?/= (others => '0');

The compiler complains that it doesn't understand what size the aggregate should be. Is that because while Alarm_Src is well defined, the comparison operator can accept many different operand widths and the tool can't see across the operator???

Basically, yes. However, if all somebody told you is "(others => '0')", and asked how wide the vector is, you wouldn't be able to answer the question. The compiler is the same way. It needs to know the width of the vector. While the operator can

work with any size vectors, those vectors still must have defined ranges. Otherwise, how can it check that the vectors are the same size?

Kevin Jennings

The vector is as wide as the other input to the ?/= operator. I would expect that to be obvious to anyone looking at the code. But it's not obvious to the tool. That's my point. Many times in the past I recall the tool not being able to under stand

an intent that is patently obvious which was eventually fixed in the language like "000" being assigned to a std_logic_vector because the tools didn't know you weren't trying to assign a bit vector to an slv.

This would seem to be another case of the tools not being able to understand what is actually rather obvious. I keep saying I'm going to learn Verilog. Maybe I should have used this project as my learning curve.

I'm not so sure that Verilog will help you much, with VHDL the compiler
refuses to guess, sometimes pedantically. Verilog is like an
enthusiastic puppy, it tries to guess what you want and sometimes gets
it horribly wrong, and you don't find out until it doesn't work.

MK

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Friday, September 18, 2020 at 3:13:51 PM UTC-4, Michael Kellett wrote:

On 18/09/2020 18:01, Rick C wrote:

On Friday, September 18, 2020 at 12:51:23 PM UTC-4, KJ wrote:

On Thursday, September 17, 2020 at 8:35:17 PM UTC-4, gnuarm.del...@gmail.com wrote:

Sound_Run <= Alarm_Src ?/= (others => '0');

The compiler complains that it doesn't understand what size the aggregate should be. Is that because while Alarm_Src is well defined, the comparison operator can accept many different operand widths and the tool can't see across the operator???

Basically, yes. However, if all somebody told you is "(others => '0')", and asked how wide the vector is, you wouldn't be able to answer the question. The compiler is the same way. It needs to know the width of the vector. While the operator can

work with any size vectors, those vectors still must have defined ranges. Otherwise, how can it check that the vectors are the same size?

Kevin Jennings

The vector is as wide as the other input to the ?/= operator. I would expect that to be obvious to anyone looking at the code. But it's not obvious to the tool. That's my point. Many times in the past I recall the tool not being able to under

stand an intent that is patently obvious which was eventually fixed in the language like "000" being assigned to a std_logic_vector because the tools didn't know you weren't trying to assign a bit vector to an slv.

This would seem to be another case of the tools not being able to understand what is actually rather obvious. I keep saying I'm going to learn Verilog. Maybe I should have used this project as my learning curve.

I'm not so sure that Verilog will help you much, with VHDL the compiler refuses to guess, sometimes pedantically. Verilog is like an
enthusiastic puppy, it tries to guess what you want and sometimes gets
it horribly wrong, and you don't find out until it doesn't work.

That is what I've heard, but I believe it's not so much a puppy wildly guessing as it is a matter of consistently making assumptions that the programmer must learn about. That part is not really different from VHDL, but the part about VHDL stubbornly
refusing to act until it is told in excruciating detail what is intended while Verilog doesn't hold your hand and makes it's assumptions whether you understand or not.

I'm still having issues with VHDL and in at least one case it is exactly the same as Verilog, other than expected with no warning. I opened another thread about rounding of real values not working as I expected. I guess I need to write some code to
explore this and figure out what is happening.

Even if VHDL gives you warnings that prevent mistakes, it's a bloody PITA to program in sometimes. My other language is Forth where it doesn't make assumptions of any sort. You just have to make it do what you want with a whip and chair. Actually no
whip or chair needed. More like giving you all the sharp and power tools you want as long as you know how to use them without getting hurt.

My real problem with all this is working with them intermittently. It can be years between significant projects. But it seems every time I have to open Pandora's box again, I find a new something in there that I hadn't seen before. My code does keep
getting better even if it is a PITA to relearn.

--

Rick C.

-- Get 1,000 miles of free Supercharging
-- Tesla referral code - https://ts.la/richard11209

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <Y8udnfntGoV2m_jCnZ2dnUU78IXNnZ2d@giganews.com>,
Michael Kellett <mk@mkesc.co.uk> wrote:

This would seem to be another case of the tools not being able to understand what is actually rather obvious. I keep saying I'm going to learn Verilog. Maybe I should

have used this project as my learning curve.

I'm not so sure that Verilog will help you much, with VHDL the compiler >refuses to guess, sometimes pedantically. Verilog is like an
enthusiastic puppy, it tries to guess what you want and sometimes gets
it horribly wrong, and you don't find out until it doesn't work.

Don't want to start a language war, but this characterization is
completely wrong about verilog. The verilog rules are less hard typed,
than VHDL but there's no "guessing" involved AT ALL within the
language. There's very few cases of ambiguous behaviour in the
standard. And for those that do exists the complementary abiguous
behavior likely exists in VHDL too, or has solid ways for the
RTL designer to avoid problems because of the "undefined" or
"implementation" defined behavior.

There are well and good reasons to prefer one VHDL over Verilog, however
this characterization misses the mark.

Regards,
Mark

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)