Convert wormhole router to bsg_noc_links about basejump_stl HOT 14 CLOSED

Thanks for the great suggestion Dan!

The reason why I did not use "ready_and_link" is that the initial purpose of designing wormhole router was for inter-ASIC network. Currently all related bsg modules (like channel tunnel, comm-link, fsb...) have standard 3-ports interface (valid ready data). Also the FPGA ip cores (like Xilinx AXI-4 Stream interface) also have standard 3-ports ready-valid interface. If we change router to 1-port, the outside network will become more complicated. (Actually the outside network has been partially designed, would need rework if changed to ready_and_link)

Do you think it's a good idea to add a new module "bsg_wormhole_router_link_wrapped", which converts the 3-port interface to 1-port link? Also we may use "my_x_i / my_y_i" to match the mesh_router naming convention.

Note that we also need to rework on wormhole_adapter_in and wormhole_adapter_out (designed by Tommy), and all wires connected to these two adapters.

Thoughts?

from basejump_stl.

Correct me if I'm wrong, but it will always be a wormhole_adapter_in or wormhole_adapter_out which connects to channel tunnel, comm-link, fsb, right? If so, we would only need to change the router to have the noc_links and then the adapters would have the noc_link on the router side and ready-valid on the other side

from basejump_stl.

The functionality of wormhole_adapter_in and wormhole_adapter_out is serial-in-parallel-out and parallel-in-serial-out. For the outside network, we are transmitting and decoding wormhole packets directly without converting it back to parallel format, so wormhole router is exposed to channel_tunnel, comm-link without adapter.

In my opinion, adapter-in and adapter-out is a temporary solution. Ideally CCE may decode and process wormhole packet directly...

from basejump_stl.

Oh, I see. Yeah, the wrapper seems like a good solution then. I think I have a preference for the bsg_wormhole_router to be ready_and_link and the wrapper to convert from ready_and_link to ready-valid. The common case is on-chip routing, and then all of our routers have exactly the same interface

from basejump_stl.

In my opinion, adapter-in and adapter-out is a temporary solution. Ideally CCE may decode and process wormhole packet directly...

Yes, definitely! We'll still need adapter-ins and outs on the very edges of the network, but the CCE shouldn't have either ideally.

from basejump_stl.

Oh, I see. Yeah, the wrapper seems like a good solution then. I think I have a preference for the bsg_wormhole_router to be ready_and_link and the wrapper to convert from ready_and_link to ready-valid. The common case is on-chip routing, and then all of our routers have exactly the same interface

This is also a great idea. If we modify in this way, all routers / adapters in bp_tile and outside bp_tile need to be updated in parallel, otherwise it will not pass the test.

If we build up a wrapper to convert to 1-port link, we may update them one-by-one (original ones still work).

Which way do you prefer?

from basejump_stl.

Personally, I prefer to add a wrapper to current wormhole router without touching the router itself. Indeed, the 3-port interface might be the real standard interface (in bsg and in industry), the 1-port link was only used on Manycore... We may not need to make all routers have same interface, because mesh-router and wormhole-router cannot connect to each other :)

from basejump_stl.

This is also a great idea. If we modify in this way, all routers / adapters in bp_tile and outside bp_tile need to be updated in parallel, otherwise it will not pass the test.

If we build up a wrapper to convert to 1-port link, we may update them one-by-one (original ones still work).

I'm fine with updating bp_tile in parallel. We can hold off bumping the submodule in BlackParrot until the changes are made in both, so there should be no problem

Personally, I prefer to add a wrapper to current wormhole router without touching the router itself. Indeed, the 3-port interface might be the real standard interface (in bsg and in industry), the 1-port link was only used on Manycore... We may not need to make all routers have same interface, because mesh-router and wormhole-router cannot connect to each other :)

That's totally fair. What's nice to me about having the same interface is that you can reuse things like bsg_mesh_stitch.v and bsg_mesh_to_ring_stitch.py. I think having the wrapper to communicate to the "real standard interface" is fine, since there's no hardware overhead (really it's just renaming wires)

from basejump_stl.

Thanks Dan! I will push the changes of wormhole router soon, after that we may look into the adapters.

from basejump_stl.

Great, thanks Paul!

(Thinking out loud)
There's also another alternative to a wrapper that's more general. We could use an adapter which converts links to ready-valid. We could use this as glue logic for both mesh_routers and wormhole_routers.

@proftaylor ?

module bsg_noc_link_to_ready_valid_adapter
(input clk_i
 , input reset_i

 , input  [dirs_lp-1:0][bsg_ready_and_link_sif_width_lp-1:0] link_io
 , output [dirs_lp-1:0][bsg_ready_and_link_sif_width_lp-1:0] link_oi

 , input [dirs_lp-1:0] valid_io 
 , input [dirs_lp-1:0][width_p-1:0] data_io
 , output [dirs_lp-1:0] ready_oi 

 , output [dirs_lp-1:0] valid_oi
 , output [dirs_lp-1:0][width_p-1:0] data_oi
 , input [dirs_lp-1:0] ready_io 

from basejump_stl.

Modification done! 9a459e2

from basejump_stl.

@dpetrisko I was rather proud of the _sif (sounds like Sith). There were a few iterations, each more awesome than the last, starting with raw, then greendroid, and then the manycore version attaining the tenth level (directions part of the array).

looks like you guys are converging.

If we find ourselves replicating Paul's add-in a lot then make sense to factor it. In the interface you gave Dan, I would specify it as link_i, link_o, v_A_i, data_A_i, ready_A_o; v_B_i, data_B_i, ready_B_o. This way you can easily eyeball that the A's are hooked up in one place of the parent module; and the B's in another place in the parent. I think I also started with io, oi, etc, and it's really hard to remember if you have it right.

Another question is whether you want to bundle the different networks together like we did in manycore (only two networks, in this case):

https://github.com/bespoke-silicon-group/bsg_manycore/blob/master/v/bsg_manycore_packet.vh

M

from basejump_stl.

Makes sense! Sounds like wrapper is the way to go short term and adapter depending on how we end up using it.

I think I also started with io, oi, etc, and it's really hard to remember if you have it right.

Yep, that's what inspired it :)

from basejump_stl.

Resolved by changing wormhole routers to use sif_links

from basejump_stl.