Frequently Asked Questions
- Where can I get more information on the Verilog interface exposed by the networks generated by 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.
- 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.
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.