multiplexing input sources for TSE MAC transmit interface

[Altera_Forum]

Hi 

 I have two transmitting modules while only one TSE MAC port. My intention is to multiplex the input to the MAC TX depending on some signal. Seems pretty straight forward but I am having issues.    My code for multiplexing is as follows..  assign mac_tx_data_1 = (owner == 1'b1) ? tx_data_0 : tx_data; assign mac_tx_valid_1 = (owner == 1'b1) ? tx_valid_0 : tx_valid; assign mac_tx_sof_1 = (owner == 1'b1) ? tx_sop_0 : tx_sof; assign mac_tx_eof_1 = (owner == 1'b1) ? tx_eop_0 : tx_eof; assign mac_rx_ready_1 = (owner == 1'b1) ? rx_ready_0 : rx_ready;   The error I got is  "Error: Cannot convert all sets of registers to RAM megafunctions when creating nodes. The resulting number of registers remaining in your design exceeds the number of registers in your device or the number specified by the assignment max_number_of_registers_from_uninferred_rams. This can cause longer compilation time or result in insufficient memory to complete Analysis and Synthesis."  My intention is to create MUX whereas tool is trying to create RAM and even not successful with that.   What can be the possible solutions..    thanks sawaak

[Altera_Forum]

If you are implementing the TSE inside a SOPC builder project there are some ready made Avalon Stream multiplexers that you can use. 

I'm not sure why you get this error message, but it's hard to think that it is linked to your code... The ready signal is supposed to go the other way round (from the TSE to the stream source) but I'm not sure it could generate this error either.

[Altera_Forum]

Hi Daixiwin, 

 Thanks for the reply..  I am not using SOPC builder, just plain HDL..  It is rx_ready and not tx_ready and therefore is supposed to go from the stream source to TSE    thanks sawaak

[Altera_Forum]

Oh yes I missed that... you still need to allow the tx_ready signal to only go to the selected source or you'll have problem if they both have a packet to send at the same time. The same thing goes for the valid signal on the RX side. 

Does the synthesis stop after the error? If not you could have a look at the RTL viewer to see what Quartus is trying to implement.

[Altera_Forum]

Hi, 

 I am also doing demux for the RX port and there is no error with that.  Doing something like this..  always@(posedge clk) begin  if(owner==1'b1)  begin  rx_data_0 = mac_rx_data_1;  .  .  .  tx_ready_0 = mac_tx_ready_1;   end  else  begin  rx_data = mac_rx_data_1;  .  .  .  tx_ready = mac_tx_ready_1;    end  end  Tried the same structure of always @(posedge clk) with TX but having same errors.   Synthesis stops after the error.    thanks sawaak

[Altera_Forum]

I think we should see all the code to find out why it is trying to generate RAM blocks. 

The mux you are trying to do will probably not work, as it will add a clock delay on the valid and ready signals in each direction. A transfer occurs when both signals are active at the same time, but in your case on every interface there will be two clock delays between those signals, and it will probably have unexpected results. You'll either have to add some buffering logic, or do a combinatorial multiplexer instead, with only the owner signal actually synchronized with the clock.

[Altera_Forum]

Unfortunately I am not able to share all the code. 

Yes, you are right, thanks for the info.  I even tried to use MUX explicitly using MegaFunction but still got the same error :(

[Altera_Forum]

This seems to show that the problem comes from another part of your design than the mux itself.

[Altera_Forum]

yup, indeed the problem was outside...mac_tx_clk_1 and mac_rx_clk_1 were not connected to one of the module.. 

 thanks for the info