We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

AR# 9782

4.1i Constraints - Virtex/Virtex-E BlockRam - How do I use the "BRAMS_PORTA" and "BRAMS_PORTB" keywords in the 3.1i software?


Keywords: Virtex, Virtex-E, Block, BlockRAM, RAM, BRAMS_PORTA, FIFO, BRAMS_PORTB, constraint

Urgency: Standard

General Description:
Before the release of 3.1i software, a TNM or TNM_NET property that was pushed onto or into a dual-port Virtex block RAM would cause that block RAM instance to be added to the TNM group. Therefore, both ports (bels) of the block RAM would belong to that group. Forward-tracing of TNM groups always marked the instance, regardless of the input pin into which the TNM property traced.

This situation made it difficult to specify timing for a dual-port block RAM on which the two ports were being accessed at different frequencies. To allow specification of separate time groups on dual-port RAMs that use different clock frequencies, two new Timespec keywords were added in 3.1i software: BRAMS_PORTA and BRAMS_PORTB.

This Answer Record discusses the usage of the two keywords, and the possible side effects of using these two attributes.

NOTE: In version 4.1, the TNM properties are correctly analyzed for dual-port RAM. For a 4.1 UCF example, please see (Xilinx Answer 12852).



The BRAMS_PORTA and BRAMS_PORTB attributes can be entered in the UCF or NCF file. The following examples show how they can be used.

The TNM group "groupA" will contain all A ports that are driven by net X. If net X is traced forward into any B-port inputs, any single-port block RAM elements, or any Select RAM elements, these will not become members of groupA.

2. NET "X" TNM_NET=BRAMS_PORTB (dob*) groupB;
The TNM group "groupB" will contain each B port driven by net X, if at least one output on that B port drives a signal that matches the pattern "dob*".

The TNM group "groupC" will contain all B ports found under instance Y. If instance Y is itself a dual-port block RAM primitive, then groupC will contain the B port of that instance.

4. INST "Y" TNM=BRAMS_PORTA (doa*) groupD;
The TNM group "groupD" will contain each A port found under instance Y, if at least one output on that A port drives a signal matching the pattern "doa*".

The user group "groupE" will contain the A ports of all dual-port Block RAM elements in the design. Note that this is equivalent to BRAMS_PORTA (*).

6. TIMEGRP groupF = BRAMS_PORTB (mem/dob*);
The user group "groupF" will contain all B ports in the design that drive a signal matching the pattern "mem/dob*".

The specification "TS01" will control paths that begin at any A port and end at a B port driving a signal that matches the pattern "dob*".

The following additional points should be noted when using these attributes:

1. The BRAMS_PORTA and BRAMS_PORTB keywords apply only to dual-port Block RAM in Virtex and related architectures. They do not apply to single-port Block RAM, nor to a dual-port Select RAM in any architecture. For these other types of RAM elements, you should use RAMS keywords.

2. Constraints Editor does not currently support these two new keywords. The constraint must be entered in the UCF or NCF constraints file.

3. A pattern group defined using one of the new keywords may contain elements that are also members of RAMs-based pattern groups. For example:


In this example, the A ports of all dual-port Block RAM elements will be members of both group ALL_RAMS and group ALL_APORTS.

4. IMPORTANT: The port must drive outputs to be defined by the BRAMS_PORT grouping. If the output port is not connected, the BRAMS_PORT group will be removed from all applicable constraints when the design is parsed by NGDBuild.


Possible side effects of using these attributes

1. If the dual-port Block RAM is controlled by two clocks, CLKA and CLKB, and there are two separate period constraints for CLKA and CLKB, TRCE will report the Block RAM paths in the .twr file based on the ordering of the period constraints that appear in the UCF or NCF file.

For example, if the UCF file has the following entry:

NET clka PERIOD = 20 ns;
NET clkb PERIOD = 15 ns;

the BlockRAM paths will only appear in the .twr file under the CLKB period spec.

To work around this problem and ensure that Block RAM paths appear under the appropriate Timespec, you can use the BRAMS_PORTA, and BRAMS_PORTB attributes to group the Block RAMs. For example, you could use the following syntax to group Block RAMs and FFs:

NET clka TNM_NET = FFS groupA;
NET clkb TNM_NET = FFS groupB;

TIMESPEC TS01 = PERIOD groupA 20ns;
TIMESPEC TS02 = PERIOD groupB 15ns;


Possible side effects of using these two attributes (continued):

2. If the design contains LUT RAMs that share one of the clocks for the dual-port Block RAMs, there is no way to keep the inappropriate Block RAM ports out of the RAM group.

For example, if the following TIMEGRP is in the constraint file:

NET clka TNM_NET = RAMS all_ram;

it would pull in not only all the LUT RAMs, but also both ports of the BlockRams. This is because BRAMS_PORTx groups are subsets of the broader RAMs group.

Therefore, in cases where LUT RAMs are involved, the only work-around is to define user time groups and use EXCEPT clauses in the constraint files. If the CLKDLL is used in the design, it would require the use of all nets at the CLKDLL outputs to specify these time groups. This is because user-defined time group names cannot currently be pushed through the CLKDLL.

The following is an example of using an EXCEPT clause to group LUT RAMs, FFs, and port A of the dual-port Block RAM in the same TIMEGRP in the constraint file:

NET "clka" TNM_NET = "FFS:clka_nolutrams";
NET "clka" TNM_NET = "BRAMS_PORTA:clka_nolutrams";
NET "clka" TNM_NET = "RAMS:clka_allrams";

TIMEGRP "clka_lutrams" = "clka_allrams EXCEPT BRAMS_PORTA BRAMS_PORTB";
TIMEGRP "clka" = "clka_nolutrams clka_lutrams";
AR# 9782
Date Created 07/25/2000
Last Updated 08/22/2003
Status Archive
Type General Article