Split register in smaller segments

Hi,

I'm working on a little UART to get more familiar with verilog, and right now I have the following input:

parameter width = 32; /* Must be multiple of 8 */ input [width - 1: 0] iData;

/* number of characters to send for each piece of data - 1 */ parameter chars = width / 8 - 1;

The iData first goes in a fifo for buffering and is then read back in as oData:

wire [width - 1: 0] oData;

Since this is an UART I want to send (always, regardless of width) 8 bits at a time, so I wrote down:

reg [7: 0] xData [chars: 0];

And then try to assign oData to this:

xData

uh, which answer? oData[8*i+7:8*i] is illegal because it's a part select with variable bounds; in Verilog all expressions must have a statically-determined bit width, and although you and I can do the algebra and see that the slice is evidently 8 bits wide, it's safer for the language to outlaw that sort of thing. The indexed part-select oData[8*i+:8] is legal, at least in Verilog-2001, but creates a big multiplexer to choose the bits - hence my comment later about using a shifter instead.

Don't take my word for it - try synthesising both versions and see what the tool shows you. For a word of only 2 or 4 bytes the difference is likely to be marginal.

--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

I figured it was something like that. But since it'd translate to hardware at some point I hoped the compiler was intelligent enough to understand this "re-definition".

Ok.. but why is this a wrong answer?

That all makes sense. I think I can pull this off without changing too much. I was already doing something similar for transmitting the actual bits anyway. :)

It would simplify the UART somewhat, but then I'd have to shift a number of bytes into the fifo in one clock cycle. I'll stick to what I have for now.

Odd. I thought a wire from the original register would be cheaper than logic to get the bits in place.

Thanks,

Michael

ummm, sorry, I wasn't being sufficiently precise. The 'for' loop, with indexed part select, is completely legal Verilog; it will simulate just fine, and as you say it will be unrolled in synthesis because the loop has static bounds. I still say that the logic will be bigger than the shift solution, though, at least if you assume (a) it's an FPGA target, and (b) the word is >=4 bytes. The reason is that a 4:1 or wider multiplexer won't fit into a single lookup table (LUT) in typical FPGAs (there are some exceptions) whereas the 2:1 mux required to implement a conditional shift most certainly will. Since each bit of storage in an FPGA comes with a free LUT, the shifter solution is almost free - the necessary logic comes along for the ride with the registers that you need in any case - but the mux solution is likely to use a few extra LUTs whose registers would be wasted. The argument in favour of shifting over selecting is likely to get stronger as the word gets wider, up to some limit where the shift register becomes implausibly wide and then you switch over to using a full-dress memory block instead - and, of course, accept that you can access only one element of it at a time.

In truth, I'm probably nit-picking. Do whatever works and gives you clean, maintainable code. I just wanted to flag up the possibility of an alternative approach.

--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

I meant the for loop. If the compiler unrolls it I don't see how this could be a wrong. Maybe size.

I'll give it a try soon. The solution of using a shift turned out to be

1 extra line and about 4 minor changes, so I'm currently working out the bugs which showed up in the simulation. :)

Thanks again,

Michael