bi-directional shift/rotate Byte

[Hezi]

Hi everyone,

I've designed a bi-directional shift/rotate Byte register based on the knowledge from this course and I'd like to hear people's opinion about it, if you see any flaws in it, or if it can be improved somehow.

There is no hdl file because this design seems to be incompatible with the syntax of hdl. It can be done, but it's too complicated to put in the effort. Unless I am missing some genius hack.

A logisim file to test the design:
Byte.circ


The diagram:

[WBahn]

It's pretty hard to follow the design -- you should try to clean up the schematic.

What should happen if multiple inputs are asserted? Is there a precedence to them?

What should happen if none of the inputs are asserted? Is there a default behavior?

Are your shifts logical shifts with no provision for arithmetic shifts?

You can implement this in the HDL -- it shouldn't be too hard. There are several ways to approach it. One would be to make a part that is a single bit of your shift register and the mux for that bit's input. Tap those signals off a bus. Then at the top level just tie eight of those parts together with a bit of glue logic at each end and your top-level decode logic and you're done.

[Hezi]

Thanks for the reply.

I will keep in mind to make cleaner diagrams.

order of precedence:

In short: except for undefined states - right precedes left, shift precedes rotation, all precedes load.

Undefined states:
If lshift and rshift, or lshift and rrot, are asserted, the result is undefined.

In detail:
If rshift is asserted, the result is a right shift (no matter what else is asserted).
If rshift is de-asserted, and rrot is asserted, the result is a right rotation (no matter what else is asserted).
If rshift and rrot are de-asserted, and lshift is asserted, the result is a left shift (no matter what else is asserted).
If other than lrot and load all is de-asserted, and lrot is asserted, the result is a left rotation whether load is asserted or not.
If load is the only asserted bit, the result is load.
If no bit is asserted the result is no change Register(t+1)=Register(t)

I thought about eliminating the undefined states, but I figured if the register is going to be part of a memory chip it may be cheaper to eliminate them for the entire chip then to do it for each register. Obviously I don't know how is it done in real life.

What do you mean by "no provision for arithmetic shifts"? AFAIK a left shift is a multiplication by 2 and a right shift is an integer division by 2. But that should be true for my design. Is there anything else?

Your suggestion for implementing an HDL is changing the design. I know how to implement *a* bi-directional shift/rotate Byte register in HDL, but I couldn't find an easy way to implement *this* design in HDL.

I did not follow the general line of the course - to use as little chip parts *in an HDL implementation* as possible. I know I could encapsulate the MUX logic in a separate design and only have inputs, output and 8 bit chips in this design, but that would bind the number of MUXes (and possibly the number of ORs also) to the number of bits in the register. In my design, if I am not mistaken, one could increase the number of bits and still only have only one MUX and 2 ORs, limited only by the space on the board available for the width of the bus (at least theoretically). I don't know if that is a good practice for designing chips, but that is what I was going for.

[WBahn]

Hezi wrote

What do you mean by "no provision for arithmetic shifts"? AFAIK a left shift is a multiplication by 2 and a right shift is an integer division by 2. But that should be true for my design. Is there anything else?

So let's say that the number in the register is -2. What will the value be after you right shift it one place? Is it -1 or is it 127?

Therein lies the distinction between a logical right shift and an arithmetic right shift.

Your suggestion for implementing an HDL is changing the design. I know how to implement *a* bi-directional shift/rotate Byte register in HDL, but I couldn't find an easy way to implement *this* design in HDL.

Depends on what you consider a changed design. I think I could write an HDL file that if one circuit were built from your diagram and another from the HDL file, the two circuits would be identical. Only the conceptual organization would be different.

I did not follow the general line of the course - to use as little chip parts *in an HDL implementation* as possible. I know I could encapsulate the MUX logic in a separate design and only have inputs, output and 8 bit chips in this design, but that would bind the number of MUXes (and possibly the number of ORs also) to the number of bits in the register. In my design, if I am not mistaken, one could increase the number of bits and still only have only one MUX and 2 ORs, limited only by the space on the board available for the width of the bus (at least theoretically). I don't know if that is a good practice for designing chips, but that is what I was going for.

That rule from the course has to be taken with a huge grain of salt. At the very least, the number of chips instantiated by the parts being called has to be taken into account. Also, starting with nothing but NAND gates means significant inefficiencies from the start. Consider the implementation of a NOR this way. It would be an OR followed by a NOT. But then the OR is built from one NAND and two NOTs and a NOT is built from a NAND, so four NAND gates. Yet in the real world a NOR is built as a fundamental gate and is the same size as a NAND (each has four transistors in classic CMOS) and an OR is built using a NOR followed by a NOT (that uses just two transistors).

I think what the authors are going for is conceptual complexity but they wonder off on a tangent that really isn't justified.