Shop OBEX P1 Docs P2 Docs Learn Events
One more clock delay on next silicon inputs - Page 2 — Parallax Forums

One more clock delay on next silicon inputs

2

Comments

  • evanhevanh Posts: 15,091
    edited 2019-02-15 06:44
    Chip,
    I've covered this before. The FPGA I/O buffer pair takes a total of 2.5 nanoseconds.

    PS: And I think that time includes the routing in the ring circuit I put together. Maybe not.
  • jmgjmg Posts: 15,140
    Cluso99 wrote: »
    Ran again for P2D2...

    24 MHz - w=3 (w=2 fails)
    200MHz - w=4 (w=3 varies per pin so is on the edge)
    300MHz - w=5 (w=4 varies per pin so is on the edge)

    Do we know if that is solely on IN or OUT side, or some combinations of both ?

    If there are per-pin differences, it likely follows that there are per-temperature differences too.

    If marginal cases on the OUT path, could cause jitter at some MHz/Temperature combinations - if this is mostly in the PAD IO, this may also effect Smart Pin generation modes, as well as streamer, in addition to normal IO opcodes.

    Maybe this is another contributor to the VGA noise seen ?
  • jmgjmg Posts: 15,140
    cgracey wrote: »
    .. An I/O pin is big and slow compared to internal signals... Just to implement ESD protection on the I/O pad, you incurr 1000x the capacitive loading of the core-side signals.

    Just how slow is the IO path, to Verilog Logic, & how does that vary with temperature (Which I guess includes all Smart Pin IO and Streamer and opcodes ?)

    I guess that means another clock delay could appear due to capacitive loading.
  • evanhevanh Posts: 15,091
    edited 2019-02-15 07:30
    Hmm, I've just done a new set of runs and got really outrageously bad results on the FPGA. It might be the first time I've done a large sweep and compared them though.

    The lower 40 pins are acting consistently as per all previous statements, but above that things get weird. In some tests they are slow while in others they are crazy fast. There can be 3 clocks difference from the expected outcome.

    PS: Even at 20 MHz the pins above #39 are not conforming.
  • evanhevanh Posts: 15,091
    eg: 20 MHz with I/O clocking enabled. WRPIN ##%100<<14
    w   . .50 . . . .40 . . . .30 . . . .20 . . . .10 . . . . 0
    0   0000000000000000000000000000000000000000000000000000000
    1   0000000000000000000000000000000000000000000000000000000
    2   0000000000000000000000000000000000000000000000000000000
    3   0000000000000000000000000000000000000000000000000000000
    4   1111111111111110000000000000000000000000000000000000000
    5   1111111111111110000000000000000000000000000000000000000
    6   1111111111111111111111111111111111111111111111111111111
    7   1111111111111111111111111111111111111111111111111111111
    
  • evanhevanh Posts: 15,091
    And the opposite effect occurs when redirecting OUT back as an input. WRPIN ##%0100<<28
    w   . .50 . . . .40 . . . .30 . . . .20 . . . .10 . . . . 0
    0   0000000000000000000000000000000000000000000000000000000
    1   0000000000000000000000000000000000000000000000000000000
    2   0000000000000001111111111111111111111111111111111111111
    3   0000000000000001111111111111111111111111111111111111111
    4   1111111111111111111111111111111111111111111111111111111
    5   1111111111111111111111111111111111111111111111111111111
    6   1111111111111111111111111111111111111111111111111111111
    7   1111111111111111111111111111111111111111111111111111111
    
  • jmgjmg Posts: 15,140
    evanh wrote: »
    eg: 20 MHz with I/O clocking enabled. WRPIN ##%100<<14

    Is that the latest FPGA, or the 'silicon-matching' FPGA ?
    The 2 sysclk quata seems strange, (even more at 20MHz) as you would expect one more clock to pass any threshold ?
  • evanhevanh Posts: 15,091
    latest v33j. What has been sent in for the respin.
  • evanhevanh Posts: 15,091
    Okay, dropping back to v32i (equivalent to P2ES) I'm getting our regular behaviour on all pins again. So this one is a new problem with v33j.


    FPGA testing with v32i image and 80 MHz, Clocked I/O:
    w   . .50 . . . .40 . . . .30 . . . .20 . . . .10 . . . . 0
    0   0000000000000000000000000000000000000000000000000000000
    1   0000000000000000000000000000000000000000000000000000000
    2   0000000000000000000000000000000000000000000000000000000
    3   0000000000000000000000000000000000000000000000000000000
    4   0000000000000000000000000000000000000000000000000000000
    5   1111111111111011100000011111111111111111111110111110000
    6   1111111111111111111111111111111111111111111111111111111
    7   1111111111111111111111111111111111111111111111111111111
    

    FPGA testing with v32i image and 80 MHz, Unclocked I/O:
    w   . .50 . . . .40 . . . .30 . . . .20 . . . .10 . . . . 0
    0   0000000000000000000000000000000000000000000000000000000
    1   0000000000000000000000000000000000000000000000000000000
    2   0000000000000000000000000000000000000000000000000000000
    3   1111111011111011100000011111111111111111111110111110000
    4   1111111111111111111111111111111111111111111111111111111
    5   1111111111111111111111111111111111111111111111111111111
    6   1111111111111111111111111111111111111111111111111111111
    7   1111111111111111111111111111111111111111111111111111111
    

    FPGA testing with v32i image and 80 MHz, OUT fed back:
    w   . .50 . . . .40 . . . .30 . . . .20 . . . .10 . . . . 0
    0   0000000000000000000000000000000000000000000000000000000
    1   0000000000000000000000000000000000000000000000000000000
    2   1111111111111111111111111111111111111111111111111111111
    3   1111111111111111111111111111111111111111111111111111111
    4   1111111111111111111111111111111111111111111111111111111
    5   1111111111111111111111111111111111111111111111111111111
    6   1111111111111111111111111111111111111111111111111111111
    7   1111111111111111111111111111111111111111111111111111111
    
  • TubularTubular Posts: 4,620
    edited 2019-02-15 08:25
    Any difference from different cogs?

    Are the pins near the borders affected by temperature?
  • cgraceycgracey Posts: 14,131
    jmg wrote: »
    cgracey wrote: »
    .. An I/O pin is big and slow compared to internal signals... Just to implement ESD protection on the I/O pad, you incurr 1000x the capacitive loading of the core-side signals.

    Just how slow is the IO path, to Verilog Logic, & how does that vary with temperature (Which I guess includes all Smart Pin IO and Streamer and opcodes ?)

    I guess that means another clock delay could appear due to capacitive loading.

    Yes, not just capacitive loading, but propagation delay within the 3.3V circuitry eats time. Maybe 3ns each way.
  • evanhevanh Posts: 15,091
    Here's one that is even odder: v33j loaded back in FPGA, 80 MHz, OUT fed back.
    w   . .50 . . . .40 . . . .30 . . . .20 . . . .10 . . . . 0
    0   0000000000000000000000000000000000000000000000000000000
    1   0000000000000000000000000000000000000000000000000000000
    2   0000000000000001111111111111111111111111111111111111111
    3   0000000000000001111111111111111111111111111111111111111
    4   1111010000100001111111111111111111111111111111111111111
    5   1111111111111111111111111111111111111111111111111111111
    6   1111111111111111111111111111111111111111111111111111111
    7   1111111111111111111111111111111111111111111111111111111
    

    Note how the >39 pins are erratic. This hasn't occurred with any other combination of OUT fed back.

  • cgraceycgracey Posts: 14,131
    evanh wrote: »
    Here's one that is even odder: v33j loaded back in FPGA, 80 MHz, OUT fed back.
    w   . .50 . . . .40 . . . .30 . . . .20 . . . .10 . . . . 0
    0   0000000000000000000000000000000000000000000000000000000
    1   0000000000000000000000000000000000000000000000000000000
    2   0000000000000001111111111111111111111111111111111111111
    3   0000000000000001111111111111111111111111111111111111111
    4   1111010000100001111111111111111111111111111111111111111
    5   1111111111111111111111111111111111111111111111111111111
    6   1111111111111111111111111111111111111111111111111111111
    7   1111111111111111111111111111111111111111111111111111111
    

    Note how the >39 pins are erratic. This hasn't occurred with any other combination of OUT fed back.

    Evanh, I don't think these things are anything to get concerned about. The FPGA compiles differently each time, and because I didn't make any timing constraints, pin timing is going to vary with each compile.
  • evanhevanh Posts: 15,091
    Okay, ignoring that there is erratic performance at 80 MHz, the additional 2-clock difference can't be assigned to lose timing. 20 MHz showed the same 2 clocks but without the erratic 3rd clock.

    There's gotta be something new wrong with v33j.
  • cgraceycgracey Posts: 14,131
    evanh wrote: »
    Okay, ignoring that there is erratic performance at 80 MHz, the additional 2-clock difference can't be assigned to lose timing. 20 MHz showed the same 2 clocks but without the erratic 3rd clock.

    There's gotta be something new wrong with v33j.

    Does what you are seeing make sense if you consider these two things:

    1) an extra flop exists now between the physical pin and the smart pin circuitry
    2) paths are unconstrained, so there will be timing differences among pins
  • evanhevanh Posts: 15,091
    That last table, "OUT fed back", is by-passing the physical pin drivers. So, no driver slew time, and no input buffering.

    It also by-passes that extra flop because the number of clocks measured is the same for both v32 and v33.

  • evanhevanh Posts: 15,091
    edited 2019-02-15 10:35
    Pin mode is AAAA == %0100


    EDIT: Here's the testing source
    pinping
    		hubset  #$ff            'change to 80 MHz sysclock
    
    		loc	pa, #\@diag11
    		call	#puts
    
    		mov	count, #0
    .loop
    		call	#allpins
    		cmp	count, #7	wc	'C = borrow of (D - S)
    if_c		ijnz	count, #.loop
    
    		jmp	#$
    
    
    
    allpins
    		mov	pb, count
    		add	pb, #"0"
    		call	#putch
    		call	#putsp
    		mov	pin, #54		'pins 55-57 are pushbuttons on P123 board.
    .loop
    '		wrpin	##%0, pin		'disable I/O clocking (unregistered I/O)
    '		wrpin	##(%100<<14), pin	'enable I/O clocking (registered I/O)
    		wrpin	##(%0100<<28), pin	'select OUT as input source
    '		wrpin	##(%0100<<28 | %100<<14), pin
    
    		waitx	#20
    		drvl	pin
    		waitx	#50
    		outh	pin
    		waitx	count
    
    		testp	pin		wz
    if_nz		mov	pb, #"0"
    if_z		mov	pb, #"1"
    		call	#putch
    
    		djnf	pin, #.loop
    
    		call	#putnl
    		ret			wcz
    
    
    diag11		byte	"w   . .50 . . . .40 . . . .30 . . . .20 . . . .10 . . . . 0",13,10,0
    
  • evanhevanh Posts: 15,091
    edited 2019-02-15 11:32
    Here's scope snap of above 80 MHz test of "OUT fed back".

    I've zoomed in on two of the pulses of pin42. And added an extra DRVL #38 and OUTH #38 to compare timing. Orange trace is pin38.

    pin_lat0027.PNG

    Note the equal sized 200 ns pulse lengths for both traces and the single instruction 25 ns phase difference. This is correct of course. But the software testing shows at least an extra two clocks, or 25 ns, for pin42 (green trace). And at 20 MHz it's still two extra clocks, or 100 ns.

    So output timing looks good. Not so for inputs.
    		wrpin	##(%0100<<28), pin	'select OUT as input source
    		cmp	pin, #42	wz
    		waitx	#10
    if_z		drvl	#38
    		drvl	pin
    		waitx	#10
    if_z		outh	#38
    		outh	pin
    		waitx	count
    		testp	pin		wz
    

    EDIT: Detailed phase difference.
    640 x 480 - 10K
  • evanhevanh Posts: 15,091
    edited 2019-02-15 11:37
    cgracey wrote: »
    Does what you are seeing make sense if you consider these two things:

    1) an extra flop exists now between the physical pin and the smart pin circuitry
    2) paths are unconstrained, so there will be timing differences among pins
    So my answer is no.

    PS: Just to reiterate. I'm now chasing a new problem that has shown only in v33j. It's not the jitteriness I'm looking at here. Although I'd dearly love them to be related because they are both an input problem.
  • evanhevanh Posts: 15,091
    To compare with the earlier v32i graphs, here's all six v33j graphs with extra pins up to #61. It's notable that for the four pins above the push buttons, the behaviour reverts to same as pins below #40.

    v33j image in FPGA at 20 MHz, Clocked I/O:
    w   60 . . . .50 . . . .40 . . . .30 . . . .20 . . . .10 . . . . 0
    0   00001110000000000000000000000000000000000000000000000000000000
    1   00001110000000000000000000000000000000000000000000000000000000
    2   00001110000000000000000000000000000000000000000000000000000000
    3   00001110000000000000000000000000000000000000000000000000000000
    4   00001111111111111111110000000000000000000000000000000000000000
    5   00001111111111111111110000000000000000000000000000000000000000
    6   11111111111111111111111111111111111111111111111111111111111111
    7   11111111111111111111111111111111111111111111111111111111111111
    

    v33j image in FPGA at 20 MHz, Unclocked I/O:
    w   60 . . . .50 . . . .40 . . . .30 . . . .20 . . . .10 . . . . 0
    0   00001110000000000000000000000000000000000000000000000000000000
    1   00001110000000000000000000000000000000000000000000000000000000
    2   00001110000000000000000000000000000000000000000000000000000000
    3   00001110000000000000000000000000000000000000000000000000000000
    4   11111111111111111111111111111111111111111111111111111111111111
    5   11111111111111111111111111111111111111111111111111111111111111
    6   11111111111111111111111111111111111111111111111111111111111111
    7   11111111111111111111111111111111111111111111111111111111111111
    

    v33j image in FPGA at 20 MHz, OUT fed back:
    w   60 . . . .50 . . . .40 . . . .30 . . . .20 . . . .10 . . . . 0
    0   00000010000000000000000000000000000000000000000000000000000000
    1   00000010000000000000000000000000000000000000000000000000000000
    2   11111110000000000000001111111111111111111111111111111111111111
    3   11111110000000000000001111111111111111111111111111111111111111
    4   11111111111111111111111111111111111111111111111111111111111111
    5   11111111111111111111111111111111111111111111111111111111111111
    6   11111111111111111111111111111111111111111111111111111111111111
    7   11111111111111111111111111111111111111111111111111111111111111
    

    v33j image in FPGA at 80 MHz, Clocked I/O:
    w   60 . . . .50 . . . .40 . . . .30 . . . .20 . . . .10 . . . . 0
    0   00001110000000000000000000000000000000000000000000000000000000
    1   00001110000000000000000000000000000000000000000000000000000000
    2   00001110000000000000000000000000000000000000000000000000000000
    3   00001110000000000000000000000000000000000000000000000000000000
    4   00001111111010000100000000000000000000000000000000000000000000
    5   00001111111111111111110000000000000000000000000000000000000000
    6   00101111111111111111110000000011111111111111111111110111110000
    7   11111111111111111111111111111111111111111111111111111111111111
    

    v33j image in FPGA at 80 MHz, Unclocked I/O:
    w   60 . . . .50 . . . .40 . . . .30 . . . .20 . . . .10 . . . . 0
    0   00001110000000000000000000000000000000000000000000000000000000
    1   00001110000000000000000000000000000000000000000000000000000000
    2   00001110000000000000000000000000000000000000000000000000000000
    3   00001110000000000000000000000000000000000000000000000000000000
    4   00101111111010000000000000000011111111111101001111110111110000
    5   11111111111111111111111111111111111111111111111111111111111111
    6   11111111111111111111111111111111111111111111111111111111111111
    7   11111111111111111111111111111111111111111111111111111111111111
    

    v33j image in FPGA at 80 MHz, OUT fed back:
    w   60 . . . .50 . . . .40 . . . .30 . . . .20 . . . .10 . . . . 0
    0   00000010000000000000000000000000000000000000000000000000000000
    1   00000010000000000000000000000000000000000000000000000000000000
    2   11111110000000000000001111111111111111111111111111111111111111
    3   11111110000000000000001111111111111111111111111111111111111111
    4   11111111111010000100001111111111111111111111111111111111111111
    5   11111111111111111111111111111111111111111111111111111111111111
    6   11111111111111111111111111111111111111111111111111111111111111
    7   11111111111111111111111111111111111111111111111111111111111111
    
  • evanhevanh Posts: 15,091
    edited 2019-02-16 08:13
    PS: I just tried 5 MHz sysclock, HUBSET #$0F, and still got identical graphs as per 20 MHz.

    And I confirmed it really is 5 MHz. 400 ns per instruction. 3200 ns pulse length.


    EDIT: Added source
  • cgraceycgracey Posts: 14,131
    edited 2019-02-16 10:52
    Thanks to Evanh for going over this problem with me on a text chat, where I ran his code to see these strange results.

    This made no sense, but after an hour of running his tests and chatting about the strange results, I realized that I had eliminated some smart pins on the Prop123-A9 and BeMicro-A9 images, in order to get them to fit into the FPGA. So, mystery solved! No problem, after all, thank goodness. ON Semi has been carrying forward with the current design and they are deep into place and route, already.

    Thanks, Evanh, for noticing this strangeness. This could have been a huge bug.
  • evanhevanh Posts: 15,091
    It's funny. Looking back, it is obvious now that that group of pins never moved their timing when adjusting the pin config. I was totally focused on the relative relationship from expected.

    It certainly is good it was just the FPGA only.
  • evanhevanh Posts: 15,091
    edited 2019-02-16 11:17
    As for the original concern with uncertainty I guess must be as Chip has been saying - the speed of the physical pin turn around. It is clearly completely speed dependant and, for the functioning smartpins, it doesn't show up when OUT feedback is config'd; which bypasses the physical pin drivers and buffers. Or at least it doesn't show up in the FPGA.

    I'll have my replacement P2ES EVAL board in a couple of days. I'll test that overclocked.
  • @evanh
    I know it's a bit late, but maybe this migt have helped. :)
    https://forums.parallax.com/discussion/164621/detecting-avualable-smart-pins-on-fpga
  • evanhevanh Posts: 15,091
    Nice, thanks. Yeah, unlikely to be needed from now but I'll add it to my regular init routine anyway.
  • evanhevanh Posts: 15,091
    edited 2019-02-17 01:17
    Here's a new output.
    Total smartpins = 48   1111111100000000000000001111111111111111111111111111111111111111
    w   60 . . . .50 . . . .40 . . . .30 . . . .20 . . . .10 . . . . 0
    0   00000010000000000000000000000000000000000000000000000000000000
    1   00000010000000000000000000000000000000000000000000000000000000
    2   11111110000000000000001111111111111111111111111111111111111111
    3   11111110000000000000001111111111111111111111111111111111111111
    4   11111111111111111111111111111111111111111111111111111111111111
    5   11111111111111111111111111111111111111111111111111111111111111
    6   11111111111111111111111111111111111111111111111111111111111111
    7   11111111111111111111111111111111111111111111111111111111111111
    

    And updated smartpin checking source. Instructions have changed in two years!
    		mov	available, #0
    		mov	smart_pin, #63			'test all 64 pins
    .searchloop
    		wrpin	#%11_0, smart_pin		'long repository mode
    		dirh	smart_pin
    
    		mov	pattern, ##$c0ffee00
    		add	pattern, smart_pin		'unique pattern
    		wxpin	pattern, smart_pin		'write long to smart pin
    		shl	mask_lsb, #1		wc	'build valid smart pin mask
    		rcl	mask_msb, #1
    		rdpin	response, smart_pin		'get long from smart pin repository
    		cmp	response, pattern	wz	'valid response?
    	if_e	add	available, #1
    	if_e	bith	mask_lsb, #0
    
    		dirl	smart_pin
    		wrpin	#0, smart_pin			'disable smart pin
    		djnf	smart_pin, #.searchloop		'next smart pin
    

    EDIT: Changed search order to use a DJNF instead of REP + ADD
  • evanhevanh Posts: 15,091
    evanh wrote: »
    As for the original concern with uncertainty I guess must be as Chip has been saying - the speed of the physical pin turn around. It is clearly completely speed dependant and, for the functioning smartpins, it doesn't show up when OUT feedback is config'd; which bypasses the physical pin drivers and buffers. Or at least it doesn't show up in the FPGA.

    I'll have my replacement P2ES EVAL board in a couple of days. I'll test that overclocked.

    Right, done some tests with the replacement P2ES EVAL board and yep, it's amazing how far this effect can go. Eg: The long tracks on the board for the uSD and flash chip are slowing down the upper few pins even more than the rest. At 350 MHz needs w=6 for those few. Or, with clocked I/O, w=8 is required. And those are without the extra flop that is added in the respin.

    And again, OUT fed back, even at 350 MHz, is clean at w=2.

  • evanhevanh Posts: 15,091
    An aside: There is notable extra current draw with I/O clocking. Here's a table for my 5 volt bench supply:
           UnClkd  Clocked
     MHz |    mA     mA
    =====|==============
      10 |    57     58
     100 |   170    185
     200 |   290    320
     300 |   406    456
     350 |   464    520
    
    
  • Thats an interesting observation, seems like a lot extra
Sign In or Register to comment.