Shop OBEX P1 Docs P2 Docs Learn Events
Prop2 FPGA files!!! - Updated 2 June 2018 - Final Version 32i - Page 156 — Parallax Forums

Prop2 FPGA files!!! - Updated 2 June 2018 - Final Version 32i

1154156158159160

Comments

  • evanhevanh Posts: 15,126
    Here's the source code:
    		andn	dira, #smartmask		'disable smartpins
    		wrpin	##(1<<24 | %01_11100_0), #tpin		'sync serial mode, Bin = tpin+1
    		wrpin	#%01_00101_0, #tpin+1			'transion mode, used for sync clock
    		wrpin	##(1<<16 | 1<<7), #tpin+2		'OTHER inverted, used for comparing clocked I/O
    		wxpin	#7, #tpin				'8 bits for serial output
    		wxpin	#10, #tpin+1				'1 MHz serial clock on 20 MHz sysclock
    		or	dira, #smartmask		'enable smartpins
    .loop
    		wypin	#$55, #tpin			'regular toggling of the serial pin
    		wypin	#4, #tpin+1			'4 transitions: 2 bits shifted out on serial pin
    		waitx	#100				'give hardware some time to action
    		jmp	#.loop				'repeat, refilling the serial buffer if empty
    
  • jmgjmg Posts: 15,140
    evanh wrote: »
    The reaffirming issue here is that with the latest v33i FPGA at 80 MHz it still leaps another clock the same way as my much older measurements using software and GETCT.

    What exactly does 'it still leaps another clock' mean ?
    Do you mean the delay varies and jitters, or that it is a fixed delay, but with an unexpected added sysclk ?


  • cgraceycgracey Posts: 14,133
    I talked to Wendy at ON Semi today and we discussed establishing timing constraints for all of the asynchronous input and output signals. We intend to bind their timing together so that the pins all behave very similarly. We'll make them go as fast as possible, of course.
  • evanhevanh Posts: 15,126
    Cool.
  • jmgjmg Posts: 15,140
    cgracey wrote: »
    I talked to Wendy at ON Semi today and we discussed establishing timing constraints for all of the asynchronous input and output signals. We intend to bind their timing together so that the pins all behave very similarly. We'll make them go as fast as possible, of course.

    Did Clock gating make the cut in the revisions ?
    What about ClkOut = SysCLK option, for the streamer ?
  • cgraceycgracey Posts: 14,133
    jmg wrote: »
    cgracey wrote: »
    I talked to Wendy at ON Semi today and we discussed establishing timing constraints for all of the asynchronous input and output signals. We intend to bind their timing together so that the pins all behave very similarly. We'll make them go as fast as possible, of course.

    Did Clock gating make the cut in the revisions ?
    What about ClkOut = SysCLK option, for the streamer ?

    Last I heard from Wendy, almost 2,000 clock gates had been synthesized into the design. This should result in a huge power savings. The current silicon has no clock gates.

    I don't think we are going to get a full-speed clock output, unless the occasion arises for resynthesis. In getting everything else together, I did not incorporate this feature into the current verilog. If we need to resynthesize, there will be opportunity, but things are pushing fast now towards completion. At the moment, I'm simulating the PLL to discover what can be done to improve it.
  • jmgjmg Posts: 15,140
    edited 2019-02-05 18:43
    cgracey wrote: »
    .... At the moment, I'm simulating the PLL to discover what can be done to improve it.

    Did you simulate yet, the XIN to PFD path delays, with varying Xtal amplitudes ?

    Measurements show ten+ ns of temperature dependent skew occurring between external clock and final PLL.
    That's bad for a couple of reasons :
    a) It means external master clock designs will not hold phase, which users will expect.
    b) It means the PFD sense point, can sweep across a sysclk boundary in some temperature zones.
    That boundary crossing will certainly worsen jitter, and it fits the symptoms observed of jitter being temperature zone related.

    Ideally, the Counter to PFD and Xtal to PFD paths should match in delays, and delay variations. That reduces phase walking to well under a Sysclk.
    Xtal paths may be somewhat Xtal amplitude dependent, and a schmitt buffer may make that delay more controlled and fixed.
  • Cluso99Cluso99 Posts: 18,066
    Chip & others,
    I am seeing what appears to be multiple powerup restarts when plugging in to USB for power.

    Can you (or others) possibly check this on a scope by looking at the pullup sampling on a scope to confirm this please?

    There is no brownout protection on the P2. Maybe we need some form of powerup delay in either hardware or ROM software delay to prevent this ???
  • jmgjmg Posts: 15,140
    Cluso99 wrote: »
    Chip & others,
    I am seeing what appears to be multiple powerup restarts when plugging in to USB for power.

    Can you (or others) possibly check this on a scope by looking at the pullup sampling on a scope to confirm this please?

    There is no brownout protection on the P2. Maybe we need some form of powerup delay in either hardware or ROM software delay to prevent this ???

    On P2-Eval there are 2 Reset generators, joined to the P2 Reset via the OD DIPSw.
    I think the next P2D2 was getting reset managed by the EFM8 MCU, not sure how that works around 1V ramping ?

    It's certainly doing a merry dance here on Win10, when you first plug in !!
    1478 x 793 - 71K
    1478 x 793 - 60K
  • jmgjmg Posts: 15,140
    hmm. seems to all be in FTDI's driver ?!

    Here is Silabs CP2102N and FTDI FT231X on other boards....
    Interesting they both have 6 hi pulses, but the P2 board shows some tristate action in there, due to different pullups/loads.
    Appears pullup is always strong, but pulldown can sometime be weaker, as the driver shuffles about ?

    Takes ~4.3 seconds to finally settle, not much a ROM can do about that.
    Maybe there is a means to kill that dance ?
    1478 x 793 - 50K
    1478 x 793 - 63K
  • jmgjmg Posts: 15,140
    Ahh, seems to settle down, if I dig deep enough...

    FTDI Advanced Driver Options AN_107 Application Note AN_107 Version 2.53
    "Note that if the "Serial Enumerator" option in the property page is selected, then the enumeration sequence causes the modem control signals to change at startup.
    So if it is necessary to select "Disable Modem Ctrl At Startup", then it is likely that "Serial Enumerator" should be unchecked in the property page."

  • Cluso99Cluso99 Posts: 18,066
    Thanks jmg.
    This is showing what I am seeing with the LED flashing program being booted from SD.

    Are you able to do the same test with DTR disconnected, or just have power connected?
  • jmgjmg Posts: 15,140
    Cluso99 wrote: »
    Are you able to do the same test with DTR disconnected, or just have power connected?

    This is the Power Up captures, using the other USB connector. (so no DTR applied, just voltages)

    Interesting, the 3v3 struggles and is not monotonic, which would make a reset generator quite important.
    1V8 has no such issues ?
    1478 x 793 - 53K
    1478 x 793 - 53K
    1478 x 793 - 55K
    1478 x 793 - 54K
  • Cluso99Cluso99 Posts: 18,066
    edited 2019-02-06 00:56
    Thanks.

    Yes, that 3v3 is not good. I haven't looked closely, but wasn't there an alternative non-switcher 3v3 on the P2-EVAL? If so, is this any better?

    At least I now know why I am seeing the multiple reboots which was causing me concern with the SD driver.

    I have another question. Could you scope for me the following please?
    How long it takes for a pullup test with 5K, 10K and 15K to return high after being pulsed low. (or 4K7, 10K, 14K7 or 15K)
    How long it takes for a pulldown test with 5K, 10K and 15K to return low after being pulsed high.
    Don't set a crystal frequency - ie use rcfast.
    Here is sample code
            orgh    0
            org     0
            drvl    #0                        ' P0 with pullup
            drvh    #1                        ' P1 with pulldown
            waitx   #30                       ' ~1us
            fltl    #0
            flth    #1
            jmp     #$
    

    Background: I had left a 4K7 pulldown on P58 and discovered it was interfering with my SD read reply. Forgot I had a resistor left on this pin from some testing and I went looking for an SD boot bug. It is obviously slowing the response and I wanted to see how much it slows the prop. Of course it's the SD cards DO pin driving the line.
  • jmgjmg Posts: 15,140
    Cluso99 wrote: »
    ... wasn't there an alternative non-switcher 3v3 on the P2-EVAL? If so, is this any better?

    Yes, that's the plot label ending with 3v3LDO, powering the PLL pins in this case.

  • evanhevanh Posts: 15,126
    The power up looks fine. It comes out of reset after the power settles every time.
  • Cluso99Cluso99 Posts: 18,066
    jmg,
    I updated my previous post with some more questions. Could you take a look please?
  • Cluso99 wrote: »
    Thanks.
    I have another question. Could you scope for me the following please?
    How long it takes for a pullup test with 5K, 10K and 15K to return high after being pulsed low. (or 4K7, 10K, 14K7 or 15K)
    How long it takes for a pulldown test with 5K, 10K and 15K to return low after being pulsed high.
    Don't set a crystal frequency - ie use rcfast.
    Here is sample code
            orgh    0
            org     0
            drvl    #0                        ' P0 with pullup
            drvh    #1                        ' P1 with pulldown
            waitx   #30                       ' ~1us
            fltl    #0
            flth    #1
            jmp     #$
    

    Background: I had left a 4K7 pulldown on P58 and discovered it was interfering with my SD read reply. Forgot I had a resistor left on this pin from some testing and I went looking for an SD boot bug. It is obviously slowing the response and I wanted to see how much it slows the prop. Of course it's the SD cards DO pin driving the line.

    Just be careful here because the Pin number might matter - when we did previously scope caps of this the pins that were also used for Onsemi JTAG checking seemed to have additional loading. These were low pins less than P15 from memory, with a few gaps in amongst them
  • Cluso99Cluso99 Posts: 18,066
    edited 2019-02-07 03:03
    @jmg
    Are you able to scope pins with 4K7 or 5K ,10K and 14.7K or 15K pullup and pulldown please. P56 & P57 would be nice but not mandatory. I need to know how long it takes for the pin to return to the pulled up or down state.

    I noticed a problem when P58 (SD DO) had a 4K7 pulldown.
  • evanhevanh Posts: 15,126
    edited 2019-02-07 06:41
    I've been testing with just software timing on the P123 board and getting some pretty low figures around 250-500 ns even for a 15k resistor.

    PS: Pins 55 to 57 don't work though, they are held high by something. Possibly Chip hasn't got everything configured right for the 33i FPGA files.
  • cgraceycgracey Posts: 14,133
    evanh wrote: »
    I've been testing with just software timing on the P123 board and getting some pretty low figures around 250-500 ns even for a 15k resistor.

    PS: Pins 55 to 57 don't work though, they are held high by something. Possibly Chip hasn't got everything configured right for the 33i FPGA files.

    I think those pins, 55 through 57, read three of the push buttons.
  • evanhevanh Posts: 15,126
    Oh, someone told me that in the past too.
  • evanhevanh Posts: 15,126
    edited 2019-02-07 06:56
    Hmm, at slower sysclock rates the time taken seems to be longer. I'm getting as high as 800 ns at 20 MHz. This is all with the FPGA though.
  • evanhevanh Posts: 15,126
    edited 2019-02-07 08:29
    Ah, just adding the scope probes on doubles the software measurements!

    EDIT: Okay, I'm seeing a negative glitch on the pulldown when doing a DIRL tristate after DRVH+WAITX. Discharge curve starts at about 2.5 volts instead of 3.3. EDIT2: Doesn't seem to have a great impact on the measurement though.
  • Cluso99Cluso99 Posts: 18,066
    I am really interested to see the results graphed on either P2D2 or P2-EVAL because I was getting errors when reading the SD card when there was a 4K7 pulldown on P58 (the DO output from the SD card) which I had forgotten I had added a while ago. Everything was fine on the ROM SD code, but not when I loaded it manually (slight timing difference in old code).

    Never-the-less, I wanted to see the effects on this on a scope to ensure that everything is within parameters for the ROM code.
  • evanhevanh Posts: 15,126
    edited 2019-02-07 08:30
    Here's a list of combinations using 15kR resistor on pin 22 on P123 board:
    			20 MHz		80 MHz
    --------------------------------------------------
    pull-up, no probe	12 (600 ns)	19 (238 ns)
    pull-down, no probe	11 (550 ns)	16 (200 ns)
    pull-up, probe		14 (700 ns)	28 (350 ns)
    pull-down, probe	16 (800 ns)	34 (425 ns)
    
    And the basic measuring source code used:
    		wrpin	##1<<16, tpin		'turn off any smartpin mode and enable clocked I/O
    		drvl	#tpin			'lower the pull up
    		waitx	sec			'set for 1 microsecond
    		setse1	#(1<<6 | tpin)		'event set to rising edge of tpin
    
    		dirl	#tpin			'tristate
    		getct	tickstart		'start measuring
    		waitse1
    		getct	pa			'stop measuring
    
    		sub	pa, tickstart
    		call	#itod			'report
    
  • Cluso99Cluso99 Posts: 18,066
    evan,
    i am interested is seeing the graph.
    I can do the pin reading and ive done it before.
  • evanhevanh Posts: 15,126
    edited 2019-02-07 10:00
    They're pretty ordinary except for the tiny glitch on the two pull-down snaps.

    EDIT: I guess the oddity is that, because of the glitch, the down curve crosses 1.65 volts in half the time of the up curve but this doesn't show up in the software measurement.
    640 x 480 - 7K
    640 x 480 - 7K
    640 x 480 - 7K
    640 x 480 - 7K
  • Cluso99Cluso99 Posts: 18,066
    Now if someone could do that on a P2-ES chip (P2D2 or P2-EVAL board) with three different resistor values please :)
Sign In or Register to comment.