Hacker News Reader

Comment by Gracana | Hacker News Reader

> So far, the bit and byte shifters only shift bits in one direction. However, bits need to be shifted in both directions. One of the key innovations of the 8087's shifter is its bidirectional design: data can be passed through the shifter in reverse to shift bits the opposite direction. This is possible because the shifter is constructed with pass transistors, not logic gates.

That's really cool. I've never really looked at ASIC design so that wasn't something I had considered before. I have a left-shift unit design that uses 74F logic, and to get it to do right shifts I would have to reverse the input and output, which is the typical trick to use when you have to use logic gates.

http://www.pnnk.org/img/lshift_schematic.pdf

http://www.pnnk.org/img/lshift_board.png

View on HN

I have always been fascinated by a paper on barrel shifters myself. I think you would enjoy this as well: https://www.princeton.edu/~rblee/ELE572Papers/Fall04Readings... In particular, logarithmic barrel shifters are amazingly simple to implement better than a massive multiplexer for each shift step.

Edit: oops, after further investigation it looks like you may be doing this in your design?

Oh, nice paper! I had been looking at this one, also by Matthew Pillmeier: https://preserve.lehigh.edu/cgi/viewcontent.cgi?article=1714...

I have a verilog module that implements the "Mux-Based Data Reversal" design with overflow output. Yosys/nextpnr synthesize it with a 102MHz timing estimate on the lattice ice40hx8k.

As for the 74F design, yeah, it uses the logarithmic approach. It still has massive multiplexers, but there's only 5 stages for a full 32 bit shift, plus the extra gates to handle the carry bit.

Thank you so much, I'll ingest this into my system, haha. Also, very cool results, that's really impressive! I'm a computer engineer by trade (primarily FPGAs), so it's always great to see other FPGA engineers (hi!). :)

For what it's worth, you might want to consider other logic families than F. It's no longer the fastest and can be less well-behaved and more power-hungry than others. As well as getting harder and harder to find and more and more expensive.

In terms of speed, you'll find that LVC at 3.3V is likely to outperform F at 5V, and AUC at 3.3V will definitely outperform everything short of ECL -- the catch there is that AUC is technically not specified for 3.3V operation. To stay at 5V, LVC is a good choice if available in the functions you need (LVC is maddeningly inconsistent in that some parts run at 3.6V max and others at 5V max), or look around at the various high-speed families otherwise. The big bus drivers in ABT are great if they're available.

> LVC is a good choice if available in the functions you need

LVC is awesome, but that's the problem I've run into. Even with 74F there are a lot of functions missing, but the options are better.

Another approach you might try is to start with a rotator, then mask off the leading or trailing bits for right or left shifts. (Rotate right by X is the same as rotate left by N-X.)

I chose the mux-based approach because it has the better area*delay product, but it might be interesting to implement the mask-based design to see how it works out on my FPGA.

The design I used should have a delay of one 74'350 and one 74'257 per two bits of shift/rotate index, but that's admittedly still one bit per two of extra muxing.

The version I breadboarded has 8 '350s and 5 '257s for a 16-bit SRU[0]; I'm not sure how to compare that area-wise to a 32-bit circuit without '350s, but you'd at least avoid needing logic to do or not do the bit-reverse.

0: four-function: shr,sar,shl,rol

Reply on news.ycombinator.com