Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Multiplexer output width depends on SELECT

Status
Not open for further replies.

rrucha

Member level 3
Joined
Jul 17, 2019
Messages
66
Helped
0
Reputation
0
Reaction score
0
Trophy points
6
Activity points
675
I am implementing a MUX which basically selects which width of input data to use. Based on that, the output width of my MUX will change.

Code:
input [width1-1:0] in1;
input [width2-1:0] in2;
input [width3-1:0] in3;
input [1:0] sel;

output [out_width-1:0] out;

SO basically, when I use a case statement to select from the inputs, I also assign what out_width would be. Is that correct? Is there any other way, that is less messy, to do it?

And also, this SELECT gets set in another module that deals with the data. So is it safe to say that if that module takes care of setting the SELECT based on the data width coming to my module, I do not need to do anything else with my Select signal other than just taking it as an input?
 
Last edited:

What you are doing is something that can't be done in hardware.
You can't have hardware that magically adds or deletes chips on a board to make buses that change widths on the fly.

You implement for the maximum width and only use the bits you want, instead of trying to change the hardware.

You have to stop thinking like this is software, it is hardware, i.e. like 374, 244, etc ICs installed on a board and wired up.
 

Hi,

I do have a single data bus. The size for it is fixed. But the data that comes on it changes in width. Basically its an unaligned data because of the additional information that is added to it. Is there no way to implement this in hardware?
 
Last edited:

Hi,

I do have a single data bus. The size for it is fixed. But the data that comes on it changes in width. Basically its an unaligned data because of the additional information that is added to it. Is there no way to implement this in hardware?

Not the way you seem to want to implement it as auto resizing hardware during operation.

If you mux the largest bus width and slice only the bits you need that can be done. e.g.

Code Verilog - [expand]
1
2
3
4
5
6
7
8
9
10
11
parameter width1 = 8;
parameter width2 = 16;
parameter width3 = 32
always @(posedge clk) begin
  out <= 0;
  case (sel)
    2'b 00 : out[0 +:width1] <= in1;
    2'b 01 : out[0 +:width2] <= in2;
    2'b 10 : out[0: +width3] <= in3;
  endcase
end


out is always out[31:0] but only the bits in the bit slices are assigned by the in1-3. The width of out doesn't change like you seem to want.

To look at the selected data out of the out[31:0] bus in the other module.

Code Verilog - [expand]
1
2
3
4
5
6
7
always @(posedge clk) begin
  case (sel)
    2'b 00 : in_slice1 <= out_data[0 +:width1];
    2'b 01 : in_slice2 <= out_data[0 +:width2];
    2'b 11 : in_slice3 <= out_data[0 +:width3];
  endcase
end

 

Hi,

Thank you so much for your reply. Its really helpful. I tried implementing it in such a way that I have two back to back MUXs basically. So the output of the first MUX is of fixed width and goes to a second MUX which uses the same select inputs to decide what the final output will be (by truncating a certain number of bits). Is that sort of what you have done as well?
 

Hi,

Thank you so much for your reply. Its really helpful. I tried implementing it in such a way that I have two back to back MUXs basically. So the output of the first MUX is of fixed width and goes to a second MUX which uses the same select inputs to decide what the final output will be (by truncating a certain number of bits). Is that sort of what you have done as well?
The second case I wrote above is not a mux I just use that type of syntax to improve the readability of the code instead of having a bunch of if statements

in_slice1 is not the same as the other two, each of those was for how I think you wanted to use that variable width output you wanted.

so muxing is

8-bit
16-bit
32-bit
2-bit select

with a 32-bit output that outputs for each select value
sel = 0 then out[7:0] = 8-bit
sel = 2 then out[31:0] = 32-bit

later when you need to use the "variable" out assignments in the next module you don't have to use sel to select the slice, you can just assign it

slice_8bit = out;

only the out[7:0] will get assigned and the other 24-bits are dropped, of course this results in a bunch of warnings in synthesis, which I don't like.


