Updating k6_N10_40nm.xml and adding k6_N10_sparse_crossbar_40nm.xml. These architectures are now more heavily commented and suitable for work in a grad course (ECE 1756). I cut the logic block areas to something more reasonable for a simple architecture like this; the area numbers for the logic blocks and the local mux delays for the sparse architecture are based on coarse scaling / guessing so they aren't extremely accurate.

Author: Vaughn Betz

vtr_flow/arch/timing/k6_N10_40nm.xml

@@ -4,27 +4,38 @@
   - 40 nm technology
   - General purpose logic block: 
     K = 6, N = 10
-  - Routing architecture: L = 4, fc_in = 0.15, Fc_out = 0.1
+  - Routing architecture: L = 4, fc_in = 0.15, fc_out = 0.15
+  - Unidirectional (mux-based) routing
+
 
   Details on Modelling:
 
   Based on flagship k6_frac_N10_mem32K_40nm.xml architecture.  This architecture has no fracturable LUTs nor any heterogeneous blocks.
-
+  The delays and areas are based on a mix of values from commercial 40 nm
+  FPGAs with a comparable architecture and 40 nm interconnect and 
+  transistor models.
 
   Authors: Jason Luu, Jeff Goeders, Vaughn Betz
 -->
 <architecture>
   <!-- 
        ODIN II specific config begins 
-       Describes the types of user-specified netlist blocks (in blif, this corresponds to 
-       ".model [type_of_block]") that this architecture supports.
-
-       Note: Basic LUTs, I/Os, and flip-flops are not included here as there are 
-       already special structures in blif (.names, .input, .output, and .latch) 
-       that describe them.
+       This part of the architecture file describes the "primitives" 
+       that exist in a device to the synthesis tool used to "elaborate" 
+       verilog into these primitives (which is called ODIN-II).
+       Basic LUTs, I/Os and FFs are built into the language used by this 
+       flow (blif keywords .names, .input, .output and .latch), so they 
+       don't have to be described here.
+    
+       For this lab you are also given the benchmark netlists after 
+       synthesis is complete (in the blif directory), so you don't need 
+       to run ODIN II.
   -->
   <models>
   </models>
+  <!-- ODIN II specific config ends -->
+
+  <!-- Descritions of the physical tiles that exist on the die begins -->
   <tiles>
     <tile name="io" area="0">
       <sub_tile name="io" capacity="8">
@@ -34,7 +45,15 @@
         <input name="outpad" num_pins="1"/>
         <output name="inpad" num_pins="1"/>
         <clock name="clock" num_pins="1"/>
-        <fc in_type="frac" in_val="0.15" out_type="frac" out_val="0.10"/>
+        <fc in_type="frac" in_val="0.15" out_type="frac" out_val="0.15"/>
+      <!-- IOs go on the periphery of the FPGA in this 
+           architecture. Since I don't want to define four 
+           different physical I/Os for the left, right, top, 
+           and bottom sides just say each pin of the I/O 
+           block is accessible from all four sides so we can
+           reach routing channels on some side of the block
+           no matter which side of the chip we're on.
+        -->
         <pinlocations pattern="custom">
           <loc side="left">io.outpad io.inpad io.clock</loc>
           <loc side="top">io.outpad io.inpad io.clock</loc>
@@ -43,21 +62,42 @@
         </pinlocations>
       </sub_tile>
     </tile>
-    <tile name="clb" area="53894">
+
+    <!-- Define general purpose logic block (CLB) begin -->
+          <!-- Area below is for everything inside the
+                logic block (LUTs, FFs, intra-cluster 
+                routing). It's a bit on the low side given the large crossbars in this
+                architecture - more appropriate for a lower-cost
+                FPGA with smaller transistors and narrower metal.
+                -->
+    <tile name="clb" area="18000">
+      <!-- We can place a clustered block of type clb on a tile location 
+           of type clb.
+           -->
       <sub_tile name="clb">
         <equivalent_sites>
           <site pb_type="clb" pin_mapping="direct"/>
         </equivalent_sites>
