Xilinx Block RAM Sim

I have generated a memory with coregen. It has a write port clocked from
clka and a registered read port clocked from clkb. When I simulate it the
written data appears 2 clk cycles after the address changes which is what I
expect. However there is also a 100ps delay from the clk edge to when the
data changes. So I basically have a delay of 2 clk cycles plus 100ps. Is
this an error or have I missed something?

Cheers

Jon

On Jun 8, 5:10 am, "maxascent" <maxasc...@yahoo.co.uk> wrote:
> I have generated a memory with coregen. It has a write port clocked from
> clka and a registered read port clocked from clkb. When I simulate it the
> written data appears 2 clk cycles after the address changes which is what I
> expect. However there is also a 100ps delay from the clk edge to when the
> data changes. So I basically have a delay of 2 clk cycles plus 100ps. Is
> this an error or have I missed something?
>
> Cheers
>
> Jon

The 100pS delay is from the model.

It is there so that if you are debugging by using a waveform viewer it
is obvious that the data comes AFTER the clock.

AL

But there isnt any 100ps delay on the actual device.

Jon

On Mon, 08 Jun 2009 10:55:50 -0500
"maxascent" <maxascent@yahoo.co.uk> wrote:

> But there isnt any 100ps delay on the actual device.
> 
> Jon

That depends on where in the chip you're routing the data to.
Post-routing you could easily have 2-3 ns of delay.

-- 
Rob Gaddi, Highland Technology
Email address is currently out of order

But I dont understand why Xilinx have put this 100ps delay in the output
that doesnt seems to relate to anything in the Virtex 5 datasheet. 

Jon

"maxascent" <maxascent@yahoo.co.uk> wrote in message 
news:dvidnUoYUYuBoLDXnZ2dnUVZ_vidnZ2d@giganews.com...
> But I dont understand why Xilinx have put this 100ps delay in the output
> that doesnt seems to relate to anything in the Virtex 5 datasheet.
>

It's common in models to put output delays on output to make waveforms more 
readable.

Don't worry about it.  It shouldn't affect functionality.  If it does, 
you're probably doing something wrong!

On Jun 8, 9:32=A0am, "maxascent" <maxasc...@yahoo.co.uk> wrote:
> But I dont understand why Xilinx have put this 100ps delay in the output
> that doesnt seems to relate to anything in the Virtex 5 datasheet.

Because there are too many "engineers" who don't understand the notion
of a functional simulation with delta delays and these are the same
engineers who litter their own code with "after 1 ns" and the like.

It's babyfood for the lazy.

-a

Andy Peters wrote:

> Because there are too many "engineers" who don't understand the notion
> of a functional simulation with delta delays and these are the same
> engineers who litter their own code with "after 1 ns" and the like.

... and some vendor models started life as verilog,
which has no clean delta delay.

If I write my own synthesis code,
I don't need the vendor model
of the secret netlist.

      -- Mike Treseler

On Jun 8, 12:32=A0pm, "maxascent" <maxasc...@yahoo.co.uk> wrote:
> But I dont understand why Xilinx have put this 100ps delay in the output
> that doesnt seems to relate to anything in the Virtex 5 datasheet.
>
> Jon

Very often I have found that Xilinx models have gated clocks
or at least clock signals with buffering on them.  Sometimes
these lead to misbehavior of the simulation if there is no
delay.  An earlier version of the block RAM used to show
read data on the same clock edge where the address was changed
instead of one cycle later.  I wouldn't spend too much time
trying to second guess why they "fixed" the model by adding
delay rather than simplifying the clock path.  Just because
Xilinx is a large company with a lot of resources doesn't
mean that everyone who writes models for them is a great
expert.  Very often such large companies use summer co-op
students and the like to do this sort of grunt-work.

Just my 2 cents,
Gabor

On Jun 8, 12:32=A0pm, "maxascent" <maxasc...@yahoo.co.uk> wrote:
> But I dont understand why Xilinx have put this 100ps delay in the output
> that doesnt seems to relate to anything in the Virtex 5 datasheet.
>
> Jon

Why do you think there is no delay in the real part?  No matter where
you measure it, there will be some delay.  It is hard to measure
delays inside the FPGA, so they only spec delays they can verify
externally.  If you look at the timing diagrams in the data sheet,
they don't show the data out of a memory changing exactly on the clock
edge.  They show it changing some time later as it would in any real
part.

Besides, why are you worried about this?  You are not doing a timing
simulation, which is pretty pointless anyway.

So where is the problem?

Rick