177 lines
9.6 KiB
C
177 lines
9.6 KiB
C
|
/****************************************************************************************
|
|||
|
|
Y.G.THIEN
|
|||
|
|
29 AUG 2012
|
|||
|
|
|
|||
|
|
This file contains functions related to placement macros. The term "placement macros"
|
|||
|
|
refers to a structure that contains information on blocks that need special treatment
|
|||
|
|
during placement and possibly routing.
|
|||
|
|
|
|||
|
|
An example of placement macros is a carry chain. Blocks in a carry chain have to be
|
|||
|
|
placed in a specific orientation or relative placement so that the carry_in's and the
|
|||
|
|
carry_out's are properly aligned. With that, the carry chains would be able to use the
|
|||
|
|
direct connections specified in the arch file. Direct connections with the pin's
|
|||
|
|
fc_value 0 would be treated specially in routing where the whole carry chain would be
|
|||
|
|
treated as a unit and regular routing would not be used to connect the carry_in's and
|
|||
|
|
carry_out's. Floorplanning constraints may also be an example of placement macros.
|
|||
|
|
|
|||
|
|
The function alloc_and_load_placement_macros allocates and loads the placement
|
|||
|
|
macros in the following steps:
|
|||
|
|
(1) First, go through all the block types and mark down the pins that could possibly
|
|||
|
|
be part of a placement macros.
|
|||
|
|
(2) Then, go through the netlist of all the pins marked in (1) to find out all the
|
|||
|
|
heads of the placement macros using criteria depending on the type of placement
|
|||
|
|
macros. For carry chains, the heads of the placement macros are blocks with
|
|||
|
|
carry_in's not connected to any nets (OPEN) while the carry_out's connected to the
|
|||
|
|
netlist with only 1 SINK.
|
|||
|
|
(3) Traverse from the heads to the tails of the placement macros and load the
|
|||
|
|
information in the t_pl_macro data structure. Similar to (2), tails are identified
|
|||
|
|
with criteria depending on the type of placement macros. For carry chains, the
|
|||
|
|
tails are blocks with carry_out's not connected to any nets (OPEN) while the
|
|||
|
|
carry_in's is connected to the netlist which has only 1 SINK.
|
|||
|
|
|
|||
|
|
The only placement macros supported at the moment are the carry chains with limited
|
|||
|
|
functionality.
|
|||
|
|
|
|||
|
|
Current support for placement macros are:
|
|||
|
|
(1) The arch parser for direct connections is working. The specifications of the direct
|
|||
|
|
connections are specified in sample_adder_arch.xml and also in the
|
|||
|
|
VPR_User_Manual.doc
|
|||
|
|
(2) The placement macros allocator and loader is working.
|
|||
|
|
(3) The initial placement of placement macros that respects the restrictions of the
|
|||
|
|
placement macros is working.
|
|||
|
|
(4) The post-placement legality check for placement macros is working.
|
|||
|
|
|
|||
|
|
Current limitations on placement macros are:
|
|||
|
|
(1) One block could only be a part of a carry chain. In the future, if a block is part
|
|||
|
|
of multiple placement macros, we should load 1 huge placement macro instead of
|
|||
|
|
multiple placement macros that contain the same block.
|
|||
|
|
(2) Bus direct connections (direct connections with multiple bits) are supported.
|
|||
|
|
However, a 2-bit carry chain when loaded would become 2 1-bit carry chains.
|
|||
|
|
And because of (1), only 1 1-bit carry chain would be loaded. In the future,
|
|||
|
|
placement macros with multiple-bit connections or multiple 1-bit connections
|
|||
|
|
should be allowed.
|
|||
|
|
(3) Placement macros that span longer or wider than the chip would cause an error.
|
|||
|
|
In the future, we *might* expand the size of the chip to accommodate such
|
|||
|
|
placement macros that are crucial.
|
|||
|
|
|
|||
|
|
In order for the carry chain support to work, two changes are required in the
|
|||
|
|
arch file.
|
|||
|
|
(1) For carry chain support, added in a new child in <layout> called <directlist>.
|
|||
|
|
<directlist> specifies a list of available direct connections on the FPGA chip
|
|||
|
|
that are necessary for direct carry chain connections. These direct connections
|
|||
|
|
would be treated specially in routing if the fc_value for the pins is specified
|
|||
|
|
as 0. Note that only direct connections that has fc_value 0 could be used as a
|
|||
|
|
carry chain.
|
|||
|
|
|
|||
|
|
A <directlist> may have 0 or more children called <direct>. For each <direct>,
|
|||
|
|
there are the following fields:
|
|||
|
|
1) name: This specifies the name given to this particular direct connection.
|
|||
|
|
2) from_pin: This specifies the SOURCEs for this direct connection. The format
|
|||
|
|
could be as following:
|
|||
|
|
a) type_name.port_name, for all the pins in this port.
|
|||
|
|
b) type_name.port_name [end_pin_index:start_pin_index], for a
|
|||
|
|
single pin, the end_pin_index and start_pin_index could be
|
|||
|
|
the same.
|
|||
|
|
3) to_pin: This specifies the SINKs for this direct connection. The format is
|
|||
|
|
the same as from_pin.
|
|||
|
|
Note that the width of the from_pin and to_pin has to match.
|
|||
|
|
4) x_offset: This specifies the x direction that this connection is going from
|
|||
|
|
SOURCEs to SINKs.
|
|||
|
|
5) y_offset: This specifies the y direction that this connection is going from
|
|||
|
|
SOURCEs to SINKs.
|
|||
|
|
Note that the x_offset and y_offset could not both be 0.
|
|||
|
|
6) z_offset: This specifies the z sublocations that all the blocks in this
|
|||
|
|
direct connection to be at.
|
|||
|
|
|
|||
|
|
The example of a direct connection specification below shows a possible carry chain
|
|||
|
|
connection going north on the FPGA chip:
|
|||
|
|
_______________________________________________________________________________
|
|||
|
|
| <directlist> |
|
|||
|
|
| <direct name="adder_carry" from_pin="adder.cout" to_pin="adder.cin" |
|
|||
|
|
| x_offset="0" y_offset="1" z_offset="0"/> |
|
|||
|
|
| </directlist> |
|
|||
|
|
|_______________________________________________________________________________|
|
|||
|
|
A corresponding arch file that has this direct connection is sample_adder_arch.xml
|
|||
|
|
A corresponding blif file that uses this direct connection is adder.blif
|
|||
|
|
|
|||
|
|
(2) As mentioned in (1), carry chain connections using the directs would only be
|
|||
|
|
recognized if the pin's fc_value is 0. In order to achieve this, pin-based fc_value
|
|||
|
|
is required. Hence, the new <fc> tag replaces both <fc_in> and <fc_out> tags.
|
|||
|
|
|
|||
|
|
A <fc> tag may have 0 or more children called <pin>. For each <fc>, there are the
|
|||
|
|
following fields:
|
|||
|
|
1) default_in_type: This specifies the default fc_type for input pins. They could
|
|||
|
|
be "frac", "abs" or "full".
|
|||
|
|
2) default_in_val: This specifies the default fc_value for input pins.
|
|||
|
|
3) default_out_type: This specifies the default fc_type for output pins. They could
|
|||
|
|
be "frac", "abs" or "full".
|
|||
|
|
4) default_out_val: This specifies the default fc_value for output pins.
|
|||
|
|
|
|||
|
|
As for the <pin> children, there are the following fields:
|
|||
|
|
1) name: This specifies the name of the port/pin that the fc_type and fc_value
|
|||
|
|
apply to. The name have to be in the format "port_name" or
|
|||
|
|
"port_name [end_pin_index:start_pin_index]" where port_name is the name
|
|||
|
|
of the port it apply to while end_pin_index and start_pin_index could
|
|||
|
|
be specified to apply the fc_type and fc_value that follows to part of
|
|||
|
|
a bus (multi-pin) port.
|
|||
|
|
2) fc_type: This specifies the fc_type that would be applied to the specified pins.
|
|||
|
|
3) fc_val: This specifies the fc_value that would be applied to the specified pins.
|
|||
|
|
|
|||
|
|
The example of a pin-based fc_value specification below shows that the fc_values for
|
|||
|
|
the cout and the cin ports are 0:
|
|||
|
|
_______________________________________________________________________________
|
|||
|
|
| <fc default_in_type="frac" default_in_val="0.15" default_out_type="frac" |
|
|||
|
|
| default_out_val="0.15"> |
|
|||
|
|
| <pin name="cin" fc_type="frac" fc_val="0"/> |
|
|||
|
|
| <pin name="cout" fc_type="frac" fc_val="0"/> |
|
|||
|
|
| </fc> |
|
|||
|
|
|_______________________________________________________________________________|
|
|||
|
|
A corresponding arch file that has this direct connection is sample_adder_arch.xml
|
|||
|
|
A corresponding blif file that uses this direct connection is adder.blif
|
|||
|
|
|
|||
|
|
****************************************************************************************/
|
|||
|
|
|
|||
|
|
|
|||
|
|
#ifndef PLACE_MACRO_H
|
|||
|
|
#define PALCE_MACRO_H
|
|||
|
|
|
|||
|
|
/* These are the placement macro structure.
|
|||
|
|
* It is in the form of array of structs instead of
|
|||
|
|
* structs of arrays for cache efficiency.
|
|||
|
|
* Could have more data members for other macro type.
|
|||
|
|
* blk_index: The block index of this block.
|
|||
|
|
* x_offset: The x_offset of the previous block to this block.
|
|||
|
|
* y_offset: The y_offset of the previous block to this block.
|
|||
|
|
*/
|
|||
|
|
typedef struct s_pl_macro_member{
|
|||
|
|
int blk_index;
|
|||
|
|
int x_offset;
|
|||
|
|
int y_offset;
|
|||
|
|
int z_offset;
|
|||
|
|
} t_pl_macro_member;
|
|||
|
|
|
|||
|
|
/* num_blocks: The number of blocks this macro contains.
|
|||
|
|
* members: An array of blocks in this macro [0<EFBFBD><EFBFBD>num_macro-1].
|
|||
|
|
* idirect: The direct index as specified in the arch file
|
|||
|
|
*/
|
|||
|
|
typedef struct s_pl_macro{
|
|||
|
|
int num_blocks;
|
|||
|
|
t_pl_macro_member* members;
|
|||
|
|
} t_pl_macro;
|
|||
|
|
|
|||
|
|
/* These are the function declarations. */
|
|||
|
|
int alloc_and_load_placement_macros(t_direct_inf* directs, int num_directs, t_pl_macro ** chains);
|
|||
|
|
void get_imacro_from_iblk(int * imacro, int iblk, t_pl_macro * macros, int num_macros);
|
|||
|
|
void free_placement_macros_structs(void);
|
|||
|
|
|
|||
|
|
/* Xifan TANG: spot the position of a block in a macro*/
|
|||
|
|
int spot_blk_position_in_a_macro(t_pl_macro pl_macros, int blk_idx);
|
|||
|
|
|
|||
|
|
int check_macros_contained(t_pl_macro pl_macro_a,
|
|||
|
|
t_pl_macro pl_macro_b);
|
|||
|
|
|
|||
|
|
int max_len_pl_macros(int num_pl_macros,
|
|||
|
|
t_pl_macro* pl_macros);
|
|||
|
|
|
|||
|
|
#endif
|