+
+      <!-- We have a full crossbar between the cluster inputs and the 
+           LUT inputs, so the router can route to *any* input or from
+           *any* output on the logic block.  Hence mark the logic block
+           inputs as fully logically equivalent (swappable by the router) and also the
+           logic block outputs as logically equivalent, which means
+           they can also be swapped by the router.
+           -->
+
         <input name="I" num_pins="40" equivalent="full"/>
         <output name="O" num_pins="10" equivalent="instance"/>
         <clock name="clk" num_pins="1"/>
-        <fc in_type="frac" in_val="0.15" out_type="frac" out_val="0.10"/>
+        <fc in_type="frac" in_val="0.15" out_type="frac" out_val="0.15"/>
         <pinlocations pattern="spread"/>
       </sub_tile>
     </tile>
   </tiles>
-  <!-- ODIN II specific config ends -->
-  <!-- Physical descriptions begin -->
+  <!-- Physical tile descriptions end -->
+  
+  <!-- Chip layout (in terms of where tiles are) begins -->
   <layout>
     <auto_layout aspect_ratio="1.0">
       <!--Perimeter of 'io' blocks with 'EMPTY' blocks at corners-->
@@ -67,22 +107,11 @@
       <fill type="clb" priority="10"/>
     </auto_layout>
   </layout>
+  <!-- Chip layout ends -->
+
+  <!-- Electrical and inter-cluster (general) routing description begins -->
   <device>
-    <!-- VB & JL: Using Ian Kuon's transistor sizing and drive strength data for routing, at 40 nm. Ian used BPTM 
-			     models. We are modifying the delay values however, to include metal C and R, which allows more architecture
-			     experimentation. We are also modifying the relative resistance of PMOS to be 1.8x that of NMOS
-			     (vs. Ian's 3x) as 1.8x lines up with Jeff G's data from a 45 nm process (and is more typical of 
-			     45 nm in general). I'm upping the Rmin_nmos from Ian's just over 6k to nearly 9k, and dropping 
-			     RminW_pmos from 18k to 16k to hit this 1.8x ratio, while keeping the delays of buffers approximately
-			     lined up with Stratix IV. 
-			     We are using Jeff G.'s capacitance data for 45 nm (in tech/ptm_45nm).
-			     Jeff's tables list C in for transistors with widths in multiples of the minimum feature size (45 nm).
-			     The minimum contactable transistor is 2.5 * 45 nm, so I need to multiply drive strength sizes in this file
-	                     by 2.5x when looking up in Jeff's tables.
-			     The delay values are lined up with Stratix IV, which has an architecture similar to this
-			     proposed FPGA, and which is also 40 nm 
-			     C_ipin_cblock: input capacitance of a track buffer, which VPR assumes is a single-stage
-			     4x minimum drive strength buffer. -->
+    <!-- Some area and timing parameters -->
     <sizing R_minW_nmos="8926" R_minW_pmos="16067"/>
     <!-- The grid_logic_tile_area below will be used for all blocks that do not explicitly set their own (non-routing)
      	  area; set to 0 since we explicitly set the area of all blocks currently in this architecture file.
@@ -92,49 +121,61 @@
       <x distr="uniform" peak="1.000000"/>
       <y distr="uniform" peak="1.000000"/>
     </chan_width_distr>
+
+    <!-- Define the switch block pattern (pattern of switches between inter-tile routing wires)
+         The Wilton switch block is a sample pattern; you can use custom switch blocks for more control -->
     <switch_block type="wilton" fs="3"/>
+
+    <!-- Set which switch to use for input connection blocks. Only affects timing and area, not connectivity -->
     <connection_block input_switch_name="ipin_cblock"/>
   </device>
   <switchlist>
     <!-- VB: the mux_trans_size and buf_size data below is in minimum width transistor *areas*, assuming the purple
 	       book area formula. This means the mux transistors are about 5x minimum drive strength.
 	       We assume the first stage of the buffer is 3x min drive strength to be reasonable given the large 
-	       mux transistors, and this gives a reasonable stage ratio of a bit over 5x to the second stage. We assume
-	       the n and p transistors in the first stage are equal-sized to lower the buffer trip point, since it's fed
-	       by a pass transistor mux. We can then reverse engineer the buffer second stage to hit the specified 
-	       buf_size (really buffer area) - 16.2x minimum drive nmos and 1.8*16.2 = 29.2x minimum drive.
-	       I then took the data from Jeff G.'s PTM modeling of 45 nm to get the Cin (gate of first stage) and Cout 
-	       (diff of second stage) listed below.  Jeff's models are in tech/ptm_45nm, and are in min feature multiples.
-	       The minimum contactable transistor is 2.5 * 45 nm, so I need to multiply the drive strength sizes above by 
-	       2.5x when looking up in Jeff's tables.
-	       Finally, we choose a switch delay (58 ps) that leads to length 4 wires having a delay equal to that of SIV of 126 ps.
-	       This also leads to the switch being 46% of the total wire delay, which is reasonable. -->
+	       mux transistors, and this gives a reasonable stage ratio of a bit over 5x to the second stage. 
+	       -->
     <switch type="mux" name="0" R="551" Cin=".77e-15" Cout="4e-15" Tdel="58e-12" mux_trans_size="2.630740" buf_size="27.645901"/>
     <!--switch ipin_cblock resistance set to yeild for 4x minimum drive strength buffer-->
     <switch type="mux" name="ipin_cblock" R="2231.5" Cout="0." Cin="1.47e-15" Tdel="7.247000e-11" mux_trans_size="1.222260" buf_size="auto"/>
   </switchlist>
   <segmentlist>
     <!--- VB & JL: using ITRS metal stack data, 96 nm half pitch wires, which are intermediate metal width/space.  
-			     With the 96 nm half pitch, such wires would take 60 um of height, vs. a 90 nm high (approximated as square) Stratix IV tile so this seems
-			     reasonable. Using a tile length of 90 nm, corresponding to the length of a Stratix IV tile if it were square. -->
+          Wires of this pitch will fit over a 90 nm
+          high logic tile (which is about the height of a Stratix IV logic tile).
+          I'm using a tile length of 90 nm, corresponding to the length of a Stratix IV tile if it were square. 
+          length below is in units of logic blocks, and Rmetal and Cmetal are
+          per logic block passed, so wire delay adapts automatically if you change the
+          length=? value.   -->
+
+    <!-- Currently only one type of routing wire, which
+         is of length 4 and has switches to every connection
+         box (4 of them) and switch box (5 of them) 
+         it passes. You can change wirelengths just by changing the length="?" values
+         and changing the number of 1's (or 0's) in the <sb type and <cb type lines to
+         match the number of switch blocks and connection blocks a wire of that length
+         would span. -->
     <segment freq="1.000000" length="4" type="unidir" Rmetal="101" Cmetal="22.5e-15">
       <mux name="0"/>
       <sb type="pattern">1 1 1 1 1</sb>
       <cb type="pattern">1 1 1 1</cb>
     </segment>
   </segmentlist>
