Comments (14)
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.
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.
Related Issues (20)
- Hardcoded address width in bsg_cache_to_dram_ctrl HOT 1
- Should have comment explaining when to use scan here
- long term change
- Add comment that describes difference between this SIPO and others HOT 1
- Questions regarding getting to high frequency on bsg_link/bsg_comm_link HOT 4
- Document on how to add and simulate PLL to bsg_chip
- DT and RT getting stuck sometimes HOT 4
- Problem with testing on `bsg_dataflow` modules
- Undefined parameter used when instantiating bsg_mem_1rw_sync HOT 1
- Syntax errors in generated hard-macro-swapping verilog files when using Python3 HOT 2
- bsg_cache optimization -- don't replay TL instruction if there is no TL instruction HOT 4
- :bug: sync_len_lp is undeclared and undefined in config_snooper.v HOT 2
- bsg_comm_link_master_calib_skip_rom.v is broken HOT 1
- bsg_cache.v ready_o may be yumi_o HOT 2
- Add code for FPGA side of bsg_link HOT 2
- How can we use a basejump_stl component as a top-level module? HOT 9
- bsg_cache_to_test_dram does not support multiple outstanding reads per channel HOT 1
- bsg_nonsynth_dramsim3 failing testbench
- Broken cache testbenches HOT 5
- Release bsg_link FPGA implementation
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from basejump_stl.