Output-to-input timing

Go To Last Post
12 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have an external memory-like device connected to ATMega128 (X=14.7456MHz), with 8-bit data connected to a port and a /RD signal "manually" bit-banged by an another port's pin.

As usually, I am trying to squeeze out the last cycle off the 'M128. The spec for the device says, /RD falling edge to data out valid is max 150ns. Now, considering the AVR input sync mechanism, which wastes half a cycle before the actual IN, it means, that after setting /RD low, I have to put 4 cycles (nop-s) to have at least a 60-70ns safety margin for the unknown delays on my board and on the way from pin to latches on chip (btw. my measurements indicate that the device's spec plays far on the safe side, with data out times as low as 50ns, so I am now quite happy with 2 NOPs - but I want to stay on the safe side).

I am somehow reluctant to burn cycles on idle, so I came up with the following construct:

   cbi   RD_PORT, RD_PIN_NR
   nop
   nop
   sbi   RD_PORT, RD_PIN_NR
   in    DATA_PIN

Any comments?

Thanks,

Jan Waclawek

[edit] PS. ... of course, with interrupts disabled momentarily ... [/edit]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The two NOPs plus the SBI will give you 4 clocks (which at 14.7456MHz is ~270ns), so there should be plenty of time. My only question would be do you want the rising edge of RD before or after you read the data, but that of course depends on the specs of the chip you are accessing.

Regards,
Steve A.

The Board helps those that help themselves.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Koshchi wrote:
The two NOPs plus the SBI will give you 4 clocks (which at 14.7456MHz is ~270ns), so there should be plenty of time. My only question would be do you want the rising edge of RD before or after you read the data, but that of course depends on the specs of the chip you are accessing.

The spec says, data hold is min 40 ns after RD going up.

But, regardless of this, due to the IN sync in AVR, the read value should be latched half-a-cycle BEFORE the RD being changed to 1 by the output, given the above code; so I am always on the safe side (if interrupts are disabled) - or do I overlook something?

JW

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Actually the input pin synchronizer is variable from 1/2 to 1.5 AVR cycles. When the AVR writes to an output pin, then reads the value it just wrote, its always 1 cycle because the timing is all from the same AVR internal clock. See the ATmega128 data sheet version 2467R–AVR–06/08 page 68 section Reading the Pin Value. The AVR write output to the pin happens immediately on the rising AVR clock edge, but the input sample isn't captured until the falling edge of the AVR clock and isn't clocked into the AVR PIN register until the next rising edge of the AVR clock (one clock delay).

Any external pin input signal must be stable for at least 1/2 AVR clock Tpd min. Only if this minimum time is perfectly synchronized in phase with the AVR clock falling to rising edge, the AVR will read this signal correctly. If the external pin input signal isn't perfectly synchronized in phase with the AVR clock falling to rising edge, the signal must be stable for up to 1.5 AVR clocks Tpd max.

Then you need to factor your external device propagation delays and signal setup times into meeting this AVR synchronizer requirement. If an AVR output pin is driving the external device, the external device has the first AVR rising clock edge (the AVR output pin change) up until the falling AVR clock edge to get a stable signal setup back to the AVR input pin, then the AVR will read this signal on the next rising AVR clock edge (1 full AVR clock cycle delay). If the external device can't get a stable signal back to the AVR within 1/2 AVR clock cycle, but within 1 AVR clock cycle, then it will take 2 AVR cycles.

If you have no synchronization to the AVR clock at all (i.e. you are not using an AVR output pin to drive the external device timing), then you need a stable AVR input signal for 1.5 AVR cycles to meet worst case timing for when you just barely miss the first falling AVR clock edge timing. Well, it doesn't actually have to be stable until the next falling edge, but that is almost a full AVR clock cycle away and in worst case timing that cycle is just wasted no matter what. Making it stable for at least 1.5 AVR clock cycles guarantees an unsynchronized input source works not matter what.

Don't forget all this theory assumes a perfectly stable AVR clock frequency with no jitter or uneven duty cycles.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Nice, but I somehow missed the answer to my question.
Given a memory-like device, with data setup from /RD falling edge max 150 ns, data connected to PORTA, /RD to PORTC.7, if I drive PORTC.7 low, insert 2 NOPs, then drive it high by SBI PORTC,7 and immediately *after* that read IN Rn, PORTA; all this on an ATM128 clocked at 14.7456MHz, will I safely read the data?

JW

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What does your calculator tell you?

14.7456MHz = 6.781684027777777778e-08 seconds per AVR clock cycle

1.5e-7 / 6.781684027777777778e-08 = 2.21184 AVR cycles during the 150 ns setup