+  <!-- Electrical and inter-cluster routing description ends -->
+
+  <!-- Description of the capabilities (number of BLEs, modes) and local interconnect in
+       each type of complex (clustered) block (e.g. LBs) begins
+    -->
   <complexblocklist>
     <!-- Define I/O pads begin -->
-    <!-- Capacity is a unique property of I/Os, it is the maximum number of I/Os that can be placed at the same (X,Y) location on the FPGA -->
     <!-- Not sure of the area of an I/O (varies widely), and it's not relevant to the design of the FPGA core, so we're setting it to 0. -->
     <pb_type name="io">
       <input name="outpad" num_pins="1"/>
       <output name="inpad" num_pins="1"/>
       <clock name="clock" num_pins="1"/>
       <!-- IOs can operate as either inputs or outputs.
-	     Delays below come from Ian Kuon. They are small, so they should be interpreted as
-	     the delays to and from registers in the I/O (and generally I/Os are registered 
-	     today and that is when you timing analyze them.
+	     The delays below are to and from registers in the I/O (and generally I/Os are registered 
+	     today).
 	     -->
       <mode name="inpad">
         <pb_type name="inpad" blif_model=".input" num_pb="1">
@@ -156,25 +197,17 @@
           </direct>
         </interconnect>
       </mode>
-      <!-- Every input pin is driven by 15% of the tracks in a channel, every output pin is driven by 10% of the tracks in a channel -->
-      <!-- IOs go on the periphery of the FPGA, for consistency, 
-          make it physically equivalent on all sides so that only one definition of I/Os is needed.
-          If I do not make a physically equivalent definition, then I need to define 4 different I/Os, one for each side of the FPGA
-        -->
-      <!-- Place I/Os on the sides of the FPGA -->
+
+      <!-- Not modeling I/O power for now -->
       <power method="ignore"/>
     </pb_type>
     <!-- Define I/O pads ends -->
+
     <!-- Define general purpose logic block (CLB) begin -->
-    <!--- Area calculation: Total Stratix IV tile area is about 8100 um^2, and a minimum width transistor 
-	   area is 60 L^2 yields a tile area of 84375 MWTAs.
-	   Routing at W=300 is 30481 MWTAs, leaving us with a total of 53000 MWTAs for logic block area 
-	   This means that only 37% of our area is in the general routing, and 63% is inside the logic
-	   block. Note that the crossbar / local interconnect is considered part of the logic block
-	   area in this analysis. That is a lower proportion of of routing area than most academics
-	   assume, but note that the total routing area really includes the crossbar, which would push
-	   routing area up significantly, we estimate into the ~70% range. 
-	   -->
+          <!-- Area below is for everything inside the
+                logic block (LUTs, FFs, intra-cluster 
+                routing).  
+           -->
     <pb_type name="clb">
       <input name="I" num_pins="40" equivalent="full"/>
       <output name="O" num_pins="10" equivalent="instance"/>
@@ -198,22 +231,16 @@
               <input name="in" num_pins="6" port_class="lut_in"/>
               <output name="out" num_pins="1" port_class="lut_out"/>
               <!-- LUT timing using delay matrix -->
-              <!-- These are the physical delay inputs on a Stratix IV LUT but because VPR cannot do LUT rebalancing,
-                       we instead take the average of these numbers to get more stable results
+              <!-- These are the delay per LUT input on a Stratix IV LUT.
+                   The average is 261 ps, and inputs earlier in the mux tree are slower.
+                  -->
+              <delay_matrix type="max" in_port="lut6.in" out_port="lut6.out">
                   82e-12
                   173e-12
                   261e-12
                   263e-12
                   398e-12
                   397e-12
-                  -->
-              <delay_matrix type="max" in_port="lut6.in" out_port="lut6.out">
-                261e-12
-                261e-12
-                261e-12
-                261e-12
-                261e-12
-                261e-12
               </delay_matrix>
             </pb_type>
             <!-- Define flip-flop -->
@@ -224,6 +251,10 @@
               <T_setup value="66e-12" port="ff.D" clock="clk"/>
               <T_clock_to_Q max="124e-12" port="ff.Q" clock="clk"/>
             </pb_type>
+
+            <!-- many lines below to describe the interconnect
+                 wires, muxes and crossbars inside a cluster.
+              -->
             <interconnect>
               <direct name="direct1" input="ble6.in" output="lut6[0:0].in"/>
               <direct name="direct2" input="lut6.out" output="ff.D">
@@ -262,15 +293,12 @@
         </complete>
         <complete name="clks" input="clb.clk" output="fle[9:0].clk">
         </complete>
-        <!-- This way of specifying direct connection to clb outputs is important because this architecture uses automatic spreading of opins.  
-               By grouping to output pins in this fashion, if a logic block is completely filled by 6-LUTs, 
-               then the outputs those 6-LUTs take get evenly distributed across all four sides of the CLB instead of clumped on two sides (which is what happens with a more
-               naive specification).
+
+        <!-- The BLE outputs are directly connected to the
+             CLB (cluster) outputs.  
           -->
         <direct name="clbouts1" input="fle[9:0].out" output="clb.O"/>
       </interconnect>
-      <!-- Every input pin is driven by 15% of the tracks in a channel, every output pin is driven by 10% of the tracks in a channel -->
-      <!-- Place this general purpose logic block in any unspecified column -->
     </pb_type>
     <!-- Define general purpose logic block (CLB) ends -->
   </complexblocklist>