If you use the sel you can use that to select only the required bits to slice with nested ifs or the case I used.

Code Verilog - [expand]
1
2
3
if (sel == 0) slice_8bit = out[7:0];
else if (sel == 1) slice_16bit = out[15:0];
else if (sel == 2) slice_32bit = out;



- - - Updated - - -

I'm getting the distinct impression your issues aren't to do with writing code as much as lacking digital design experience. Think of it this way if you can't sit down and design the circuit you need using 7400 series parts then you will end up with problems trying to design it in Verilog as you are effectively describing that same 7400 design at a higher level of abstraction.
 

Hi,

It could be done. The major challenge is having to detect which channels of the input data bus that bear information. Selecting those channels and connecting them to the output is simple - just have a select counter and manipulate it accordingly.

- - - Updated - - -

Also realize that always placing the LSB of your variable-width data on channel 0 of the mux, LSB+1 on channel 1, and so on would simplify the operation of such select counter owing to the fact that you can reset the counter based on the number of channels detected to bear data.
 

Hi,

Thank you so much for your reply. Its really helpful. I tried implementing it in such a way that I have two back to back MUXs basically. So the output of the first MUX is of fixed width and goes to a second MUX which uses the same select inputs to decide what the final output will be (by truncating a certain number of bits). Is that sort of what you have done as well?

This is basically connecting the output channel of a mux to the input channel of a demux. It is not going to be of any use because it is the same number of imput channels to the mux that you would have as output channels on the demux.

I was thinking you just meant to multiplex input data of varying width placed on a fixed width multiplexer while ignoring the channels that bear no information and then transferring the now serial data for remote use or so.
 

This is basically connecting the output channel of a mux to the input channel of a demux. It is not going to be of any use because it is the same number of imput channels to the mux that you would have as output channels on the demux.

I was thinking you just meant to multiplex input data of varying width placed on a fixed width multiplexer while ignoring the channels that bear no information and then transferring the now serial data for remote use or so.

Hi,

I have several operations that I need to perform on the data. the different widths of input will come out of the 1st MUX based on the select input. We already discussed that this output channel will be of a fixed width (maximum width). Then I want to manipulate this data by appending a few bits to it. So I though if I have a sort of a demux that will use the same select input and will have different width output, then the task of slicing can be achieved. Am I going wrong somewhere?
 

A mux has a single bit output. You can synchronize the output with clock though.

- - - Updated - - -

If you just have a mux and then a demux, and you have a common select signal to the select inputs of both, then the bit into the channel0 of mux will exit at channel0 of demux, that at channel1 of mux will exit at channel1 of demux, and so on.

- - - Updated - - -

You could just make a behavioral description of what you want instead of a structural connection of mux and demux. That's just my thoughts though.
 

A mux has a single bit output. You can synchronize the output with clock though.

- - - Updated - - -

If you just have a mux and then a demux, and you have a common select signal to the select inputs of both, then the bit into the channel0 of mux will exit at channel0 of demux, that at channel1 of mux will exit at channel1 of demux, and so on.

- - - Updated - - -

You could just make a behavioral description of what you want instead of a structural connection of mux and demux. That's just my thoughts though.

