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.

Hardware implementation of problem

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
Hi I wanted to know how I will represent this code in hardware. I will explain it with a picture.
I have 8 different inputs to select from. In one clock, I will either choose 4 chunks of it or 2 chunks of it.
I implemented the harware to pick the first 4 inputs and then to pick 2 inputs out of this. I want to know how I will represent the picking mechanism between either 4 inputs of two inputs.

The code will just be
Code:
case (input_sel)
0: begin
dout1 = 1;
dout2 = 2;
dout3 = 3;
dout4 = 4;
end 

1: begin 
dout1 = 2_1;
dout2 = 2_2;
end 
endcase

How is this shown in hardware? In code, we will just tap the respective output points.
Also, is there a better way to pick the chunks of inputs than what I have done with the 6 MUXs?
qq.PNG

- - - Updated - - -

I wanted to add; Can I make use of the configurable MUX here? Where the select will either choose 4 inputs of 2 inputs in a clock?
 
Last edited by a moderator:

I wanted to add; Can I make use of the configurable MUX here? Where the select will either choose 4 inputs of 2 inputs in a clock?
I don't understand why you can't get past the idea that everything has to be a configuration at compile time. You don't have to have the size of anything change on the fly.

The responsibility of what data is looked at should be the responsibility of the device getting the data. The sending device, this mux structure, always has 4 inputs routed out, it's only a mater of which of the four inputs actually has valid data at any given time and informs the receiving end which data is valid on that clock cycle.

e.g. some bus protocols (don't recall which ones) have a signal sent along with the data that tells a destination device how many bytes are valid in the multi-byte output. The output is always aligned to one end of the bus or the other.
 

I don't understand why you can't get past the idea that everything has to be a configuration at compile time. You don't have to have the size of anything change on the fly.

The responsibility of what data is looked at should be the responsibility of the device getting the data. The sending device, this mux structure, always has 4 inputs routed out, it's only a mater of which of the four inputs actually has valid data at any given time and informs the receiving end which data is valid on that clock cycle.

e.g. some bus protocols (don't recall which ones) have a signal sent along with the data that tells a destination device how many bytes are valid in the multi-byte output. The output is always aligned to one end of the bus or the other.

Hi! Thank you for your quick reply. Understood; nothing will be configurable.
The 4 outputs ( when 4 is selected instead of 2) are going to 4 different CRC engines in parallel so I can get their CRCs in the same clock. In case of of 2 chunks of MD; say MD1 and MD4; only these two need to be sent to the first 2 CRC engines and no data will go to the lower two CRC engines. How can I implemnet this in hardware? Even with a MUX, I dont understand how I will route either 4 of 2 MDs.
 

Hi! Thank you for your quick reply. Understood; nothing will be configurable.
The 4 outputs ( when 4 is selected instead of 2) are going to 4 different CRC engines in parallel so I can get their CRCs in the same clock. In case of of 2 chunks of MD; say MD1 and MD4; only these two need to be sent to the first 2 CRC engines and no data will go to the lower two CRC engines. How can I implemnet this in hardware? Even with a MUX, I dont understand how I will route either 4 of 2 MDs.
I don't understand the problem you are having with this code, it is just simple steering logic to put either 4 or 2 CRCs on the bus in whatever position makes sense for the downstream logic to use.


Code Verilog - [expand]
1
2
3
4
5
always @(posedge clk)
  if (steer4)
    out_bus <= {a, b, c, d};  // four crcs go out
  else if (steer2)
    out_bus <= {e, f};    // data is right justified in out_bus and zero fills bits above input e}



You can code it with if statements like the example above or a case statement if you prefer. You just have to figure out what selects whether or not you are steering 4 or 2 of the inputs and what combination of inputs are going where. If you have a lot of different combinations of inputs that can go out then you'll just have more cases to deal with.

I get the feeling you are making ad hoc decisions on how to control the routing of the data through the CRCs and the output logic with little thought to the overall architecture and how you should be looking at how to route the data. i.e. like a table of how inputs get assigned to CRCs and how the outputs are arranged, then creating an index in that table to determine what the routings are for each stage of the design.
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top