Start with a rising AVR clock where RD goes low, then two nops later you issue an AVR port PIN read. This port PIN read critical falling AVR clock edge will now be 2.5 AVR cycles since the RD. These 2.5 AVR cycles take about 169.5 ns. You will have about 19.5 ns to spare. Remember, your maximum setup time is up against the minimum AVR timing, so don't expect faster than 150 ns average performance to save you from disaster all the time. Now I suggest you characterize your AVR clock accuracy over time/temperature/jitter/etc. and see if it really has a 50% duty cycle or not. Don't forget to look at wiring path propagation delay including velocity factor. A time period as small as 19.5 ns may not be as much as you think, especially if your AVR clock duty cycle isn't perfect. If it gets really tight, check the AVR output pin slew rate just in case it becomes a factor (if it does, you have already lost). If you end up right on the edge in any characterization or go over, then 3 nop instructions would be more reliable.

Unless I goofed somewhere, that is the way I see it.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, my calculation starts from the fact, that SBI is a 2-cycle instruction.

That gives two nops plus one-and-a-half instruction before the input sync latch clock which "belongs" to the subsequent IN instruction. And that's a comfortable 60-70ns of headroom after the 150ns setup time, which shall hopefully cover all the issues you listed above.

Hold of data after the read signal goes up should be not an issue, as this happens at the time when the input value is already latched (half a cycle after that).

My hopes were, that somebody has a first-hand experience with such a sequence of events. I don't really trust the AVR datasheets to the last letter, they - as any other mcu's datasheets - have been proved to be not completely correct too many times.

JW

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So, why do you believe the SBI will output the bit value in the very first of two cycles and not at the end of the second cycle? I have no way too see inside the chip, do you? Besides, how do you get a low falling edge RD signal with a SBI?

This is all internal processor operations. If you want better information than what is in the data sheet, you had better contact ATMEL technical support, if you choose to believe them. What did you expect, an AVR chip physic would answer?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am referring to the snippet of code I posted above: CBI on /RD pin (that produces the active=low evel for the device), then two NOPs, then SBI on /RD, and then IN of the DATA.

I was seeking comments and personal experience. I of course know this is not an official Atmel support.

Thanks for your thoughts.

JW

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I used an AT90CAN128 which is similar to the ATmega128, except it has a CLKO clock output pin and a little newer design with CAN added. Using a logic analyzer to observe toggling an output port pin using a mix of OUT, SBI and CBI instructions what I found is the OUT takes one AVR cycle to change the output pin. The SBI and CBI take two AVR cycles to change the output pin. All output pin changes were on positive AVR clock edges on CLKO (this appears to be the beginning of the next AVR instruction).

There was no pattern asymmetry in these one or two cycle times using mixed OUT, SBI and CBI instructions. It appears it takes two AVR cycles for SBI or CBI to change an output pin. If the output had changed in the first of the two SBI or CBI cycles, then the pattern would have been disrupted compared to preceding or following one cycle OUT instructions, but it always took two SBI or CBI cycles to change the output pin.

I correlated each instruction in my test program to the logic analyzer result. It looks like it operates predictably just like the data sheet suggests.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry, I was wrong in my earlier assessment. Look at Figure 32 Synchronization when Reading a Software Assigned Pin Value. The output pin goes positive after the out instruction (on the positive edge of at the start of the nop instruction). The positive clock makes the latch transparent. The negative clock edge closes the latch. Its the succeeding positive clock edge (the start of the AVR input instruction) that places the latch value in the PIN register.

Any input pin level change that changes during the AVR input instruction isn't seen by the AVR. The change must take place at least by 1/2 clock cycle into the AVR instruction before the AVR input instruction.

You will need 3 nop instructions minimum to meet your 150 ns maximum setup time.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I believe, the following timing applies for the snippet of code I posted above:

      ---.   ,---.   ,---.   ,---.   ,---.   ,---.   ,---.   ,---.   
CLK      |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   
         `---'   `---'   `---'   `---'   `---'   `---'   `---'   `---
         :       :       :       :       :       :       :       :
INSTR    |  CBI.......   |  NOP  |  NOP  |  SBI.......   |  IN   |
         :       :       :       :       :       :       :       :
      -------------------.       :       :       :       ,-----------
PORTC.7  :       :       |       :       :       :       |       :
= /RD    :       :       `_______________________________'       :
         :       :       :       :       :       :       :       :
         :       :       :       :       :       :       :       :
INPUT    :       :       :       :       :       ,---.   :       :
LATCH    :       :       :       :       :       |   |   :       :
(TRANSP.):       :       :       :       :    ---'   `---:       :
         :       :       :       :       :       :   ^   :       :
INPUT    :       :       :       :       :       :   :   ,---    :
LATCH    :       :       :       :       :       :   :   ^       :
(CLKED)  :       :       :       :       :       :   : --'       :
         :       :       :       :       :       :   :   :       :
                         :                           :   
                         :                           :   
                         :                  END OF DATA INPUT
                         :                           :
                         :<------------------------->:
                           3.5 x 67ns (1/14.7456MHz) = 234ns

Comments?

Thanks,

Jan