+ Post New Thread
Results 1 to 4 of 4
  1. #1
    Member level 3
    Points: 322, Level: 3

    Join Date
    Jul 2019
    Posts
    66
    Helped
    0 / 0
    Points
    322
    Level
    3

    Hardware implementation of problem

    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?
    Click image for larger version. 

Name:	qq.PNG 
Views:	4 
Size:	16.5 KB 
ID:	156060

    - - - 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 ads-ee; 15th October 2019 at 17:58. Reason: fixed missing end tag

    •   AltAdvertisement

        
       

  2. #2
    Super Moderator
    Points: 31,842, Level: 43
    ads-ee's Avatar
    Join Date
    Sep 2013
    Location
    USA
    Posts
    7,369
    Helped
    1728 / 1728
    Points
    31,842
    Level
    43

    Re: Hardware implementation of problem

    Quote Originally Posted by rrucha View Post
    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.



    •   AltAdvertisement

        
       

  3. #3
    Member level 3
    Points: 322, Level: 3

    Join Date
    Jul 2019
    Posts
    66
    Helped
    0 / 0
    Points
    322
    Level
    3

    Re: Hardware implementation of problem

    Quote Originally Posted by ads-ee View Post
    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.



    •   AltAdvertisement

        
       

  4. #4
    Super Moderator
    Points: 31,842, Level: 43
    ads-ee's Avatar
    Join Date
    Sep 2013
    Location
    USA
    Posts
    7,369
    Helped
    1728 / 1728
    Points
    31,842
    Level
    43

    Re: Hardware implementation of problem

    Quote Originally Posted by rrucha View Post
    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.



--[[ ]]--