What's the easiest way to bit-wisely reverse a vector?

M

Mr. Ken

Guest
I need to reverse the vector, and prefer simplest codes. One liner is
probably the best. :)

For example,
reg [31:0] mydata;
wire [31:0] mydata_r;

assign mydata_r = mydata[0:31] // Syntax error here.

TIA
 
Mr. Ken wrote:
I need to reverse the vector, and prefer simplest codes. One liner is
probably the best. :)

For example,
reg [31:0] mydata;
wire [31:0] mydata_r;

assign mydata_r = mydata[0:31] // Syntax error here.

TIA
Click to expand...
Use a Verilog2001 generate for loop to assign each bit of mydata to
mydata_r one at a time. The generate stays pretty compact.
 
"John_H" <johnhandwork@mail.com> wrote in message
news:Av_1g.2328$Fy1.1239@trnddc02...
Mr. Ken wrote:
I need to reverse the vector, and prefer simplest codes. One liner is
probably the best. :)

For example,
reg [31:0] mydata;
wire [31:0] mydata_r;

assign mydata_r = mydata[0:31] // Syntax error here.

TIA

Use a Verilog2001 generate for loop to assign each bit of mydata to
mydata_r one at a time. The generate stays pretty compact.
Click to expand...
for loop is nice, but anything more compact? maybe I am expecting too much.
:)
 
"Mr. Ken" <Mr. Ken@asdf> wrote in message
news:444875ee$1@news.starhub.net.sg...
"John_H" <johnhandwork@mail.com> wrote in message
news:Av_1g.2328$Fy1.1239@trnddc02...
Mr. Ken wrote:
I need to reverse the vector, and prefer simplest codes. One liner is
probably the best. :)

For example,
reg [31:0] mydata;
wire [31:0] mydata_r;

assign mydata_r = mydata[0:31] // Syntax error here.

TIA

Use a Verilog2001 generate for loop to assign each bit of mydata to
mydata_r one at a time. The generate stays pretty compact.

for loop is nice, but anything more compact? maybe I am expecting too
much.
Click to expand...
basically a for loop doesn't do well with "assign".
 
A "generate for" loop is different from a "for" loop, whereby the
former is not seen during run-time, much like a compiler directive,
hence wouldn't be causing much problems with assign here ...

Joe
LogicSim - Your Personal Verilog Simulator
http://www.logicsim.com

Mr. Ken wrote:
"Mr. Ken" <Mr. Ken@asdf> wrote in message
news:444875ee$1@news.starhub.net.sg...

"John_H" <johnhandwork@mail.com> wrote in message
news:Av_1g.2328$Fy1.1239@trnddc02...
Mr. Ken wrote:
I need to reverse the vector, and prefer simplest codes. One liner is
probably the best. :)

For example,
reg [31:0] mydata;
wire [31:0] mydata_r;

assign mydata_r = mydata[0:31] // Syntax error here.

TIA

Use a Verilog2001 generate for loop to assign each bit of mydata to
mydata_r one at a time. The generate stays pretty compact.

for loop is nice, but anything more compact? maybe I am expecting too
much.
basically a for loop doesn't do well with "assign".
Click to expand...
 
Mr. Ken wrote:

"Mr. Ken" <Mr. Ken@asdf> wrote in message
news:444875ee$1@news.starhub.net.sg...

"John_H" <johnhandwork@mail.com> wrote in message
news:Av_1g.2328$Fy1.1239@trnddc02...

Mr. Ken wrote:

I need to reverse the vector, and prefer simplest codes. One liner is
probably the best. :)

For example,
reg [31:0] mydata;
wire [31:0] mydata_r;

assign mydata_r = mydata[0:31] // Syntax error here.

TIA

Use a Verilog2001 generate for loop to assign each bit of mydata to
mydata_r one at a time. The generate stays pretty compact.

for loop is nice, but anything more compact? maybe I am expecting too

much.
basically a for loop doesn't do well with "assign".
Click to expand...
That's why one uses the Verilog 2001 "generate" for statement. It's not
your grandfather's for statement.

