EDAboard.com | EDAboard.de | EDAboard.co.uk | WTWH Media

sign extension in Verilog 2001

Ask a question - edaboard.com

elektroda.net NewsGroups Forum Index - Verilog Language - sign extension in Verilog 2001

Goto page 1, 2  Next

TJ Edmister
Guest

Mon Apr 13, 2020 9:45 pm   



Greetings, I have a question about usage of $signed in verilog 2001. I had
thought this could be used for sign extension and I employed it in various
places in my design. But when I simulate with Icarus verilog I find that
it is not doing the sign extension.

cpupc <= cpupc + $signed({branchloc2, 1'b0});

cpupc is a 32-bit value and I wanted the branch offset (which is 10 bits
plus a 0 bit to make it even) to be sign extended so I can branch backward
as well as forward... :)

Since this failed in the simulation, I replaced that code with this "old"
way of doing sign extension, and this one does work:

cpupc <= cpupc + {{21{branchloc2[9]}}, branchloc2, 1'b0};

I don't like the look of this one quite as much, is it the only way to do
sign extension? How is $signed supposed to be used?

Richard Damon
Guest

Tue Apr 14, 2020 1:45 am   



On 4/13/20 4:32 PM, TJ Edmister wrote:
Quote:
Greetings, I have a question about usage of $signed in verilog 2001. I
had thought this could be used for sign extension and I employed it in
various places in my design. But when I simulate with Icarus verilog I
find that it is not doing the sign extension.

cpupc <= cpupc + $signed({branchloc2, 1'b0});

cpupc is a 32-bit value and I wanted the branch offset (which is 10 bits
plus a 0 bit to make it even) to be sign extended so I can branch
backward as well as forward... :)

Since this failed in the simulation, I replaced that code with this
"old" way of doing sign extension, and this one does work:

cpupc <= cpupc + {{21{branchloc2[9]}}, branchloc2, 1'b0};

I don't like the look of this one quite as much, is it the only way to
do sign extension? How is $signed supposed to be used?


I think the issue is that cpupc is probably unsigned, and an unsigned
plus a signed is done as unsigned, so that branchloc2 isn't signed extended.

If you made a 32 bit signed wire that you put brancedloc2 into first
then you could get the results you want.

Maybe you could also do:

cpupc <= $signed(cpupc) + $signed({branchloc2, 1'b0});

Rick C
Guest

Tue Apr 14, 2020 2:45 am   



On Monday, April 13, 2020 at 8:09:45 PM UTC-4, Richard Damon wrote:
Quote:
On 4/13/20 4:32 PM, TJ Edmister wrote:
Greetings, I have a question about usage of $signed in verilog 2001. I
had thought this could be used for sign extension and I employed it in
various places in my design. But when I simulate with Icarus verilog I
find that it is not doing the sign extension.

cpupc <= cpupc + $signed({branchloc2, 1'b0});

cpupc is a 32-bit value and I wanted the branch offset (which is 10 bits
plus a 0 bit to make it even) to be sign extended so I can branch
backward as well as forward... :)

Since this failed in the simulation, I replaced that code with this
"old" way of doing sign extension, and this one does work:

cpupc <= cpupc + {{21{branchloc2[9]}}, branchloc2, 1'b0};

I don't like the look of this one quite as much, is it the only way to
do sign extension? How is $signed supposed to be used?

I think the issue is that cpupc is probably unsigned, and an unsigned
plus a signed is done as unsigned, so that branchloc2 isn't signed extended.

If you made a 32 bit signed wire that you put brancedloc2 into first
then you could get the results you want.

Maybe you could also do:

cpupc <= $signed(cpupc) + $signed({branchloc2, 1'b0});


This is the sort of issue I have been warned about with Verilog. I would like to learn the details so I can use the language without fighting issues like this. Is there a good book on the language that explains all the default assumptions the language uses so as to fully understand what to expect? I've asked about this a number of times and no one seems to know of a good reference.

--

Rick C.

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

Richard Damon
Guest

Tue Apr 14, 2020 3:45 am   



On 4/13/20 9:08 PM, Rick C wrote:
Quote:
On Monday, April 13, 2020 at 8:09:45 PM UTC-4, Richard Damon wrote:
On 4/13/20 4:32 PM, TJ Edmister wrote:
Greetings, I have a question about usage of $signed in verilog 2001. I
had thought this could be used for sign extension and I employed it in
various places in my design. But when I simulate with Icarus verilog I
find that it is not doing the sign extension.

cpupc <= cpupc + $signed({branchloc2, 1'b0});

cpupc is a 32-bit value and I wanted the branch offset (which is 10 bits
plus a 0 bit to make it even) to be sign extended so I can branch
backward as well as forward... :)

Since this failed in the simulation, I replaced that code with this
"old" way of doing sign extension, and this one does work:

cpupc <= cpupc + {{21{branchloc2[9]}}, branchloc2, 1'b0};

I don't like the look of this one quite as much, is it the only way to
do sign extension? How is $signed supposed to be used?

I think the issue is that cpupc is probably unsigned, and an unsigned
plus a signed is done as unsigned, so that branchloc2 isn't signed extended.

If you made a 32 bit signed wire that you put brancedloc2 into first
then you could get the results you want.

Maybe you could also do:

cpupc <= $signed(cpupc) + $signed({branchloc2, 1'b0});

This is the sort of issue I have been warned about with Verilog. I would like to learn the details so I can use the language without fighting issues like this. Is there a good book on the language that explains all the default assumptions the language uses so as to fully understand what to expect? I've asked about this a number of times and no one seems to know of a good reference.


I figured it out with a bit of google-fu, where I found this document:
<https://sutherland-hdl.com/papers/2006-SNUG-Boston_standard_gotchas_presentation.pdf>

Which explains a number of traps like that.

Rick C
Guest

Tue Apr 14, 2020 4:45 am   



On Monday, April 13, 2020 at 9:51:06 PM UTC-4, Richard Damon wrote:
Quote:
On 4/13/20 9:08 PM, Rick C wrote:

This is the sort of issue I have been warned about with Verilog. I would like to learn the details so I can use the language without fighting issues like this. Is there a good book on the language that explains all the default assumptions the language uses so as to fully understand what to expect? I've asked about this a number of times and no one seems to know of a good reference.


I figured it out with a bit of google-fu, where I found this document:
https://sutherland-hdl.com/papers/2006-SNUG-Boston_standard_gotchas_presentation.pdf

Which explains a number of traps like that.


Great guide. The one on sign extending literals is pathological. I like that they tell you to avoid this problem to "learn Verilog's sign extension rules!" but don't tell you how to do it correctly. I guess there is no "correct" way other than entering all the bits?

I'm seven items into the list and it's getting a bit deep for my waders. I'll go back to this when I sit down to learn Verilog. There's one guy I know who swears up and down everyone who learns Verilog will prefer it and be more productive. So one day I will give it a serious try.

Thanks.

--

Rick C.

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

TJ Edmister
Guest

Tue Apr 14, 2020 3:45 pm   



On Mon, 13 Apr 2020 20:09:42 -0400, Richard Damon
<Richard_at_Damon-Family.org> wrote:

Quote:
On 4/13/20 4:32 PM, TJ Edmister wrote:
Greetings, I have a question about usage of $signed in verilog 2001. I
had thought this could be used for sign extension and I employed it in
various places in my design. But when I simulate with Icarus verilog I
find that it is not doing the sign extension.

cpupc <= cpupc + $signed({branchloc2, 1'b0});

cpupc is a 32-bit value and I wanted the branch offset (which is 10 bits
plus a 0 bit to make it even) to be sign extended so I can branch
backward as well as forward... :)

Since this failed in the simulation, I replaced that code with this
"old" way of doing sign extension, and this one does work:

cpupc <= cpupc + {{21{branchloc2[9]}}, branchloc2, 1'b0};

I don't like the look of this one quite as much, is it the only way to
do sign extension? How is $signed supposed to be used?

I think the issue is that cpupc is probably unsigned, and an unsigned
plus a signed is done as unsigned, so that branchloc2 isn't signed
extended.

If you made a 32 bit signed wire that you put brancedloc2 into first
then you could get the results you want.

Maybe you could also do:

cpupc <= $signed(cpupc) + $signed({branchloc2, 1'b0});


Thanks for posting. I'm thinking that if it is this finicky maybe I'll use
it only for plain old assignments, and then enumerate the bits myself in
any expression that involves computation.

Rick C
Guest

Tue Apr 14, 2020 7:45 pm   



On Tuesday, April 14, 2020 at 10:09:46 AM UTC-4, TJ Edmister wrote:
Quote:
On Mon, 13 Apr 2020 20:09:42 -0400, Richard Damon
Richard_at_Damon-Family.org> wrote:

On 4/13/20 4:32 PM, TJ Edmister wrote:
Greetings, I have a question about usage of $signed in verilog 2001. I
had thought this could be used for sign extension and I employed it in
various places in my design. But when I simulate with Icarus verilog I
find that it is not doing the sign extension.

cpupc <= cpupc + $signed({branchloc2, 1'b0});

cpupc is a 32-bit value and I wanted the branch offset (which is 10 bits
plus a 0 bit to make it even) to be sign extended so I can branch
backward as well as forward... :)

Since this failed in the simulation, I replaced that code with this
"old" way of doing sign extension, and this one does work:

cpupc <= cpupc + {{21{branchloc2[9]}}, branchloc2, 1'b0};

I don't like the look of this one quite as much, is it the only way to
do sign extension? How is $signed supposed to be used?

I think the issue is that cpupc is probably unsigned, and an unsigned
plus a signed is done as unsigned, so that branchloc2 isn't signed
extended.

If you made a 32 bit signed wire that you put brancedloc2 into first
then you could get the results you want.

Maybe you could also do:

cpupc <= $signed(cpupc) + $signed({branchloc2, 1'b0});

Thanks for posting. I'm thinking that if it is this finicky maybe I'll use
it only for plain old assignments, and then enumerate the bits myself in
any expression that involves computation.


Actually this is just the language asking you to explain exactly what you mean. Trust me, as a VHDL user, I get that! In fact, in VHDL you would then need to type cast the value back to unsigned before it would allow the summation! In VHDL operators are overloaded depending on the types of arguments and results. There is no summation operator for adding

In VHDL the sign extension would also need to be explicit which is really the root of the problem in Verilog, the assumed sign extension that doesn't happen.

cpupc <= cpupc + unsigned(resize((branchloc2 & "0"), cpupc'length));

Is there no resize() operator in Verilog?

--

Rick C.

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

Richard Damon
Guest

Tue Apr 14, 2020 8:45 pm   



On 4/13/20 10:54 PM, Rick C wrote:
Quote:
On Monday, April 13, 2020 at 9:51:06 PM UTC-4, Richard Damon wrote:
On 4/13/20 9:08 PM, Rick C wrote:

This is the sort of issue I have been warned about with Verilog. I would like to learn the details so I can use the language without fighting issues like this. Is there a good book on the language that explains all the default assumptions the language uses so as to fully understand what to expect? I've asked about this a number of times and no one seems to know of a good reference.


I figured it out with a bit of google-fu, where I found this document:
https://sutherland-hdl.com/papers/2006-SNUG-Boston_standard_gotchas_presentation.pdf

Which explains a number of traps like that.

Great guide. The one on sign extending literals is pathological. I like that they tell you to avoid this problem to "learn Verilog's sign extension rules!" but don't tell you how to do it correctly. I guess there is no "correct" way other than entering all the bits?


Yes, because the literal is ALWAYS zero extended to its declared size.
Sign extension of the value only happens after that, and only if the
operation will be done as a signed operation. You only get signed
operations if ALL the signals in the expression are signed.
Quote:

I'm seven items into the list and it's getting a bit deep for my waders. I'll go back to this when I sit down to learn Verilog. There's one guy I know who swears up and down everyone who learns Verilog will prefer it and be more productive. So one day I will give it a serious try.

Thanks.


Rick C
Guest

Tue Apr 14, 2020 11:45 pm   



On Tuesday, April 14, 2020 at 2:58:12 PM UTC-4, Richard Damon wrote:
Quote:
On 4/13/20 10:54 PM, Rick C wrote:
On Monday, April 13, 2020 at 9:51:06 PM UTC-4, Richard Damon wrote:
On 4/13/20 9:08 PM, Rick C wrote:

This is the sort of issue I have been warned about with Verilog. I would like to learn the details so I can use the language without fighting issues like this. Is there a good book on the language that explains all the default assumptions the language uses so as to fully understand what to expect? I've asked about this a number of times and no one seems to know of a good reference.


I figured it out with a bit of google-fu, where I found this document:
https://sutherland-hdl.com/papers/2006-SNUG-Boston_standard_gotchas_presentation.pdf

Which explains a number of traps like that.

Great guide. The one on sign extending literals is pathological. I like that they tell you to avoid this problem to "learn Verilog's sign extension rules!" but don't tell you how to do it correctly. I guess there is no "correct" way other than entering all the bits?

Yes, because the literal is ALWAYS zero extended to its declared size.
Sign extension of the value only happens after that, and only if the
operation will be done as a signed operation. You only get signed
operations if ALL the signals in the expression are signed.


Not sure I get what you are saying. After there are zeros appended to match sizes, there is no extension. What do you mean by "Sign extension of the value only happens after that"??? It looks like there is never automatic sign extension. Once the zeros are appended it's too late anyway.

--

Rick C.

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

Rick C
Guest

Wed Apr 15, 2020 12:45 am   



On Tuesday, April 14, 2020 at 6:46:46 PM UTC-4, Richard Damon wrote:
Quote:
On 4/14/20 6:17 PM, Rick C wrote:
On Tuesday, April 14, 2020 at 2:58:12 PM UTC-4, Richard Damon wrote:
On 4/13/20 10:54 PM, Rick C wrote:
On Monday, April 13, 2020 at 9:51:06 PM UTC-4, Richard Damon wrote:
On 4/13/20 9:08 PM, Rick C wrote:

This is the sort of issue I have been warned about with Verilog. I would like to learn the details so I can use the language without fighting issues like this. Is there a good book on the language that explains all the default assumptions the language uses so as to fully understand what to expect? I've asked about this a number of times and no one seems to know of a good reference.


I figured it out with a bit of google-fu, where I found this document:
https://sutherland-hdl.com/papers/2006-SNUG-Boston_standard_gotchas_presentation.pdf

Which explains a number of traps like that.

Great guide. The one on sign extending literals is pathological. I like that they tell you to avoid this problem to "learn Verilog's sign extension rules!" but don't tell you how to do it correctly. I guess there is no "correct" way other than entering all the bits?

Yes, because the literal is ALWAYS zero extended to its declared size.
Sign extension of the value only happens after that, and only if the
operation will be done as a signed operation. You only get signed
operations if ALL the signals in the expression are signed.

Not sure I get what you are saying. After there are zeros appended to match sizes, there is no extension. What do you mean by "Sign extension of the value only happens after that"??? It looks like there is never automatic sign extension. Once the zeros are appended it's too late anyway.


If you take 4'sb1111 + 3'sb111 then the 3 ones will be extended to 4
bits with sign extension, or if two signed vectors get operated on
together, the smaller will get extended to match the size of the larger.
(Or possibly bigger, as the size of the result can also cause the fields
to get extended).

In a literal of the form x'sby, if the value y takes less than x bits,
it is zero extended to that size, and THEN if that literal needs to be
expanded to be used in the expression, the MSB of that value is check to
decide sign extension.


Thank you, that is clear.

I'm not very conversant in Verilog so perhaps you can explain some details.

cpupc <= $signed(cpupc) + $signed({branchloc2, 1'b0});

This works I assume. If branchloc2 is a signed quantity would this also work?

cpupc <= $signed(cpupc) + {branchloc2, 1'b0};

I assume the aggregate would then be signed and would be properly sign extended?

--

Rick C.

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

Richard Damon
Guest

Wed Apr 15, 2020 12:45 am   



On 4/14/20 6:17 PM, Rick C wrote:
Quote:
On Tuesday, April 14, 2020 at 2:58:12 PM UTC-4, Richard Damon wrote:
On 4/13/20 10:54 PM, Rick C wrote:
On Monday, April 13, 2020 at 9:51:06 PM UTC-4, Richard Damon wrote:
On 4/13/20 9:08 PM, Rick C wrote:

This is the sort of issue I have been warned about with Verilog. I would like to learn the details so I can use the language without fighting issues like this. Is there a good book on the language that explains all the default assumptions the language uses so as to fully understand what to expect? I've asked about this a number of times and no one seems to know of a good reference.


I figured it out with a bit of google-fu, where I found this document:
https://sutherland-hdl.com/papers/2006-SNUG-Boston_standard_gotchas_presentation.pdf

Which explains a number of traps like that.

Great guide. The one on sign extending literals is pathological. I like that they tell you to avoid this problem to "learn Verilog's sign extension rules!" but don't tell you how to do it correctly. I guess there is no "correct" way other than entering all the bits?

Yes, because the literal is ALWAYS zero extended to its declared size.
Sign extension of the value only happens after that, and only if the
operation will be done as a signed operation. You only get signed
operations if ALL the signals in the expression are signed.

Not sure I get what you are saying. After there are zeros appended to match sizes, there is no extension. What do you mean by "Sign extension of the value only happens after that"??? It looks like there is never automatic sign extension. Once the zeros are appended it's too late anyway.


If you take 4'sb1111 + 3'sb111 then the 3 ones will be extended to 4
bits with sign extension, or if two signed vectors get operated on
together, the smaller will get extended to match the size of the larger.
(Or possibly bigger, as the size of the result can also cause the fields
to get extended).

In a literal of the form x'sby, if the value y takes less than x bits,
it is zero extended to that size, and THEN if that literal needs to be
expanded to be used in the expression, the MSB of that value is check to
decide sign extension.

Richard Damon
Guest

Wed Apr 15, 2020 4:45 am   



On 4/14/20 7:06 PM, Rick C wrote:
Quote:
On Tuesday, April 14, 2020 at 6:46:46 PM UTC-4, Richard Damon wrote:
On 4/14/20 6:17 PM, Rick C wrote:
On Tuesday, April 14, 2020 at 2:58:12 PM UTC-4, Richard Damon wrote:
On 4/13/20 10:54 PM, Rick C wrote:
On Monday, April 13, 2020 at 9:51:06 PM UTC-4, Richard Damon wrote:
On 4/13/20 9:08 PM, Rick C wrote:

This is the sort of issue I have been warned about with Verilog. I would like to learn the details so I can use the language without fighting issues like this. Is there a good book on the language that explains all the default assumptions the language uses so as to fully understand what to expect? I've asked about this a number of times and no one seems to know of a good reference.


I figured it out with a bit of google-fu, where I found this document:
https://sutherland-hdl.com/papers/2006-SNUG-Boston_standard_gotchas_presentation.pdf

Which explains a number of traps like that.

Great guide. The one on sign extending literals is pathological. I like that they tell you to avoid this problem to "learn Verilog's sign extension rules!" but don't tell you how to do it correctly. I guess there is no "correct" way other than entering all the bits?

Yes, because the literal is ALWAYS zero extended to its declared size.
Sign extension of the value only happens after that, and only if the
operation will be done as a signed operation. You only get signed
operations if ALL the signals in the expression are signed.

Not sure I get what you are saying. After there are zeros appended to match sizes, there is no extension. What do you mean by "Sign extension of the value only happens after that"??? It looks like there is never automatic sign extension. Once the zeros are appended it's too late anyway.


If you take 4'sb1111 + 3'sb111 then the 3 ones will be extended to 4
bits with sign extension, or if two signed vectors get operated on
together, the smaller will get extended to match the size of the larger.
(Or possibly bigger, as the size of the result can also cause the fields
to get extended).

In a literal of the form x'sby, if the value y takes less than x bits,
it is zero extended to that size, and THEN if that literal needs to be
expanded to be used in the expression, the MSB of that value is check to
decide sign extension.

Thank you, that is clear.

I'm not very conversant in Verilog so perhaps you can explain some details.

cpupc <= $signed(cpupc) + $signed({branchloc2, 1'b0});


Yes, I think that would work. The term will be computed as signed, and
the offset should be thus sign extended.

Quote:

This works I assume. If branchloc2 is a signed quantity would this also work?

cpupc <= $signed(cpupc) + {branchloc2, 1'b0};


you might need it to be

cpupc <= $signed(cpupc) {branchloc2, 1'sb0 }

so the unsigned 0 bit doesn't pollute the signedness of the computation.
Quote:

I assume the aggregate would then be signed and would be properly sign extended?


I will confess I don't know about that. This is getting into a corner of
the language I haven't used much of. It might work, or it might not.

Kevin Neilson
Guest

Sun Apr 19, 2020 6:45 pm   



On Monday, April 13, 2020 at 2:32:23 PM UTC-6, TJ Edmister wrote:
Quote:
Greetings, I have a question about usage of $signed in verilog 2001. I had
thought this could be used for sign extension and I employed it in various
places in my design. But when I simulate with Icarus verilog I find that
it is not doing the sign extension.

cpupc <= cpupc + $signed({branchloc2, 1'b0});

cpupc is a 32-bit value and I wanted the branch offset (which is 10 bits
plus a 0 bit to make it even) to be sign extended so I can branch backward
as well as forward... :)

Since this failed in the simulation, I replaced that code with this "old"
way of doing sign extension, and this one does work:

cpupc <= cpupc + {{21{branchloc2[9]}}, branchloc2, 1'b0};

I don't like the look of this one quite as much, is it the only way to do
sign extension? How is $signed supposed to be used?


I usually use an intermediate sign-extended version of the addend, which is a little clumsy.
Below are three examples of methods that work. I was surprised to find that Richard D's method of converting cpupc to $signed before the addition was successful. Then there is my intermediate sign extension. Last is casting to an integer. I don't use this because it's Systemverilog and too many customers whine when you use Systemverilog because it's too "new" (2009).

reg [31:0] cpupc;
reg signed [9:0] branchloc2 = -4;
wire signed [$left(cpupc):0] branchloc2_sgnext = branchloc2;

initial begin
// convert cpupc to signed before addition
cpupc = 64; cpupc = $signed(cpupc) + (branchloc2<<<1);
$display("cpupc: %0d", cpupc);

// use sign-extended version of branchloc2
cpupc = 64; cpupc = cpupc + (branchloc2_sgnext<<<1);
$display("cpupc: %0d", cpupc);

// Systemverilog casting to signed integer
cpupc = 64; cpupc = cpupc + (int'(branchloc2))*2;
$display("cpupc: %0d", cpupc);
end

ucli% run;
cpupc: 56
cpupc: 56
cpupc: 56

Rick C
Guest

Mon Apr 20, 2020 7:45 am   



On Sunday, April 19, 2020 at 1:17:01 PM UTC-4, Kevin Neilson wrote:
Quote:
On Monday, April 13, 2020 at 2:32:23 PM UTC-6, TJ Edmister wrote:
Greetings, I have a question about usage of $signed in verilog 2001. I had
thought this could be used for sign extension and I employed it in various
places in my design. But when I simulate with Icarus verilog I find that
it is not doing the sign extension.

cpupc <= cpupc + $signed({branchloc2, 1'b0});

cpupc is a 32-bit value and I wanted the branch offset (which is 10 bits
plus a 0 bit to make it even) to be sign extended so I can branch backward
as well as forward... :)

Since this failed in the simulation, I replaced that code with this "old"
way of doing sign extension, and this one does work:

cpupc <= cpupc + {{21{branchloc2[9]}}, branchloc2, 1'b0};

I don't like the look of this one quite as much, is it the only way to do
sign extension? How is $signed supposed to be used?

I usually use an intermediate sign-extended version of the addend, which is a little clumsy.
Below are three examples of methods that work. I was surprised to find that Richard D's method of converting cpupc to $signed before the addition was successful. Then there is my intermediate sign extension. Last is casting to an integer. I don't use this because it's Systemverilog and too many customers whine when you use Systemverilog because it's too "new" (2009).

reg [31:0] cpupc;
reg signed [9:0] branchloc2 = -4;
wire signed [$left(cpupc):0] branchloc2_sgnext = branchloc2;

initial begin
// convert cpupc to signed before addition
cpupc = 64; cpupc = $signed(cpupc) + (branchloc2<<<1);
$display("cpupc: %0d", cpupc);

// use sign-extended version of branchloc2
cpupc = 64; cpupc = cpupc + (branchloc2_sgnext<<<1);
$display("cpupc: %0d", cpupc);

// Systemverilog casting to signed integer
cpupc = 64; cpupc = cpupc + (int'(branchloc2))*2;
$display("cpupc: %0d", cpupc);
end

ucli% run;
cpupc: 56
cpupc: 56
cpupc: 56


In the second version, is the assignment to branchloc2_sgnext a regular concurrent statement or is this only executed during initialization?

In the third case w
hat size is an int in Verilog? Is it like VHDL, 32 bits by default? If cpupc were less than 32 bits would that be a problem? If cpupc were more than 32 bits would that be a problem?

--

Rick C.

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

Kevin Neilson
Guest

Mon Apr 20, 2020 5:45 pm   



Quote:

In the second version, is the assignment to branchloc2_sgnext a regular concurrent statement or is this only executed during initialization?

branchloc2_sgnext is a continuous assignment so it is automatically updated whenever branchloc2 is.


Quote:
In the third case w
hat size is an int in Verilog? Is it like VHDL, 32 bits by default? If cpupc were less than 32 bits would that be a problem? If cpupc were more than 32 bits would that be a problem?

I believe an 'int' is always 32 bits, so this case would probably not work if cpupc were bigger than 32 bits.


Goto page 1, 2  Next

elektroda.net NewsGroups Forum Index - Verilog Language - sign extension in Verilog 2001

Ask a question - edaboard.com

Arabic version Bulgarian version Catalan version Czech version Danish version German version Greek version English version Spanish version Finnish version French version Hindi version Croatian version Indonesian version Italian version Hebrew version Japanese version Korean version Lithuanian version Latvian version Dutch version Norwegian version Polish version Portuguese version Romanian version Russian version Slovak version Slovenian version Serbian version Swedish version Tagalog version Ukrainian version Vietnamese version Chinese version Turkish version
EDAboard.com map