Virtex-II block RAM problem

Show the actual clock constraints you are using.

In the past I've had no problems using the blockRAM for similar tasks, so these problems really came as a surprise. In fact, the code has evolved from the older version (which never had such issues). I am trying now to redo the transition step-by-step to see where the problems start.

Unfortunately, at this point my trust in tools is not too great, especially since XST will not properly synthesize dual-port blockRAM coded according to the templates distributed with the ISE (examples_v9.zip).

The data acquisition logic as well as BRAMs are clocked by a DCM which drives a BUFG. Here is the timing constraint for the DCM input clock:

NET "clkp" TNM_NET = FFS(*) "clkp"; TIMESPEC "TS_clkp" = PERIOD "clkp" 3.8 ns HIGH 50 %;

The data acquisition logic and BRAMs are clocked by a DCM driving a BUFG. The DCM divides the input clock by 2 (using CLKDV output). Here is the timing constraint on the DCM input clock:

NET "clkp" TNM_NET = FFS(*) "clkp"; TIMESPEC "TS_clkp" = PERIOD "clkp" 3.8 ns HIGH 50 %;

Get rid of the FFS(*) and see what happens.

The BlockRAM specifically needs RAMS(*) if you're trying to keep other elements such as multipliers and latches off the timing specification. I usually end up with something like

NET sysClk TNM_NET = sysClk;

to specify my main clock. In this syntax it applies to all sequential elements.

- John_H

John,

Thanks a million! Of course that was it, now everything runs fine up to

Would the unimportant warnings in question happen to be the one about PAR/MAP getting confused between PAD and IOB FFs timing constraints? I am glad I saw this thread because I was about to make the very same mistake to get rid of those warnings too!

I added FFS(*) to the constraint to get rid of the following warning in the translation report:

WARNING:XdmHelpers:662 - Period specification "TS_clk_ctrl_aclk4_dcm" references the TNM group "clk_ctrl_aclk4_dcm", which contains both pads and synchronous elements. The timing analyzer will ignore the pads for this specification. You might want to use a qualifier (e.g. "FFS") on the TNM property to remove the pads from this group.

I reckon that warning ought to end with "... but you probably don't as this might break all sorts of other things unless you really understand what this does"

:-)

Xilinx: How about a) A better warning b) the ability to say "NOPADS" on the TNM property (or NOFFS, NORAMS etc...)

Cheers, Martin

I know the EXCEPT can be used to define timing groups but I'm not sure about the TNM_NET. I'd be interested to see if

NET myclk TNM_NET = EXCEPT PADS(*) myclk; or NET myclk TNM_NET = ALL EXCEPT PADS(*) myclk;

works. I think ALL may be a proper keyword but I forget the details.

It might be a matter of 1) defining a catchall TNM_NET, then 2) redefining that timing group with the EXCEPT keyword.

I'd love to see someone spend a few minutes with the constraints guide and see if they can get that error to go away in one or two statements to fully define the group. Personally, I don't push my clocks directly out onto pads (I'll run them though an ODDR2 primitive first) so I don't end up seeing the warnings.

The syntax

NET myclk TNM_NET = FFS(*) LATCHES(*) MULTS(*) RAMS(*) myclk;

(and any othere synchronous elements I've forgotten) is another approach that should work.

Tried both of the above - no go:

ERROR:NgdBuild:765 - "foo.ucf" Line 40: A parsing error has occurred while reading the constraint file. The value 'EXCEPT' at column 22 is invalid.

My constraint is on an input clock. The differential inputs go directly into a clock control module which instantiates IBUFDS and feeds it to some DCMs. So at the top level the input pad signal is the only one which will propagate the constraint through the DCMs.

No such luck:

ERROR:NgdBuild:765 - "foo.ucf" Line 40: A parsing error has occurred while reading the constraint file. The value 'LATCHES' at column 30 is invalid.

So it seems that the only way to get rid of the warnings would be to pull the IBUFDS to the top level and place the TNM_NET on its output.

Yup, that is the annoying warning I was thinking about. I wish there was a simple timespec for everything except pads... everything synchronous. From other replies in this thread, it seems like the only way is exhaustive enumeration.

I knew there was something like that, but my quick reread of the constraints guide didn't point me at it - thanks!

and therein lies the problem :-) Using EXCEPT would allow the tools to remember for you (we hope..)

Cheers, Martin

Let me step back from the long thread a moment. According to the constraints guide:

Assigning Definitions for DLL/DCM Clocks

TRANSLATION (NGDBuild) propagates TNM_NET tags through DLLs and DCMs. NGDBuild creates new TNM_NETs for each of the DLL and DCM output taps and associated PERIOD statements. The code takes into account the phase relationship factor of the outputs for the DLL, and also performs the appropriate multiplication or division of the PERIOD value.

The code also takes into account any of the PHASE taps adjustments. This means that for OFFSETs and cross-clock domain paths, the timing tools now know the relationship for PHASE shifts also.

So have you tried just a period constraint on the input clock and removed all other constraints?