Bottom line: the Verilog language has strict vector bit order. If you
declare the elements as increasing (e.g., my[0:35]) then the references
all need to be increasing. I'd *love* to be able to swap back & forth,
reversing the bit order to take care of my too-frequent bit-swizzle
needs but a short generate for statement or a fully expanded vector
assignment is the only way I've found to go.

I'll post the syntax of the generate block when I get in to work.
 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John_H wrote:
Mr. Ken wrote:
I need to reverse the vector, and prefer simplest codes. One liner is
probably the best. :)

For example,
reg [31:0] mydata;
wire [31:0] mydata_r;

assign mydata_r = mydata[0:31] // Syntax error here.

TIA

Use a Verilog2001 generate for loop to assign each bit of mydata to
mydata_r one at a time. The generate stays pretty compact.
Click to expand...
Something like this:

genvar i;
for (i=0; i<32; i=i+1) assign mydata_r = mydata[31-i];

(The generate/endgenerate is optional because it is obvious to the
parser that this is a generate loop.)

So it's 2 lines instead of 1. Sorry:)

- --
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFESP0drPt1Sc2b3ikRAiWPAKDsrOOTfBaNlg5sRuEje9VnwgVS8wCgzM1P
p6NVXpUtxD9qbtniF5sca94=
=yTRn
-----END PGP SIGNATURE-----
 
"John_H" <johnhandwork@mail.com> wrote in message
news:6552g.2$ww6.1@trnddc05...

Bottom line: the Verilog language has strict vector bit order. If you
declare the elements as increasing (e.g., my[0:35]) then the references
all need to be increasing. I'd *love* to be able to swap back & forth,
reversing the bit order to take care of my too-frequent bit-swizzle needs
but a short generate for statement or a fully expanded vector assignment
is the only way I've found to go.

I'll post the syntax of the generate block when I get in to work.
Click to expand...
genvar i;
generate
for( i=0; i<8; i=i+1 )
begin : swiz
assign Y = A[7-i];
end
endgenerate
 
I didn't know the Verilog2001 LRM allowed the generate to be optional.
SynplifyPro certainly doesn't like the "obvious" generate block without an
explicit generate/endgenerate. Even the for block needed a name.


"Stephen Williams" <spamtrap@icarus.com> wrote in message
news:8ZednY7UIpCCYNXZRVn-og@giganews.com...
Something like this:

genvar i;
for (i=0; i<32; i=i+1) assign mydata_r = mydata[31-i];

(The generate/endgenerate is optional because it is obvious to the
parser that this is a generate loop.)

So it's 2 lines instead of 1. Sorry:)

- --
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."
Click to expand...
 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John_H wrote:
I didn't know the Verilog2001 LRM allowed the generate to be optional.
SynplifyPro certainly doesn't like the "obvious" generate block without an
explicit generate/endgenerate. Even the for block needed a name.
Click to expand...
The for-loop statement most definitely does *not* need a name. There
is a whole elaborate rule for assigning scope names to generate
blocks that are anonymous is the source code.

As for the generate/endgenerate being optional, I may have gotten
ahead of myself on that one. In fact, I somehow got it in my head
that it is optional (I think I read it in an errata draft) but I
cannot find any definitive reference.

The generate/endgenerate keywords are in fact silly because any
module items (not just generate schemes) are allowed withing them,
so they convey almost no information. Steve Sharp may speak more
authoritatively on this matter (as he often does).

In any case, Icarus Verilog doesn't require generate/endgenerate,
other then to require that generate has a matching endgenerate;-)

"Stephen Williams" <spamtrap@icarus.com> wrote in message
news:8ZednY7UIpCCYNXZRVn-og@giganews.com...
Something like this:

genvar i;
for (i=0; i<32; i=i+1) assign mydata_r = mydata[31-i];

(The generate/endgenerate is optional because it is obvious to the
parser that this is a generate loop.)

So it's 2 lines instead of 1. Sorry:)

- --
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."
Click to expand...


- --
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFESR4mrPt1Sc2b3ikRAqfzAKCDycxsoLWnaZb9bwN42qGTCHpddACfQ/tJ
gAeCZQnuGK2NiKCsnlzSVMQ=
=QfAp
-----END PGP SIGNATURE-----
 
