|
| 1 | +.. _server_mode: |
| 2 | + |
| 3 | +Server Mode |
| 4 | +================ |
| 5 | + |
| 6 | +If VPR is in server mode, it listens on a socket for commands from a client. Currently, this is used to enable interactive timing analysis and visualization of timing paths in the VPR UI under the control of a separate client. |
| 7 | +VPR provides the ability to run in server mode using the following command-line arguments. |
| 8 | + |
| 9 | +.. code-block:: none |
| 10 | +
|
| 11 | + --server --port_num 60555 |
| 12 | +
|
| 13 | +Server mode may only accept a single client application connection and respond to two types of requests: **get critical path report** and **highlight selected critical path elements**. |
| 14 | + |
| 15 | +Communication telegram |
| 16 | +------------------------- |
| 17 | + |
| 18 | +Telegram consists of two parts: a fixed-size **telegram header** and a variable-size **telegram body**. |
| 19 | +The telegram header contains helper information required to properly extract the telegram body sequence from the data flow. |
| 20 | + |
| 21 | +.. _fig_comm_telegram_structure: |
| 22 | + |
| 23 | +.. figure:: comm_telegram_structure.* |
| 24 | + |
| 25 | + Communication telegram structure. |
| 26 | + |
| 27 | +.. note:: The telegram body itself could be compressed with zlib to minimize the amount of data transferred over the socket. |
| 28 | + This compression is applied to the response of the 'get critical path report' request. The compressor ID byte in the telegram header signals whether the telegram body is compressed. |
| 29 | + When the compressor ID is null, the telegram body is not compressed. If the compressor ID is 'z', it means the body is compressed with zlib. |
| 30 | + |
| 31 | +.. note:: The checksum field contains the telegram body checksum. This checksum is used to validate the consistency of the telegram body during the dispatching phase. |
| 32 | + If checksums are mismatched, the telegram is considered invalid and is skipped in processing. |
| 33 | + |
| 34 | + |
| 35 | +.. _fig_comm_telegram_body_structure: |
| 36 | + |
| 37 | +.. figure:: comm_telegram_body_structure.* |
| 38 | + |
| 39 | + Communication telegram body structure. |
| 40 | + |
| 41 | + **telegram body** is a flat **JSON** structure. |
| 42 | + |
| 43 | + **CMD** could have following integer values: |
| 44 | + |
| 45 | + - 0 - command id for **get critical path** |
| 46 | + - 1 - command id for **highlight selected path elements** |
| 47 | + |
| 48 | + JOB_ID is a unique ID for a task. It is used to associate the request with the response by matching the same JOB_ID. Each new client request should increment the JOB_ID value; otherwise, it will not be clear which request the current response belongs to. |
| 49 | + |
| 50 | + |
| 51 | +Get critical path timing report example |
| 52 | +--------------------------------------- |
| 53 | + |
| 54 | + Let's take a look at an example of a request timing report telegram body with the following options: |
| 55 | + |
| 56 | + - path_num = 1 |
| 57 | + - path_type = "setup" |
| 58 | + - details_level = "netlist" |
| 59 | + - is_flat_routing = false |
| 60 | + |
| 61 | + .. code-block:: json |
| 62 | + :caption: telegram body **REQUEST** example |
| 63 | + :linenos: |
| 64 | +
|
| 65 | + { |
| 66 | + "JOB_ID": "1", |
| 67 | + "CMD": "0", |
| 68 | + "OPTIONS": "int:path_num:1;string:path_type:setup;string:details_level:netlist;bool:is_flat_routing:0" |
| 69 | + } |
| 70 | +
|
| 71 | + **path_type** could have following string values: |
| 72 | + |
| 73 | + - "setup" |
| 74 | + - "hold" |
| 75 | + |
| 76 | + **details_level** could have following string values: |
| 77 | + |
| 78 | + - "netlist" |
| 79 | + - "aggregated" |
| 80 | + - "detailed" |
| 81 | + - "debug" |
| 82 | + |
| 83 | + Response will look like: |
| 84 | + |
| 85 | + .. code-block:: json |
| 86 | + :caption: telegram body **RESPONSE** example |
| 87 | + :linenos: |
| 88 | +
|
| 89 | + { |
| 90 | + "JOB_ID": "1", |
| 91 | + "CMD": "0", |
| 92 | + "OPTIONS": "int:path_num:1;string:path_type:setup;string:details_level:netlist;bool:is_flat_routing:0", |
| 93 | + "DATA": " |
| 94 | + #Timing report of worst 1 path(s) |
| 95 | + # Unit scale: 1e-09 seconds |
| 96 | + # Output precision: 3 |
| 97 | +
|
| 98 | + #Path 1 |
| 99 | + Startpoint: count[1].Q[0] (dffsre clocked by clk) |
| 100 | + Endpoint : count[13].D[0] (dffsre clocked by clk) |
| 101 | + Path Type : setup |
| 102 | +
|
| 103 | + Point Incr Path |
| 104 | + ------------------------------------------------------------------------------------------ |
| 105 | + clock clk (rise edge) 0.000 0.000 |
| 106 | + clock source latency 0.000 0.000 |
| 107 | + clk.inpad[0] (.input) 0.000 0.000 |
| 108 | + count[1].C[0] (dffsre) 0.715 0.715 |
| 109 | + count[1].Q[0] (dffsre) [clock-to-output] 0.286 1.001 |
| 110 | + count_adder_carry_p_cout[2].p[0] (adder_carry) 0.573 1.574 |
| 111 | + count_adder_carry_p_cout[2].cout[0] (adder_carry) 0.068 1.642 |
| 112 | + count_adder_carry_p_cout[3].cin[0] (adder_carry) 0.043 1.685 |
| 113 | + count_adder_carry_p_cout[3].cout[0] (adder_carry) 0.070 1.755 |
| 114 | + count_adder_carry_p_cout[4].cin[0] (adder_carry) 0.053 1.808 |
| 115 | + count_adder_carry_p_cout[4].cout[0] (adder_carry) 0.070 1.877 |
| 116 | + count_adder_carry_p_cout[5].cin[0] (adder_carry) 0.043 1.921 |
| 117 | + count_adder_carry_p_cout[5].cout[0] (adder_carry) 0.070 1.990 |
| 118 | + count_adder_carry_p_cout[6].cin[0] (adder_carry) 0.053 2.043 |
| 119 | + count_adder_carry_p_cout[6].cout[0] (adder_carry) 0.070 2.113 |
| 120 | + count_adder_carry_p_cout[7].cin[0] (adder_carry) 0.043 2.156 |
| 121 | + count_adder_carry_p_cout[7].cout[0] (adder_carry) 0.070 2.226 |
| 122 | + count_adder_carry_p_cout[8].cin[0] (adder_carry) 0.053 2.279 |
| 123 | + count_adder_carry_p_cout[8].cout[0] (adder_carry) 0.070 2.348 |
| 124 | + count_adder_carry_p_cout[9].cin[0] (adder_carry) 0.043 2.391 |
| 125 | + count_adder_carry_p_cout[9].cout[0] (adder_carry) 0.070 2.461 |
| 126 | + count_adder_carry_p_cout[10].cin[0] (adder_carry) 0.053 2.514 |
| 127 | + count_adder_carry_p_cout[10].cout[0] (adder_carry) 0.070 2.584 |
| 128 | + count_adder_carry_p_cout[11].cin[0] (adder_carry) 0.043 2.627 |
| 129 | + count_adder_carry_p_cout[11].cout[0] (adder_carry) 0.070 2.696 |
| 130 | + count_adder_carry_p_cout[12].cin[0] (adder_carry) 0.053 2.749 |
| 131 | + count_adder_carry_p_cout[12].cout[0] (adder_carry) 0.070 2.819 |
| 132 | + count_adder_carry_p_cout[13].cin[0] (adder_carry) 0.043 2.862 |
| 133 | + count_adder_carry_p_cout[13].cout[0] (adder_carry) 0.070 2.932 |
| 134 | + count_adder_carry_p_cout[14].cin[0] (adder_carry) 0.053 2.985 |
| 135 | + count_adder_carry_p_cout[14].sumout[0] (adder_carry) 0.040 3.025 |
| 136 | + count_dffsre_Q_D[13].in[0] (.names) 0.564 3.589 |
| 137 | + count_dffsre_Q_D[13].out[0] (.names) 0.228 3.818 |
| 138 | + count[13].D[0] (dffsre) 0.000 3.818 |
| 139 | + data arrival time 3.818 |
| 140 | +
|
| 141 | + clock clk (rise edge) 0.000 0.000 |
| 142 | + clock source latency 0.000 0.000 |
| 143 | + clk.inpad[0] (.input) 0.000 0.000 |
| 144 | + count[13].C[0] (dffsre) 0.715 0.715 |
| 145 | + clock uncertainty 0.000 0.715 |
| 146 | + cell setup time -0.057 0.659 |
| 147 | + data required time 0.659 |
| 148 | + ------------------------------------------------------------------------------------------ |
| 149 | + data required time 0.659 |
| 150 | + data arrival time -3.818 |
| 151 | + ------------------------------------------------------------------------------------------ |
| 152 | + slack (VIOLATED) -3.159 |
| 153 | +
|
| 154 | +
|
| 155 | + #End of timing report |
| 156 | + #RPT METADATA: |
| 157 | + path_index/clock_launch_path_elements_num/arrival_path_elements_num |
| 158 | + 0/2/30 |
| 159 | + ", |
| 160 | + "STATUS": "1" |
| 161 | + } |
| 162 | +
|
| 163 | +Draw selected critical path elements example |
| 164 | +-------------------------------------------- |
| 165 | + |
| 166 | + Let's take a look at an example of a request timing report telegram body with the following options: |
| 167 | + |
| 168 | + - path_elements = path 0 and it's sub-elements 10,11,12,13,14,15,20,21,22,23,24,25 |
| 169 | + - high_light_mode = "crit path flylines delays" |
| 170 | + - draw_path_contour = 1 |
| 171 | + |
| 172 | + .. code-block:: json |
| 173 | + :caption: telegram body **REQUEST** example |
| 174 | + :linenos: |
| 175 | +
|
| 176 | + { |
| 177 | + "JOB_ID": "2", |
| 178 | + "CMD": "1", |
| 179 | + "OPTIONS": "string:path_elements:0#10,11,12,13,14,15,20,21,22,23,24,25;string:high_light_mode:crit path flylines delays;bool:draw_path_contour:1" |
| 180 | + } |
| 181 | +
|
| 182 | + **high_light_mode** could have following string values: |
| 183 | + |
| 184 | + - "crit path flylines" |
| 185 | + - "crit path flylines delays" |
| 186 | + - "crit path routing" |
| 187 | + - "crit path routing delays" |
| 188 | + |
| 189 | + Response will look like: |
| 190 | + |
| 191 | + .. code-block:: json |
| 192 | + :caption: telegram body **RESPONSE** example |
| 193 | + :linenos: |
| 194 | +
|
| 195 | + { |
| 196 | + "JOB_ID": "2", |
| 197 | + "CMD": "1", |
| 198 | + "OPTIONS": "string:path_elements:0#10,11,12,13,14,15,20,21,22,23,24,25;string:high_light_mode:crit path flylines delays;bool:draw_path_contour:1", |
| 199 | + "DATA": "", |
| 200 | + "STATUS": "1" |
| 201 | + } |
| 202 | +
|
| 203 | + .. note:: If status is not 1, the field ***DATA*** contains error string. |
| 204 | + |
| 205 | + |
| 206 | + |
| 207 | + |
| 208 | + |
0 commit comments