Virtex-II block RAM problem

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Hello,

I am running into a strange problem with the dual-port block RAM in
Virtex-II and at this point have run out of ideas :(

In my design I am trying to perform data acquisition on a 32-bit parallel
data stream running at 125 MHz. I have two memory blocks into which I want
to be able to direct the data: internal block RAM and external SRAM.
Internal RAM is dual ported with one port connected to the local bus. SRAM
controller has can be switched between the local bus and the data port.
Data source is the same for both block RAM and the SRAM - their inputs are
taken from a single signal. Within the design I have a little test pattern
generator to produce a fake data stream for testing.

So here is the problem: the data is written correctly into the SRAM, but
not into the block RAM. It is a timing problem - errors go away if I lower
the clock frequency.

The same problem persist with both ISE 8.2i and 9.1i. Here are some
numbers:

The part is XC2V3000-4FF1152. Clock constraint is 7.6 ns. Static timing
analysis gives me 7.632 ns. Experimentally-determined maximum clock
frequency for error-free acquisition into the block RAM is 105 MHz.
Maximum clock frequency for SRAM - around 150 MHz.

As I play around with block RAM (instantiated vs. inferred, pipelining in
front of the memory), maximum frequency moves in the range from 90 to
120 MHz. SRAM maximum frequency is consistently around 150 MHz. Block RAM
errors are typically single-bit, sometimes two bits. Which bit it is seems
to move around from one compilation to another.

--
Dmitry Teytelman

Re: Virtex-II block RAM problem
Quoted text here. Click to load it



Re: Virtex-II block RAM problem
Dmitry, whatever timing poblems you have has nothing to do with the
BlockRAM itself.
It is a synchronous device (think of it as a flip-flop or register)
with a data and address input set-up time below 1 ns, and no hold time
requirement. Clock-to-out (for reading) can be up to 3 ns.
If you have problems below 150 MHz, those timing problems are
elsewhere.
I hope you use a global clock for clocking the BRAM and the adjacent
logic...
Peter Alfke, Xilinx Applications

On Mar 20, 4:07 pm, snipped-for-privacy@moc.liamg wrote:
Quoted text here. Click to load it



Re: Virtex-II block RAM problem

Quoted text here. Click to load it

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).

Quoted text here. Click to load it

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 %;

--
Dmitry Teytelman

Re: Virtex-II block RAM problem
Quoted text here. Click to load it

Show the actual clock constraints you are using.

Re: Virtex-II block RAM problem

Quoted text here. Click to load it

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 %;

--
Dmitry Teytelman

Re: Virtex-II block RAM problem
Quoted text here. Click to load it

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

Re: Virtex-II block RAM problem

Quoted text here. Click to load it

John,

Thanks a million! Of course that was it, now everything runs fine up to
325 MHz. And my earlier (working) version did not have FFS(*). That is
what happens when you try to get rid of unimportant warnings :(

--
Dmitry Teytelman

Re: Virtex-II block RAM problem
Quoted text here. Click to load it

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!

Re: Virtex-II block RAM problem
Hello Daniel,


Quoted text here. Click to load it

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.

--
Dmitry Teytelman

Re: Virtex-II block RAM problem

Quoted text here. Click to load it

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

--
snipped-for-privacy@trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
We've slightly trimmed the long signature. Click to see the full one.
Re: Virtex-II block RAM problem
Quoted text here. Click to load it

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.

Re: Virtex-II block RAM problem

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

--
Dmitry Teytelman

Re: Virtex-II block RAM problem

Quoted text here. Click to load it

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

<snip>
Quoted text here. Click to load it

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

Cheers,
Martin

--
snipped-for-privacy@trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
We've slightly trimmed the long signature. Click to see the full one.
Re: Virtex-II block RAM problem
Quoted text here. Click to load it

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.

Re: Virtex-II block RAM problem
Quoted text here. Click to load it

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?

Site Timeline