Frequently Asked Questions
- Where can I get more information on the Verilog interface exposed by the networks generated through CONNECT?
The Verilog interface and other CONNECT technical details are described in the README file that accompanies every generated network. In addition to the README file every generated network also comes with a minimal bare bones testbench to get you started.
- Is there a command-line version of CONNECT?
Yes, to get access to a command-line tool for generating CONNECT networks, please send a request with your contact information and project description to
- How long does it take to generate a network?
Network generation times vary depending on network complexity and server load and can range from a few minutes to several hours. Network complexity is affected by the: i) number of routers in a network and/or ii) the radix and specific configuration of individual routers in the network. For VC-based networks, the number of Virtual Channels can also significantly affect network generation time. As a point of reference, when our servers are not overloaded, a 4x4 mesh with 2 Virtual Channels should take between 5 and 20 minutes to finish. Note that enabling debug symbols also has a severe impact on network generation time (please also see the next question).
- Why do my jobs take much longer to finish or never finish at all when I enable debug symbols?
Enabling debug symbols has a severe impact on network generation times and might even cause jobs to get preempted if server load is high. When enabling debug symbols, please constrain your designs to smaller networks.
- I submitted a network generation request, but never received any emails. What happened?
Each network generation request generates two emails. One email that confirms the request and should arrive withing a few minutes and a second email that contains the generated network. If you did not receive the first confirmation email, please check your SPAM folder. If the confirmation email is not there, then it is likely that your mail server is blocking CONNECT emails, in which case you should try submitting your request using a different email address (gmail and yahoo email addresses have been confirmed to work).
- I received a confirmation email, but I never received the resulting network. What happened?
There is a chance that your mail server is blocking the CONNECT emails that include the tarball (.tar.gz) attachment with the resulting network. Please try using a different email address (gmail and yahoo email addresses have been confirmed to work).
- Do some types of routers make more efficient use of FPGA resources?
Yes, the Virtual Channel (VC) and Virtual Output Queued (VOQ) routers were designed to map efficiently to the FPGA substrate. The Input Queued (IQ) router option was added later as a baseline design, which should also be FPGA-friendly, but does not use FPGA resources as efficiently as the VC and VOQ routers, which were more carefully engineered specifically for FPGA use.
- I ran synthesis and noticed that resource usage sometimes increases abruptly as I change network/router parameters. How is this explained?
This is an artifact of quantization effects in the FPGA substrate. For instance, going from a 4x4 to a 5x5 router can cause an abrupt jump in resource usage, because FPGA constructs (e.g. multiplexers or LUTRAM) often exhibit abrupt behavior -- with respect to resource usage -- as they scale (e.g. a 35-entry and 60-entry LUTRAM memory will occupy the same number of LUTs in a Virtex-6 FPGA device). Note that different FPGA families and devices might have different network/router configuration sweet spots.
- I noticed that in the generated Verilog the top-level network module (mkNetwork), always instantiates the same router module (mkRouter) even though my network contains routers that have different numbers of input/output ports. Why is that?
To reduce the processing time of network generation requests and load on our servers, when creating the RTL for a network, our backend generates Verilog for a single router module and then replicates this router module to build the requested network (this is handled like this to deal with long generation times, especially in the case of custom networks). For example, a generated mesh network is composed using 5x5 routers, even though the corner and side routers do not actually use all input/output ports. This might lead to slightly sub-optimal designs for networks that contain routers with different configurations, but synthesis tools are typically good at pruning any unnecessary logic.
- How should I decide which pipeline options to enable?
In most cases enabling either the core or allocator pipeline option can already provide 90% of the clock period improvements achievable through pipelining (but see next question for potential issues when enabling multiple pipeline options). As a rule of thumb, typical designs (3-6 ports/router, 2-3 VCs) will benefit the most from enabling the core pipeline option, while designs with a higher number of ports/router and VCs might benefit more from the allocator pipeline option. Pipelining the network links is useful when routers are placed far apart and thus only provides minimal clock frequency improvements for typical designs.
- I enabled multiple pipeline options and I'm getting assertion errors and/or my NoC does not work properly. What happened?
Some network configuration instances do not support pipelining both the router core and allocator. Since this can also depend on the type of traffic pushed through the network, for full flexibility the web interface does not currently prevent such designs from being generated (but it will show a warning to caution the user). As a result if you have enabled multiple pipeline options and you notice erratic network behavior or assertion errors during your simulation, try disabling one of your pipeline options (router or core).