Different interpretations for '<=' operator in VHDL
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}
0
(this part of the question has been answered in the comments) How does the VHDL interpreter know the difference between the signal assignment operator (<=) and the less-than-or-equal operator (<=) ?
The second part of the question: I think using the same symbol for different operations makes it easy to introduce hard-to-find bugs and reduces the readability of code:
if signal <= '1' then -- less-than-or-equal
...
end if;
if signal = '1' then -- equal
...
end if;
signal <= '1'; -- signal assignment
Is there a workaround to prevent introducing that kind of bug and improving readability? The code above will be synthesizable, but may be hard to read or not do what you expect.
syntax comparison vhdl variable-assignment ambiguous
asked Nov 23 '18 at 21:09
tudorturcutudorturcu
344
add a comment |
0
(this part of the question has been answered in the comments) How does the VHDL interpreter know the difference between the signal assignment operator (<=) and the less-than-or-equal operator (<=) ?
The second part of the question: I think using the same symbol for different operations makes it easy to introduce hard-to-find bugs and reduces the readability of code:
if signal <= '1' then -- less-than-or-equal
...
end if;
if signal = '1' then -- equal
...
end if;
signal <= '1'; -- signal assignment
Is there a workaround to prevent introducing that kind of bug and improving readability? The code above will be synthesizable, but may be hard to read or not do what you expect.
syntax comparison vhdl variable-assignment ambiguous
asked Nov 23 '18 at 21:09
tudorturcutudorturcu
344
1
There is no possibllity of introducing such a bug. "<=" isn't an assignment operator. Signal assignments are statements, all of which are terminated with a semicolon. A statement isn't part of an expression. (VHDL has no expression statements.) You'll find you're not able to demonstrate your theoretical bug.
– user1155120
Nov 23 '18 at 21:32
1
Expressions are described in IEEE Std 1076-2008 9. Expressions, the BNF in 9.1 is normative. A condition expression used in an if statement in your theoretical example returns a boolean value (10.8 If statement). Expressions are "a formula that defines the computation of a value". "A signal assignment statement modifies the projected output waveforms contained in the drivers of one or more signals (see 14.7.2), schedules a force for one or more signals, or schedules release of one or more signals (see 14.7.3)" (10.5 Signal assignment statement).
– user1155120
Nov 23 '18 at 21:54
3
basically you cant. <= (assignment) is not a function, and cannot be overriden. This is perfectly acceptible and can never cause compiler confusion: a <= b <= c; -- a assinged to b lessthan or equal to c
– Tricky
Nov 23 '18 at 23:42
1
@user1155120 Thank you for the clarification. It was a two-part question actually. In the second part, I was thinking about a bug I had, where I wrote "if a <= '1' " but I actually meant "if a = '1' ". And this led me to question the choice of using the same operator with different meanings depending on the context, I think it makes the code a little bit less readable
– tudorturcu
Nov 24 '18 at 0:53
Note the same usage of "<=" for assignment in SystemVerilog. For a declared as type std_logic condition a <= '1' would be true if a were 'U', 'X' or '0;. The base type std_ulogic is an enumerated character type and the character literal '1' can only have an enumerated character type inferred by context (here the condition in the if statement).
– user1155120
Nov 24 '18 at 1:50
add a comment |
0
0
0
(this part of the question has been answered in the comments) How does the VHDL interpreter know the difference between the signal assignment operator (<=) and the less-than-or-equal operator (<=) ?
The second part of the question: I think using the same symbol for different operations makes it easy to introduce hard-to-find bugs and reduces the readability of code:
if signal <= '1' then -- less-than-or-equal
...
end if;
if signal = '1' then -- equal
...
end if;
signal <= '1'; -- signal assignment
Is there a workaround to prevent introducing that kind of bug and improving readability? The code above will be synthesizable, but may be hard to read or not do what you expect.
syntax comparison vhdl variable-assignment ambiguous
asked Nov 23 '18 at 21:09
tudorturcutudorturcu
344
(this part of the question has been answered in the comments) How does the VHDL interpreter know the difference between the signal assignment operator (<=) and the less-than-or-equal operator (<=) ?
The second part of the question: I think using the same symbol for different operations makes it easy to introduce hard-to-find bugs and reduces the readability of code:
if signal <= '1' then -- less-than-or-equal
...
end if;
if signal = '1' then -- equal
...
end if;
signal <= '1'; -- signal assignment
Is there a workaround to prevent introducing that kind of bug and improving readability? The code above will be synthesizable, but may be hard to read or not do what you expect.
syntax comparison vhdl variable-assignment ambiguous
syntax comparison vhdl variable-assignment ambiguous
asked Nov 23 '18 at 21:09
tudorturcutudorturcu
344
asked Nov 23 '18 at 21:09
tudorturcutudorturcu
344
edited Nov 26 '18 at 13:06
tudorturcu
asked Nov 23 '18 at 21:09
tudorturcutudorturcu
344
asked Nov 23 '18 at 21:09
tudorturcutudorturcu
344
asked Nov 23 '18 at 21:09
tudorturcutudorturcu
344
344
1
There is no possibllity of introducing such a bug. "<=" isn't an assignment operator. Signal assignments are statements, all of which are terminated with a semicolon. A statement isn't part of an expression. (VHDL has no expression statements.) You'll find you're not able to demonstrate your theoretical bug.
– user1155120
Nov 23 '18 at 21:32
1
Expressions are described in IEEE Std 1076-2008 9. Expressions, the BNF in 9.1 is normative. A condition expression used in an if statement in your theoretical example returns a boolean value (10.8 If statement). Expressions are "a formula that defines the computation of a value". "A signal assignment statement modifies the projected output waveforms contained in the drivers of one or more signals (see 14.7.2), schedules a force for one or more signals, or schedules release of one or more signals (see 14.7.3)" (10.5 Signal assignment statement).
– user1155120
Nov 23 '18 at 21:54
3
basically you cant. <= (assignment) is not a function, and cannot be overriden. This is perfectly acceptible and can never cause compiler confusion: a <= b <= c; -- a assinged to b lessthan or equal to c
– Tricky
Nov 23 '18 at 23:42
1
@user1155120 Thank you for the clarification. It was a two-part question actually. In the second part, I was thinking about a bug I had, where I wrote "if a <= '1' " but I actually meant "if a = '1' ". And this led me to question the choice of using the same operator with different meanings depending on the context, I think it makes the code a little bit less readable
– tudorturcu
Nov 24 '18 at 0:53
Note the same usage of "<=" for assignment in SystemVerilog. For a declared as type std_logic condition a <= '1' would be true if a were 'U', 'X' or '0;. The base type std_ulogic is an enumerated character type and the character literal '1' can only have an enumerated character type inferred by context (here the condition in the if statement).
– user1155120
Nov 24 '18 at 1:50
add a comment |
1
There is no possibllity of introducing such a bug. "<=" isn't an assignment operator. Signal assignments are statements, all of which are terminated with a semicolon. A statement isn't part of an expression. (VHDL has no expression statements.) You'll find you're not able to demonstrate your theoretical bug.
– user1155120
Nov 23 '18 at 21:32
1
Expressions are described in IEEE Std 1076-2008 9. Expressions, the BNF in 9.1 is normative. A condition expression used in an if statement in your theoretical example returns a boolean value (10.8 If statement). Expressions are "a formula that defines the computation of a value". "A signal assignment statement modifies the projected output waveforms contained in the drivers of one or more signals (see 14.7.2), schedules a force for one or more signals, or schedules release of one or more signals (see 14.7.3)" (10.5 Signal assignment statement).
– user1155120
Nov 23 '18 at 21:54
3
basically you cant. <= (assignment) is not a function, and cannot be overriden. This is perfectly acceptible and can never cause compiler confusion: a <= b <= c; -- a assinged to b lessthan or equal to c
– Tricky
Nov 23 '18 at 23:42
1
@user1155120 Thank you for the clarification. It was a two-part question actually. In the second part, I was thinking about a bug I had, where I wrote "if a <= '1' " but I actually meant "if a = '1' ". And this led me to question the choice of using the same operator with different meanings depending on the context, I think it makes the code a little bit less readable
– tudorturcu
Nov 24 '18 at 0:53
Note the same usage of "<=" for assignment in SystemVerilog. For a declared as type std_logic condition a <= '1' would be true if a were 'U', 'X' or '0;. The base type std_ulogic is an enumerated character type and the character literal '1' can only have an enumerated character type inferred by context (here the condition in the if statement).
– user1155120
Nov 24 '18 at 1:50
1
1
There is no possibllity of introducing such a bug. "<=" isn't an assignment operator. Signal assignments are statements, all of which are terminated with a semicolon. A statement isn't part of an expression. (VHDL has no expression statements.) You'll find you're not able to demonstrate your theoretical bug.
– user1155120
Nov 23 '18 at 21:32
There is no possibllity of introducing such a bug. "<=" isn't an assignment operator. Signal assignments are statements, all of which are terminated with a semicolon. A statement isn't part of an expression. (VHDL has no expression statements.) You'll find you're not able to demonstrate your theoretical bug.
– user1155120
Nov 23 '18 at 21:32
1
1
Expressions are described in IEEE Std 1076-2008 9. Expressions, the BNF in 9.1 is normative. A condition expression used in an if statement in your theoretical example returns a boolean value (10.8 If statement). Expressions are "a formula that defines the computation of a value". "A signal assignment statement modifies the projected output waveforms contained in the drivers of one or more signals (see 14.7.2), schedules a force for one or more signals, or schedules release of one or more signals (see 14.7.3)" (10.5 Signal assignment statement).
– user1155120
Nov 23 '18 at 21:54
Expressions are described in IEEE Std 1076-2008 9. Expressions, the BNF in 9.1 is normative. A condition expression used in an if statement in your theoretical example returns a boolean value (10.8 If statement). Expressions are "a formula that defines the computation of a value". "A signal assignment statement modifies the projected output waveforms contained in the drivers of one or more signals (see 14.7.2), schedules a force for one or more signals, or schedules release of one or more signals (see 14.7.3)" (10.5 Signal assignment statement).
– user1155120
Nov 23 '18 at 21:54
3
3
basically you cant. <= (assignment) is not a function, and cannot be overriden. This is perfectly acceptible and can never cause compiler confusion: a <= b <= c; -- a assinged to b lessthan or equal to c
– Tricky
Nov 23 '18 at 23:42
basically you cant. <= (assignment) is not a function, and cannot be overriden. This is perfectly acceptible and can never cause compiler confusion: a <= b <= c; -- a assinged to b lessthan or equal to c
– Tricky
Nov 23 '18 at 23:42
1
1
@user1155120 Thank you for the clarification. It was a two-part question actually. In the second part, I was thinking about a bug I had, where I wrote "if a <= '1' " but I actually meant "if a = '1' ". And this led me to question the choice of using the same operator with different meanings depending on the context, I think it makes the code a little bit less readable
– tudorturcu
Nov 24 '18 at 0:53
@user1155120 Thank you for the clarification. It was a two-part question actually. In the second part, I was thinking about a bug I had, where I wrote "if a <= '1' " but I actually meant "if a = '1' ". And this led me to question the choice of using the same operator with different meanings depending on the context, I think it makes the code a little bit less readable
– tudorturcu
Nov 24 '18 at 0:53
Note the same usage of "<=" for assignment in SystemVerilog. For a declared as type std_logic condition a <= '1' would be true if a were 'U', 'X' or '0;. The base type std_ulogic is an enumerated character type and the character literal '1' can only have an enumerated character type inferred by context (here the condition in the if statement).
– user1155120
Nov 24 '18 at 1:50
Note the same usage of "<=" for assignment in SystemVerilog. For a declared as type std_logic condition a <= '1' would be true if a were 'U', 'X' or '0;. The base type std_ulogic is an enumerated character type and the character literal '1' can only have an enumerated character type inferred by context (here the condition in the if statement).
– user1155120
Nov 24 '18 at 1:50
add a comment |
0
active
oldest
votes
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
draft saved
draft discarded
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53452959%2fdifferent-interpretations-for-operator-in-vhdl%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
0
active
oldest
votes
0
active
oldest
votes
active
oldest
votes
active
oldest
votes
draft saved
draft discarded
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
draft saved
draft discarded
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53452959%2fdifferent-interpretations-for-operator-in-vhdl%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
There is no possibllity of introducing such a bug. "<=" isn't an assignment operator. Signal assignments are statements, all of which are terminated with a semicolon. A statement isn't part of an expression. (VHDL has no expression statements.) You'll find you're not able to demonstrate your theoretical bug.
– user1155120
Nov 23 '18 at 21:32
1
Expressions are described in IEEE Std 1076-2008 9. Expressions, the BNF in 9.1 is normative. A condition expression used in an if statement in your theoretical example returns a boolean value (10.8 If statement). Expressions are "a formula that defines the computation of a value". "A signal assignment statement modifies the projected output waveforms contained in the drivers of one or more signals (see 14.7.2), schedules a force for one or more signals, or schedules release of one or more signals (see 14.7.3)" (10.5 Signal assignment statement).
– user1155120
Nov 23 '18 at 21:54
3
basically you cant. <= (assignment) is not a function, and cannot be overriden. This is perfectly acceptible and can never cause compiler confusion: a <= b <= c; -- a assinged to b lessthan or equal to c
– Tricky
Nov 23 '18 at 23:42
1
@user1155120 Thank you for the clarification. It was a two-part question actually. In the second part, I was thinking about a bug I had, where I wrote "if a <= '1' " but I actually meant "if a = '1' ". And this led me to question the choice of using the same operator with different meanings depending on the context, I think it makes the code a little bit less readable
– tudorturcu
Nov 24 '18 at 0:53
Note the same usage of "<=" for assignment in SystemVerilog. For a declared as type std_logic condition a <= '1' would be true if a were 'U', 'X' or '0;. The base type std_ulogic is an enumerated character type and the character literal '1' can only have an enumerated character type inferred by context (here the condition in the if statement).
– user1155120
Nov 24 '18 at 1:50