Hi!
I will explain what I have done. I tested it and it works fine; I just want to know if there is a better way to do it.
My data bus is fixed; as i said. So my data comes in on a bus. I used case statement to determine what widths of data to chop and use. But again, the output needs to be a fixed width. so I end up with the desired output data with appended 0's on the excess width of the bus.
This I then send to another module (sort of like a DEMUX) along with the select signals. What I need to do in this module is add some extra information to my input data. So using the select input, I chop the data to desired width (basically remove the extra 0's that we got on the big bus) and append the desired data and send it out on a variable number of outputs. Basically implementing a DEMUX.

Everything works as expected. But is there any other way to do this?
 

So the data coming in on the bus has bits that are either '1', '0' or 'Z'?

- - - Updated - - -

I'm much concerned about 'Z'.
 
Last edited:

Hi!
I will explain what I have done. I tested it and it works fine; I just want to know if there is a better way to do it.
My data bus is fixed; as i said. So my data comes in on a bus. I used case statement to determine what widths of data to chop and use. But again, the output needs to be a fixed width. so I end up with the desired output data with appended 0's on the excess width of the bus.
This I then send to another module (sort of like a DEMUX) along with the select signals. What I need to do in this module is add some extra information to my input data. So using the select input, I chop the data to desired width (basically remove the extra 0's that we got on the big bus) and append the desired data and send it out on a variable number of outputs. Basically implementing a DEMUX.

Everything works as expected. But is there any other way to do this?

This sounds like this question is related to your other question. https://www.edaboard.com/showthread.php?386638-parameterized-insertion-of-bits-to-data. Forum rules forbid this. Next time ask all related questions on the same topic in a single thread.

What you've described is exactly the way it should be done. A for loop will only make it harder to maintain the code as you are trying to be "clever".
 

This sounds like this question is related to your other question. https://www.edaboard.com/showthread.php?386638-parameterized-insertion-of-bits-to-data. Forum rules forbid this. Next time ask all related questions on the same topic in a single thread.

What you've described is exactly the way it should be done. A for loop will only make it harder to maintain the code as you are trying to be "clever".

Hi,

the two are related but they are not the same issue. One issue is about connecting the modules and another is about whats going on inside the module.
But if you say what I mentioned above about the MUX and DEMUX is correct, then I wont try any harder to come up with a better implementation.

Thanks

- - - Updated - - -

So the data coming in on the bus has bits that are either '1', '0' or 'Z'?

- - - Updated - - -

I'm much concerned about 'Z'.

No, its all about data widths. Nothing is Z.
As we know, if the bus is wider than required, the data only gets appended with 0's.

Say we have a 16 bit bus, and the widths we need are 4, 8 and 16.
what my circuit will do is, when 4 bit width is chosen, it will select the first 4 bits of data coming on the 16 bit bus and give it to the output; meaning the remaining bits are 0.
 

Okay, so it's just parallel data comong in and not necessarily a bus.

Doing this operation using a mux and then a demux to me is time consuming. I believe the operation can be accomplished with even shorter time.

- - - Updated - - -

If your aim is to minimize the time it takes to complete the operation, then I believe I can propose a solution for you.
 

Okay, so it's just parallel data comong in and not necessarily a bus.

Doing this operation using a mux and then a demux to me is time consuming. I believe the operation can be accomplished with even shorter time.

- - - Updated - - -

If your aim is to minimize the time it takes to complete the operation, then I believe I can propose a solution for you.

Hi! Yes, any better solution works.
I even implemented the operation in one module. Dont know how that will look in hardware though.
 
Last edited:

Very well then, consider this.
Feed each data line into one input of a two input mux. The second input of each mux on a data line that does not bear a data bit at the time would be fed an 'append bit'. You could select which input of each mux is routed to its output based on the width of the input data that you have on the data lines. Any data line that does not bear a data bit should have its select bit set such that the 'append bit' is routed to its mux output. Every data line bearing a data bit should have its select bit set so that the data bit is routed to its output.

So how do you route the 'append data' bits to the right mux input in every occasion? You could implement a circuit that takes in a code signal at its select input to route your 'append data' bits like this:
Using your 16-bit maximum data width example, let the code signal for a16-bit data be 0, 1 for 8-bit data, 2 for 4 bit data. When the code signal on its select input is 0, it will not care about the 'append data'. When it is 1, it will route the 'append data' bits beginning with mux8 through mux15. When it is 2, it will route the 'append data' bits beginning with mux4 through mux15.

You could just take this basic idea and improve on it.
 
Last edited:

So all the operations are parallel and may even take one clock cycle to append the extra data.

If any part of my post is not clear, feel free to ask for an explanation.
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top