Minor Clarification Point for (un)shuffle

20 views
Skip to first unread message

jsb...@bu.edu

unread,
Nov 13, 2018, 7:56:48 PM11/13/18
to riscv-xbitmanip
Hi xbitmanip group,

One thing as far as the spec goes that may be worthwhile for clarity.  In the section on shuffle and unshuffle, it's not immediately clear that the LSB of rs2 or the mode immediate being set indicates an unshuffle, or it being unset indicates a shuffle.  Tables 2.2 and 2.3 hint at this after a bit of closer reading, and the supplied verilog samples in the xbitmanip repo clearly show this; however, the C code explanations starting on page 13 after Figure 2.3 of the permutation network without flip stages does not agree with this, or at best leads to confusion.  In the C provided at there, for the input rs2 we check if bits zero, one, two, etc are set, rather than checking if bits one, two, three, and so on are set, which is closer to everything around it.

If I'm incorrect in understanding how the (un)shuffle operations are intended to be denoted via rs2 or the mode field, please let me know.  But it still would seem to me that the C code in the spec seems a little off when looked at next to the verilog and other notes around in that section.

Thanks

John Burke

Clifford Wolf

unread,
Nov 15, 2018, 5:45:52 AM11/15/18
to jsb...@bu.edu, riscv-x...@googlegroups.com
Hi,

there have been some changes to this operation when it was renamed from 'gzip' to 'shfl/ushfl' unfortunately there have still been a few traces of the old behavior in the spec. I gave it another pass now and I hope the behavior of shfl/unshfl/shfli/unshfli is much clearer now in the updated draft pdf.

But to answer your question directly: shfl/unshfl are two different instructions. The type of instruction select which operations is performed. The value of rs2 only select which shfl/unshfl operation to perform, but it does not select between shfl and unshfl.

The C code is the formal part of the spec. The Verilog code is just there for demonstration purposes.

In case of shfl/unshfl the Verilog code still implements the old gzip semantic. (The difference isn't really relevant for area and speed estimates, and that's the main purpose of those Verilog modules.) That's also why I haven't renamed the Verilog modules yet.

regards,
 - Clifford
--
You received this message because you are subscribed to the Google Groups "riscv-xbitmanip" group.
To unsubscribe from this group and stop receiving emails from it, send an email to riscv-xbitman...@googlegroups.com.
To post to this group, send email to riscv-x...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/riscv-xbitmanip/20154921-998c-4505-808b-70dffbecf923%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

jsb...@bu.edu

unread,
Nov 15, 2018, 1:48:56 PM11/15/18
to riscv-xbitmanip
Thanks kindly!

It's a lot clearer now and your direct response is exactly what I was hoping for.

The only nit-pick I'd have at this point is that the instruction listing at the end of the section only lists SHFL and SHFLI, UNSHFL and UNSHFLI are absent.  It's super minor, but I forked your repo and made that change on it.  I can PR that if it will be helpful

-John
Reply all
Reply to author
Forward
0 new messages