Reorder shift register bits with custom Verilog?

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
TePh_4811091
Level 1
Level 1
First question asked 5 sign-ins First reply posted

Greetings - I'm working on a logging project where I'm capturing data into 5x 32 bit shift registers, each with a stream of 13 words (call it a frame) with approx 100Hz clock cycle in 10 frame bursts. The design of the equipment I'm logging has reordered the 5 different data streams into 5 different bit orders even though they all represent the same data. I'd like to normalize the data back to a consistent format as I ultimately need to do a lookup of the bytes to the data values they represent. One thought I had would be a modified Shift Register with Verilog. I'll qualify this by saying I know very little about Verilog, but I'm interested in learning...

Q: Would it be possible to design a SR with the bits in a non-sequential order? My google'fu returned an example of a SR that initially started off as:

reg bit0;
reg bit1;
reg bit2;
reg bit3;

assign shift_out = bit3;

always @(posedge clock) begin
  bit3 <= bit2;
  bit2 <= bit1;
  bit1 <= bit0;
  bit0 <= shift_in;
end

And progressed to a more compact style of:

reg [3:0] bits;

assign shift_out = bits[3];

always @(posedge clock) begin

  bits <= bits << 1;
  bits[0] <= shift_in;
end

If the data stream was a value of 1010 and the first iteration was rearranged such as:

always @(posedge clock) begin

  bit2 <= bit3;  // Changed

  bit3 <= bit1;  // Changed

  bit1 <= bit0;

  bit0 <= shift_in;

end

Would that not produce 0110? Is this even possible?

The other thing I do not yet fully grasp (looking at the Cypress BSiftReg_v2_30)  is how/where the values of the bits translate to the bytes from which the data is retrieved. Right now I'm going off the assumption the rearranged bit shift order would not effect the bytes output.

If what I'm trying to achieve is remotely possible, I'll bang on it till I figure it out. But if I'm barking up the wrong tree OR there's an easier way to perform bit reordering I'm open for suggestions. Just trying to take advantage of the PSoC platform and avoid software solutions. Open to suggestions,,,

TIA,

-Terry

0 Likes
4 Replies
TePh_4811091
Level 1
Level 1
First question asked 5 sign-ins First reply posted

Ok - reading over the Component Author Guide, at least the included Shift Register makes more sense now. But I'm still brain-storming for a solution.

-Terry

0 Likes

TePh,

Lets keep shift register working as usual and swap bits using intermediate location

/odissey1

reg [3:0] bits;

//assign shift_out = bits[3]

//rearrange bits using intermediate location

wire [3:0] tmp = {bits[1], bits[3], bits[1], bits[0]};

assign shift_out = tmp[3];

always @(posedge clock) begin

  bits <= bits << 1;
  bits[0] <= shift_in;
end

0 Likes
RodolfoGL
Employee
Employee
250 solutions authored 250 sign-ins 5 comments on KBA

One way to solve this is to use one datapath as a parallel output (PO) and another one as a parallel input(PI).

The PO datapath is configured a shift register.

The PI datapath is configured as FIFO only, load ALU to FIFO.

You can have whatever combination you want between these two datapath by linking the PO and PI.

The only catch is that you might burn many datapaths. If you need to have 5x 32-bit datapath, you would runout of it.

In your example, you just show 4-bits. Can you show an example with 32-bits? Perhaps you can simply use 8-bit datapath + DMA to build these frames.

0 Likes
TePh_4811091
Level 1
Level 1
First question asked 5 sign-ins First reply posted

Thanks guys for taking the time to offer suggestions. My initial task is focused on data shifting into the PSoC. And as to the points made and my rapidly growing understanding of the PSoC world, I've come to the realization that I was making this more difficult than need be. So my current functional solution, though it feels somewhat like hack:  Control Registers  cross wired to Status Registers, in a fashion that re-arranges the bits as I need them. Hmmmm, now if I can utilize the DMA engine to move the bytes through my CR/SR and ultimately to my i2c slave buffer.  Another wild tangent to investigate...

0 Likes