If on a bidirectional bus, if there is a strong pull up and there is a device which is drives the line low, can we reduce the fall time substantially, if we reduce the pull up on the lines?
Or is it that the low overrides the pull up and does not affect fall time at all?
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.
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?
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
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?
:) 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
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.