cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
chris0622
Contributor
Contributor
386 Views
Registered: ‎09-22-2019

Shift hundreds of bits in one clock

Jump to solution

Hi ,

I'm doing RTL code for some functions, and then I encountered a problem.
Does anybody know if it will happen timing violation if I shift 500 bits  to a register in one clock .
If yes, what is the limit of bits that I can shift in one clock.

EX:

 test.PNG

Thank you!

 

 

0 Kudos
1 Solution

Accepted Solutions
avrumw
Expert
Expert
251 Views
Registered: ‎01-23-2009

if I code like this below , it wouldn't  produce congestion or timing violation. right?

This is much more complicated. Now you are no longer talking about a fixed shift value - you are talking about a variable shift amount. Assuming bitsLeft can any value between 0 and (presumably) 128, then this is a MUX of 128 different shifters. Thus each bit of (data_in >> x) where x is between 0 and 128 is the output of this MUX. Effectively, this means that bit 0 of the output is a 128:1 MUX, bit 1 is a 127:1 MUX (the remaining value is 0), bit 2 is a 126:1 MUX, etc... This is a HUGE combinatorial network. This then gets coupled with your fixed shift and OR (which is relatively inexpensive).

Is this going to cause "congestion" - I can't tell. It is definitely going to be a candidate for congestion - some of the bits of data_in fan out to as many as 128 different MUXes - that's a lot of fanout and a lot of logic funneling down to your output. In other words, that's a lot of nets. Is this enough to cause congestion? Maybe - only by synthesizing and implementing it can you tell.

The same is true for timing. This infers a lot of combinatorial logic between flip-flops (I presume both data_in and bitsLeft come from flip-flops). Depending on the clock speed you are targeting this certainly can be a critical timing path.

This is a good example of the skills required for design. A single line of code can result in relatively little and relatively fast logic (like a fixed shift) or a huge mass of potentially slow combinatorial logic (like the variable shift). One of the most important skills in designing is being able to visualize (at least roughly) what the resulting logic will look like as you write code. This will help you decide the feasibility of a particular micro architecture (where to put flip-flops, how to organize things, etc...), and help you converge on implementable solutions faster.

Avrum

View solution in original post

4 Replies
dpaul24
Scholar
Scholar
357 Views
Registered: ‎08-07-2014

@chris0622 ,

Does anybody know if it will happen timing violation if I shift 500 bits to a register in one clock .

Well technically it is not possible to shift 500 bits in to 1 register in clock cycle. You need 500 clocks to shift in 500 bits.

Do you want to rephrase the question?

Do you mean shifting in 500 bits to 500 registers?

Well there are various pipelined bus protocols in which the bus width is 512 and they are shifting in and out all those bits in 1 clock cycle.

------------------------------------------------------------------------------------

Update: Please never duplicate posts in the future.

https://forums.xilinx.com/t5/Design-Entry/shift-hundreds-of-bits-in-one-clock/td-p/1266916

 

------------FPGA enthusiast------------
Consider giving "Kudos" if you like my answer. Please mark my post "Accept as solution" if my answer has solved your problem
Asking for solutions to problems via PM will be ignored.

0 Kudos
avrumw
Expert
Expert
303 Views
Registered: ‎01-23-2009

There is no problem with this. A fixed "shift" operator actually infers no logic - it merely renames the bits of a vector - if you have

wire [15:0] a; 
wire [7:0] b;

assign b = a[15:8];

This infers no logic - merely creates a second RTL name for a[15:8].

The code is identical to 

assign b = a >> 8;

You are still merely giving another name to bits a[15:8].

In your case, you are doing your >> operator in an if statement and inside an always @(posedge clk). The shift operator still infers no logic - it merely takes bits [511:500] (and prepends 500 0's). The 'if' infers a MUX (or CE) between the original 512 bit vector and the new vector (the result of the >> ), and the fact that it is in a clocked process assigns the value to a flip-flop.

So while the >> operator is called a "shift operator" it is not a serial bit shifter (which can only shift right or left one bit at a time) - it is an operator that takes two operands and generates an output (just like the + operator or, in fact, all the other Verilog operators). The sizing rules for the >> are a bit complicated (the size of the right hand expression has no effect on the size of the operation), but other than that it is just an operator.

Avrum

chris0622
Contributor
Contributor
265 Views
Registered: ‎09-22-2019

Hi, 

First, thank you for your reply. I benefited a lot !

The last question. if I code like this below , it wouldn't  produce congestion or timing violation. right?

擷取2.PNG

0 Kudos
avrumw
Expert
Expert
252 Views
Registered: ‎01-23-2009

if I code like this below , it wouldn't  produce congestion or timing violation. right?

This is much more complicated. Now you are no longer talking about a fixed shift value - you are talking about a variable shift amount. Assuming bitsLeft can any value between 0 and (presumably) 128, then this is a MUX of 128 different shifters. Thus each bit of (data_in >> x) where x is between 0 and 128 is the output of this MUX. Effectively, this means that bit 0 of the output is a 128:1 MUX, bit 1 is a 127:1 MUX (the remaining value is 0), bit 2 is a 126:1 MUX, etc... This is a HUGE combinatorial network. This then gets coupled with your fixed shift and OR (which is relatively inexpensive).

Is this going to cause "congestion" - I can't tell. It is definitely going to be a candidate for congestion - some of the bits of data_in fan out to as many as 128 different MUXes - that's a lot of fanout and a lot of logic funneling down to your output. In other words, that's a lot of nets. Is this enough to cause congestion? Maybe - only by synthesizing and implementing it can you tell.

The same is true for timing. This infers a lot of combinatorial logic between flip-flops (I presume both data_in and bitsLeft come from flip-flops). Depending on the clock speed you are targeting this certainly can be a critical timing path.

This is a good example of the skills required for design. A single line of code can result in relatively little and relatively fast logic (like a fixed shift) or a huge mass of potentially slow combinatorial logic (like the variable shift). One of the most important skills in designing is being able to visualize (at least roughly) what the resulting logic will look like as you write code. This will help you decide the feasibility of a particular micro architecture (where to put flip-flops, how to organize things, etc...), and help you converge on implementable solutions faster.

Avrum

View solution in original post