On Fri, 21 Apr 2006 11:02:14 -0700, Stephen Williams
<spamtrap@icarus.com> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John_H wrote:
I didn't know the Verilog2001 LRM allowed the generate to be optional.
Click to expand...
It doesn't. I think you'll find "generate" became optional
in 1364-2005.

The for-loop statement most definitely does *not* need a name.
Click to expand...
Really? Again, I think this is a 1364-2005 relaxation. I'm sure
1364-2001 requires generate-for loop body to be a
labelled begin..end

The generate/endgenerate keywords are in fact silly because any
module items (not just generate schemes) are allowed withing them,
so they convey almost no information. Steve Sharp may speak more
authoritatively on this matter (as he often does).
Click to expand...
Interestingly, though, the relaxation makes it much harder for a
compiler to issue clear diagnostics for certain simple errors,
since a for-loop might now be a generate-loop or simply a
procedural loop written by someone who innocently
forgot the preceding "initial" keyword.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK
Tel: +44 (0)1425 471223 Email: jonathan.bromley@MYCOMPANY.com
Fax: +44 (0)1425 471573 Web: http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
 
Jonathan Bromley wrote:
On Fri, 21 Apr 2006 11:02:14 -0700, Stephen Williams
spamtrap@icarus.com> wrote:

John_H wrote:
I didn't know the Verilog2001 LRM allowed the generate to be optional.

It doesn't. I think you'll find "generate" became optional
in 1364-2005.

The for-loop statement most definitely does *not* need a name.

Really? Again, I think this is a 1364-2005 relaxation. I'm sure
1364-2001 requires generate-for loop body to be a
labelled begin..end
Click to expand...
*sigh* I can't refute you. In Icarus Verilog I implemented it
the "-2005" way because I've been working from some drafts of the
newer generate syntax. So it seems that I'm farther ahead of myself
then I originally thought:-O

I think I need to buy myself a copy of the 1364-2005 standard.


--
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."
 
Some of the changes to generates were intended as corrections to
Verilog-2001, because of significant problems with what was specified
there. After approving the changes, the BTF recommended that
implementations of Verilog-2001 use the revised version. So they could
be considered to be part of a revised Verilog-2001, though there was no
official corrigendum.

Making generate/endgenerate optional was not a necessary correction, so
that could be considered a Verilog-2005 enhancement instead. But there
is not a clear dividing line.

Specifying that conditional generates created scopes was necessary for
practical implementation. Allowing implicit names for those scopes was
necessary to avoid annoyance to users (and to give backward
compatibility with any attempted implementations of the original
specification). But once the implicit naming scheme was added for
conditional generates, there was no reason to continue to require
explicit names for the for-generated scopes. So that change could be
viewed as part of the corrections or as a separate enhancement.
 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

sharp@cadence.com wrote:
Some of the changes to generates were intended as corrections to
Verilog-2001, because of significant problems with what was specified
there. After approving the changes, the BTF recommended that
implementations of Verilog-2001 use the revised version. So they could
be considered to be part of a revised Verilog-2001, though there was no
official corrigendum.
Click to expand...
So with all that said, I might as well leave Icarus Verilog with
the 2005 behavior because it is almost 2001+ behavior anyhow. And
besides, it's a superset so strictly-2001 programs will care.

And my two-line solution that started this whole thread remains
as valid code if you have a newer compiler.
- --
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFESX21rPt1Sc2b3ikRAlHqAJ4l0ohU671A145We2SqirzCuvM++wCcDABl
h4w5nWOBIfU2rL19EzbMENo=
=gDUg
-----END PGP SIGNATURE-----
 
If you want to reverse at the chip's top interface, this works:
module m(
input [31:0] a,
output [31:0] b);
assign b=a;
endmodule
// To this
module m(
input [0:31] a,
output [31:0] b);
assign b=a;
endmodule

T

Mr. Ken wrote:
I need to reverse the vector, and prefer simplest codes. One liner is
probably the best. :)

For example,
reg [31:0] mydata;
wire [31:0] mydata_r;

assign mydata_r = mydata[0:31] // Syntax error here.

TIA
Click to expand...
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top