Fall Times and Pullup

Did you do the math? Did you try to simulate?

Take the Pull up current in relation to the low drive sink current...

--
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

mstadt.de

Let's give the poor guy a clue.

What impedance is a driver designed to drive an edge into? If you don't know what a transmission line is you are in it up to your neck.

a

armstadt.de

I am trying to analyze the behavior of the SD card data lines. According to the specifications, the SD card is supposed to drive the data at the falling edge of the clock and the host shall sample the data at the rising edge of the clock.

Now I see that the data transition of line going low, happens 8ns after a falling edge. Now _assuming_ that the card uses a flip flop to drive the output line, I would imagine the clock to output to be anywhere between

2ns to 3ns. But I observe an 8ns clock to output. So I am not sure if it is the card that is at fault of driving the output so slow or is it the pull up on the line that is pulling the line hard to keep it 1 for a longer time.

Thanks Shyam

There is no simulation that I am doing here. I have a board and am observing the behavior mentioned in my next post in reply to colin.

The pullup is via a 10K resistor to a 3.3v supply line.

Thanks Shyam

mstadt.de

s a

l

-darmstadt.de

To answer your original question, the fall time of an open collector/ drain is largely determined by the drive strength of the output and the capacitance of the line and input. There is some contribution by the pullup as any current through the pullup is not going through the capacitance, but with a value of 10 kohms it won't have much contribution.

I can't say why the delay inside the SD card is 8 ns rather than 3 ns. But I would not read too much into it. This is a device designed for low power, not for high logic speed necessarily. How fast is the clock specified to operate? Is the 8 ns delay a significant portion of the clock cycle?

Rick

s a

l

-darmstadt.de

Why would you imagine what the timing would be instead of looking at a device datasheet to see what the real specifications are?

Here's one example:

pdf

In the high speed mode Table 13, the data output will occur between

2.5 to 14nS after the clock.

Ed McGettigan

-- Xilinx Inc.

is a

all

..

tu-darmstadt.de

dt

d

I have some glue logic between the SD host and the SD card. And the Glue logic has to sort of mus some data from the FPGA itself and some taken from the SD card. I am operating at the low speed mode of the SD and the clock period is around 40ns. (25MHz) The issue is that the SD Card responds on the falling edge with a Clock to Output time of 8 ns and the data has to be sent much in prior to the next rising edge so that the Host can see it well.

So there is some clock skew added to this because the clock is also routed to the SD card via the FPGA. So there are route delays involved and I see my data from the SD card 8ns late. I can nullify clock skew by pushing the clock forward effectively making the input and output clock in synch which also meets data setup.

But I cannot eliminate data skews in the FPGA. So clock to output of

8ns is what concerned me...

re is a

e

fall

t...

k.tu-darmstadt.de

tadt

k.

/

ned

I can't quite visualize the timing based on your post so I'll have to take your word for it. But the FPGA is the part you have the most control over. I would think you could delay the sample timing in the FPGA to make this work. Do you have a higher speed clock in the FPGA? Can you use a clock manager to double the clock speed and generate a new sample edge with better timing?

Rick

here is a

ime

ct fall

ent...

sik.tu-darmstadt.de

mstadt

--

eck.

e

if

e

or/

by

igned

he

n

:) No I have a very low timing budget here. No PLLs, no Clock multipliers. One thing I could do is to generate a rise detect in the FPGA and make the duty cycle less so that the SD Card sees the falling edge earlier than what it would see if I had forwarded the incoming clock. So that is one place where I can control things. As far as FPGA route is concerned, I have optimized the paths and they delays internal to the FPGA are the max I can minimize. Most of them are uncontrollable, stuff like PAD delay, clock buffer delay, Span Mux delay