Implementation

[gemmagilmore]

I am rebuilding a design switching my synthesis tool from Precision to Synplify using ISE10.1 SP3 and a x2vp30 FPGA.

The design has 12 LVDS input clocks and 7 other clock resources.  I can see from loading the .ncd file into FPGA_EDITOR that the original design uses the pads on the input pins to generate the LVDS clocks and BUFGMUXs for the others.  This is the expected behavior.

However, when I try to build with the new Synplify .edn file, 9 of the 12 LVDS clocks are mapped to BUFGMUXs (undesired) using them all up leaving routing confilcts with the other clock resources (that do need them).  This ultimately results in an unroutable design where the PAR process fails with the tool suggesting I fix the problem using FPGA_EDITOR.

What is particularly strange is that for each LVDS clock, IBUFDSs are explicitly instantiated, (not inferred) in the top level RTL code and each has a fan out of ony 20 so a global clocking resource isn't even required.  

There was clearly a problem in the original design as the output clock from each IBUFDS has a physical routing constraint (made up of co-ordinates) implemented in the .ucf file, but, this does not have any impact in the routing of the new design (strange again). 

The design is now has unecessary nets and unecessary components... the design is supposed to go

IBUFDS(I0=>clk1_p, I1=>clk1_n, O=>LVDS_CLK1) ...fan out 20, routed to rest of design

but instead does...

IBUFDS(I0=>clk1_p, I1=>clk1_n, O=>LVDS_CLK1_c) ...fan out 1 driven into....

BUFGMUX(I0=>LVDS_CLK1_c, I1=>open, O=>LVDS_CLK1) ... fan out 19 but unroutable due to the lack of BUFGMUX input resources...

I tried adding LOC constraints for each of the desired clock resources to BUFGMUXs but this now causes the design to fail at the MAP stage with  placement error regarding a routing conflict as before..... As 3 of the 12 LVDS clocks were mapped as expected, I did not think this would cause problems but the tool is still trying to place the other 9 LVDS clocks using BUFGMUXs.

What I want is to know how to tell the design to not use the BUFGMUXs (under any circumastances)..

Any help with this would be greatly appreciated...

Thanks in advance,

gems

[eteam00]

IBUFDS(I0=>clk1_p, I1=>clk1_n, O=>LVDS_CLK1) ...fan out 20, routed to rest of design

but instead does...

IBUFDS(I0=>clk1_p, I1=>clk1_n, O=>LVDS_CLK1_c) ...fan out 1 driven into....

BUFGMUX(I0=>LVDS_CLK1_c, I1=>open, O=>LVDS_CLK1) ... fan out 19 but unroutable due to the lack of BUFGMUX input resources...

IBUFDS is simply an input buffer for differential inputs.  It is not a clock distribution buffer.

Signals used as a clock in the FPGA must be properly buffered.  The BUFGMUX is such a clock buffer.

The synthesiser, it seems, is trying to do the right thing.

I am not a Virtex-2 expert.  Is there a requirement in Virtex-2 devices that BUFGMUX buffers must be driven from a clock-capable (or GCLK) pin?  If so, this may be the underlying problem which provokes the unroutable signal condition.

-- Bob Elkind

[gszakacs · Accepted solution]

In XST there is a BUFFER_TYPE attribute you can apply to a clock signal to say what

sort of buffer if any to use.  Setting this to "none" prevents insertion of a BUFGMUX.  In

Synplify there may be something similar.  If not, there is probably a global setting to

turn on or off clock buffer insertion.  Then you need to manually instantiate the BUFGMUX

(or BUFG) on each clock that needs one.

For non-globally buffered clock nets, you should attach the attribute USELOWSKEWLINES

(this is from memory - check it) to reduce skew between the loads on that clock net.

I imagine that Synplify should come with a user manual that describes how to attach

these attributes to a net for Xilinx designs.

-- Gabor

[gemmagilmore]

Thanks so much for your help guys...

I thought the problem was during the map stage, not synthesis (although that was the main build change - duh!)

After my signal declarations for the output of each IBUFDS I added the following attribute which gave me a successful build.

entity declaration

...

component declarations

...

SIGNAL LVDS_CLK1      : std_logic;
attribute syn_noclockbuf of LVDS_CLK1  : signal is true;

...

architecture

...

LVDS_CLK1_BUF : IBUFDS port map (  I => CLK1_P ,   IB => CLK1_N,    O => LVDS_CLK1    );

I found a good online source for all the synplify documentation (I always find the Synopsys site hard to navigate):  

http://www.cs.washington.edu/lab/facilities/hwlab/pdfs/syndoc/synpro_docs.pdf

The user guide details the syntax for applying attributes and the reference manual details all of the attributes available for the different technologies.

Thanks again,

Kind regards

gems

[gszakacs]

Thanks for sharing your solution, and let's hope that the link to the documents stays

valid at least until the next person needs to use it :-)

-- Gabor