One more clock delay on next silicon inputs

cgraceycgracey Posts: 10,864
edited 2019-02-07 - 02:47:59 in Propeller 2
Wendy at ON Semi noticed there's a potential metastability problem with the way we are registering pin inputs. We added another set of flops for the incoming pin signals. This means that there is now one more clock delay on all inputs from pins. I will make new FPGA files soon so we can confirm this doesn't cause any problems with existing code, especially what will go into ROM.
«13

Comments

  • Cluso99Cluso99 Posts: 14,594
    edited 2019-02-07 - 04:41:16
    Thanks Chip. So we will see pins from another older clock ie prior clock.
    IIRC currently we see 1 clock prior to the start of a testp and 2 clocks prior for ina/inb, so that will now be 2 & 3 respectively.
    IIRC outputs are 3 clocks after the instruction completion. This will remain the same?
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • Cluso99Cluso99 Posts: 14,594
    edited 2019-02-14 - 03:03:33
    Here is the in/out pin timing...
    Postedit 14 Feb 2019 - fix
    Timing%20Diagram%20-%20In-Out.jpg
    466 x 456 - 31K
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • Wouldn't that diagram be the other way round, rather than whats labelled?
  • Tubular wrote: »
    Wouldn't that diagram be the other way round, rather than whats labelled?
    ??? please explain :smiley:
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • The diagram shows that the new "Respin P2" will have testp and ina/b taking 1 clock *less* than the current P2-ES
  • Cluso99Cluso99 Posts: 14,594
    edited 2019-02-14 - 03:04:26
    Oh! I need to swap respin with es.
    Ill do it later :(
    fixed 14 Feb 2019
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • Cluso99Cluso99 Posts: 14,594
    edited 2019-02-14 - 05:23:27
    Chip,

    Does this look correct? This is my send/receive code in the current ROM...

    BTW your flash code seems to sample differently ???

    SD%20SPI%20Timing%20Diagram.jpg

    Note:
    Data Out follows CLK low by 2 clocks. It can either precede by 2 or after 2 clocks.
    Data In will precisely sample on CLK going high in the new silicon if I have the info correct.

    Postedit - add out/sample
    1127 x 727 - 131K
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • Probably safest to make it work at 80 MHz on the FPGA. It adds another assumed extra clock of input lag but should handle any possible future discrepancies.
    "There's no huge amount of massive material
    hidden in the rings that we can't see,
    the rings are almost pure ice."
  • Cluso99Cluso99 Posts: 14,594
    edited 2019-02-14 - 05:19:34
    Here is the FLASH SPI Timing...
    Postedit fix out/sample
    FLASH%20SPI%20Timing%20DIagram.jpg
    590 x 633 - 76K
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • jmgjmg Posts: 13,092
    Cluso99 wrote: »
    Here is the FLASH SPI Timing...

    Does that mean the flash timing should be adjusted, to give enough margin ?

  • Cluso99Cluso99 Posts: 14,594
    edited 2019-02-14 - 05:44:29
    For my code, I have two choices...

    1. Data OUT follows the CLK LOW by 2 clocks (as-is)
    -or-
    2. Data OUT precedes the CLK LOW by 2 clocks

    Each bit-time is 23 clocks plus a lost hub window.

    Checking 25Q128 specs, 1. is preferable. All timings are met.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • Cluso99Cluso99 Posts: 14,594
    edited 2019-02-14 - 11:57:48
    Here is the timing for the P2D2 for all pins P00-P61...

    For the current ES silicon (v32i), presuming the delay from DRVx to the pin is +3 clocks after the end of the DRVx instruction, a minimum delay of 5 clocks (waitx #3) is required for the TESTP x instruction to see the output value on the pin. ie the TESTP instruction latches the pin value 1 clock prior to the start of the TESTP instruction.

    DRV-TESTP%20Timing.jpg

    On the respin silicon, this is expected to be waitx #4 or 2 clocks prior to the start of the TESTP instruction. INx instructions should take an extra clock prior.

    Here is the test code for the P2D2. Change the clock values in the CON section as marked for P2-EVAL.
    '' +--------------------------------------------------------------------------+
    '' | Cluso's P2 Test Program              (c)2013-2019 "Cluso99" (Ray Rodrick)|
    '' +--------------------------------------------------------------------------+
    '' RR20190201 0001a      generalised test program
    
    
    ''============================[ CON ]============================================================
    CON
    
    {{'P2-EVAL
      _XTALFREQ     = 20_000_000                                    ' crystal frequency
      _XDIV         = 2             '\                              '\ crystal divider                      to give 10.0MHz
      _XMUL         = 10            '| 100 MHz                      '| crystal / div * mul                  to give 100 MHz
      _XDIVP        = 1             '/                              '/ crystal / div * mul /divp            to give 100 MHz
      _XOSC         = %10                                   '15pF   ' %00=OFF, %01=OSC, %10=15pF, %11=30pF
    }}
    
    'P2D2
      _XTALFREQ     = 12_000_000                                    ' crystal frequency
      _XDIV         = 3             '\                              '\ crystal divider                      to give 4.0MHz
      _XMUL         = 12            '| 24 MHz                       '| crystal / div * mul                  to give 48 MHz
      _XDIVP        = 2             '/                              '/ crystal / div * mul /divp            to give 24 MHz
      _XOSC         = %01                                   'Osc    ' %00=OFF, %01=OSC, %10=15pF, %11=30pF
    
    
      _XSEL         = %11                                   'XI+PLL ' %00=rcfast(20+MHz), %01=rcslow(~20KHz), %10=XI(5ms), %11=XI+PLL(10ms)
      _XPPPP        = ((_XDIVP>>1) + 15) & $F                       ' 1->15, 2->0, 4->1, 6->2...30->14
      _CLOCKFREQ    = _XTALFREQ / _XDIV * _XMUL / _XDIVP            ' internal clock frequency                
      _SETFREQ      = 1<<24 + (_XDIV-1)<<18 + (_XMUL-1)<<8 + _XPPPP<<4 + _XOSC<<2  ' %0000_000e_dddddd_mmmmmmmmmm_pppp_cc_00  ' setup  oscillator
      _ENAFREQ      = _SETFREQ + _XSEL                                             ' %0000_000e_dddddd_mmmmmmmmmm_pppp_cc_ss  ' enable oscillator
      us            = _clockfreq/1_000_000                          ' 1us
    '------------------------------------------------------------------------------------------------
      _baud         = 115_200
      _bitper       = (_clockfreq / _baud) << 16 + 7          ' 115200 baud, 8 bits
      _txmode       = %0000_0000_000_0000000000000_01_11110_0 'async tx mode, output enabled for smart output
      _rxmode       = %0000_0000_000_0000000000000_00_11111_0 'async rx mode, input  enabled for smart input
    '------------------------------------------------------------------------------------------------
      rx_pin        = 63            ' pin serial receiver
      tx_pin        = 62            ' pin serial transmitter
      spi_cs        = 61            ' pin SPI memory select          (also sd_ck)
      spi_ck        = 60            ' pin SPI memory clock           (also sd_cs)
      spi_di        = 59            ' pin SPI memory data in         (also sd_di)
      spi_do        = 58            ' pin SPI memory data out        (also sd_do)
    '------------------------------------------------------------------------------------------------
      test_pin      = 49
      
    
    
    CON
    '' +--------------------------------------------------------------------------+
    '' | Cluso's LMM_SerialDebugger for P2    (c)2013-2018 "Cluso99" (Ray Rodrick)|
    '' +--------------------------------------------------------------------------+
    ''  xxxxxx : xx xx xx xx ... <cr>  DOWNLOAD:  to cog/lut/hub {addr1} following {byte(s)}
    ''  xxxxxx - [xxxxxx] [L] <cr>     LIST:      from cog/lut/hub {addr1} to < {addr2} L=longs
    ''  xxxxxx G <cr>                  GOTO:      to cog/lut/hub {addr1}
    ''  Q <cr>                         QUIT:      Quit Rom Monitor and return to the User Program
    ''  Lffffffff[.]xxx<cr>            LOAD:      Load file from SD
    ''  Rffffffff[.]xxx<cr>            RUN:       Load & Run file from SD
    ''  <esc><cr>                      TAQOZ:     goto TAQOZ
    '' +--------------------------------------------------------------------------+
    ''   LMM DEBUGGER - CALL Modes...(not all modes supported)
    '' +--------------------------------------------------------------------------+
      _MODE         = $F << 5                       ' mode bits defining the call b8..b5 (b4..b0 are modifier options)
      _SHIFT        = 5                             ' shr # to extract mode bits
      _HEX_         = 2 << 5                        ' hex...
        _REV_               = 1 << 4                '   - reverse byte order
        _SP                 = 1 << 3                '   - space between hex output pairs
       '_DIGITS             = 7..0 where 8->0       '   - no. of digits to display
      _LIST         = 3 << 5                        ' LIST memory line (1/4 longs) from cog/hub
        _ADDR2              = 1 << 4                ' 1= use lmm_p2 as to-address
        _LONG_              = 1 << 1                ' 1=display longs xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx
      _TXSTRING     = 4 << 5                        ' tx string (nul terminated) from hub
      _RXSTRING     = 5 << 5                        ' rx string
        _ECHO_              = 1 << 4                '    - echo char
        _PROMPT             = 1 << 3                '    - prompt (lmm_x)
        _ADDR               = 1 << 2                '    - addr of string buffer supplied
        _NOLF               = 1 << 1                '    - strip <lf>
      _MONITOR      = 7 << 5                        ' goto rom monitor
    '' +--------------------------------------------------------------------------+
    ''   P2 ROM SERIAL ROUTINES (HUBEXEC)
    '' +--------------------------------------------------------------------------+
      _SerialInit      = $fcab8     ' Serial Initialise     (lmm_x & lmm_bufad must be set first)
      _HubTxCR         = $fcae4     ' Sends <cr><lf>        (overwrites lmm_x)
      _HubTxRev        = $fcaec     ' Sends lmm_x with bytes reversed
      _HubTx           = $fcaf0     ' Sends lmm_x           (can be up to 4 bytes)
      _HubHexRev       = $fcb24     ' Sends lmm_x with bytes reversed as Hex char(s) as defined in lmm_f
      _HubHex8         = $fcb28     ' Sends lmm_x as Hex char(s) after setting lmm_f as 8 hex chars
      _HubHex          = $fcb2c     ' Sends lmm_x as Hex char(s) as defined in lmm_f
      _HubTxStrVer     = $fcb9c     ' Sends $0 terminated string at lmm_p address after setting lmm_p=##_str_vers
      _HubTxString     = $fcba4     ' Sends $0 terminated string at lmm_p address
      _HubListA2H      = $fcbc4     ' List/Dump line(s) from lmm_p address to lmm_p2 address after setting lmm_f=#_LIST+_ADDR2 
      _HubList         = $fcbc8     ' List/Dump line(s) from lmm_p address to lmm_p2 address according to lmm_f
      _HubRx           = $fcb10     ' Recv char into lmm_x
      _HubRxStrMon     = $fccc4     ' Recv string into lmm_bufad address after setting prompt=lmm_x=#"*" & params=lmm_f=#_RXSTRING+_ECHO_+_PROMPT
      _HubRxString     = $fcccc     ' Recv string into lmm_p/lmm_bufad address according to params in lmm_f
      _HubMonitor      = $fcd78     ' Calls the Monitor; uses lmm_bufad as the input buffer address
      _RdLongCogHub    = $fcf34     ' read cog/lut/hub long from lmm_p address into lmm_x, then lmm_p++
      _str_vers        = $fd014     ' locn of hub string, $0 terminated
    '' +--------------------------------------------------------------------------+
    '' HUB ADDRESSES
    '' +--------------------------------------------------------------------------+
      _HUBROM       = $FC000        ' ROM $FC000
      _HUBBUF       = $FC000        ' overwrite Booter
      _HUBBUFSIZE   = 80            ' RxString default size for _HUBBUF
    '' +--------------------------------------------------------------------------+
    
    ''============[ COG VARIABLES $1E0-$1EF - MONITOR]=============================
    ''-------[ LMM parameters, etc ]-----------------------------------------------
      lmm_x         = $1e0          ' parameter passed to/from LMM routine (typically a value)
      lmm_f         = $1e1          ' parameter passed to      LMM routine (function options; returns unchanged)
      lmm_p         = $1e2          ' parameter passed to/from LMM routine (typically a hub/cog ptr/addr)
      lmm_p2        = $1e3          ' parameter passed to/from LMM routine (typically a 2nd hub/cog address)
      lmm_c         = $1e4          ' parameter passed to/from LMM routine (typically a count)
    ''-------[ LMM additional workareas ]------------------------------------------
      lmm_w         = $1e5          ' workarea (never saved - short term use between calls, except _HubTx)
      lmm_tx        = $1e6          ' _HubTx
      lmm_hx        = $1e7          ' _HubHex/_HubString
      lmm_hx2       = $1e8          ' _HubHex
      lmm_hc        = $1e9          '   "
      lmm_lx        = $1ea          ' _HubList
      lmm_lf        = $1eb          '   "
      lmm_lp        = $1ec          '   "
      lmm_lp2       = $1ed          '   "
      lmm_lc        = $1ee          '   "
      lmm_bufad     = $1ef          ' _HubRxString
    '' +--------------------------------------------------------------------------+
    '' ASCII equates
    '' +--------------------------------------------------------------------------+
      _CLS_         = $0C     
      _BS_          = $08
      _LF_          = $0A
      _CR_          = $0D
      _TAQOZ_       = $1B           ' <esc>   goto TAQOZ
    '' +--------------------------------------------------------------------------+
    
    DAT             org     0
    
    
    entry
    
    
    '+=============================================================================+
    
    '+-------[ Set Xtal ]----------------------------------------------------------+ 
    entry2          hubset  #0                              ' set 20MHz+ mode
                    hubset  ##_SETFREQ                      ' setup oscillator
                    waitx   ##20_000_000/100                ' ~10ms
                    hubset  ##_ENAFREQ                      ' enable oscillator
    '+-----------------------------------------------------------------------------+
                    waitx   ##_clockfreq*5                  ' just a delay to get pc terminal running
    '+-----------------------------------------------------------------------------+
    
    
    
    
    '+=============================================================================+
    '+ Display results                                                             +
    '+=============================================================================+
    
    '+-------[ Start Serial ]------------------------------------------------------+ 
                    mov     lmm_bufad,        ##_HUBBUF     ' locn of hub buffer for serial routine 
                    mov     lmm_x,            ##_bitper     ' sets serial baud
                    call    #_SerialInit                    ' initialise serial
    '+-----------------------------------------------------------------------------+
    ''              mov     lmm_x,            #0            ' clear screen
    ''              call    #_hubTx
    '+-----------------------------------------------------------------------------+
                    mov     lmm_f,            #_TXSTRING+0  ' send string, $00 terminated 
                    mov     lmm_p,            ##_hubstring  ' must be in hub!
                    call    #_HubTxString
    '+-----------------------------------------------------------------------------+
    
    
    '+=============================================================================+
    '+ Test Section                                                                +
    '+=============================================================================+
    
    
                    mov     w,#2
                    mov     pin,#0                          ' start at P0
                    mov     c,#62
    .again          call    #loop
                    add     pin,#1
                    djnz    c,#.again
    
                    call    #_hubTxCR
    
                    mov     w,#3
                    mov     pin,#0                          ' start at P0
                    mov     c,#62
    .again3          call    #loop
                    add     pin,#1
                    djnz    c,#.again3
    
    '+-----------------------------------------------------------------------------+
                    jmp     #$                              ' loop here <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
    '+-----------------------------------------------------------------------------+
    
    
    loop            mov     x,#0
                    drvl    pin
                    waitx   #8
                    drvh    pin
                    waitx   w
                    testp   pin               wc
                    rcl     x,#1
                    or      x,#"0"
                    mov     lmm_x,x
                    call    #_hubTx
                    
                    mov     x,#0
                    drvh    pin
                    waitx   #8
                    drvl    pin
                    waitx   w
                    testp   pin               wc
                    rcl     x,#1
                    or      x,#"0"
                    mov     lmm_x,x
                    call    #_hubTx
                    call    #_hubTxCR
    
                    flth    pin
                    ret
    '+-----------------------------------------------------------------------------+
                    jmp     #$                              ' loop here <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
    '+-----------------------------------------------------------------------------+
    
    x               long    0
    c               long    0
    w               long    2'3
    pin             long    55
    
                    fit     $1E0                            ' check fits in cog  with lmm_x
    '+-----------------------------------------------------------------------------+
    
    ''============[ HUB VARIABLES ]=================================================                                    
    DAT             orgh    $
    _hubstring      byte    "P2 Test Program v0003b",13,10,0
                    alignl                                                                                                             
    ''---------------------------------------------------------------------------------------------------
    
    830 x 454 - 63K
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • I've just run that on FPGA with v33j image at 80 MHz. I had to add a couple more values for "w". Here's a terminal output of values from 2 through 5. (Note: The 3 inputs that are always set are the push buttons on the P123 board.)
    P2 Test Program v0003b
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    11
    11
    11
    01
    01
    01
    01
    
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    11
    11
    11
    01
    01
    01
    01
    
    01
    01
    01
    01
    11
    11
    10
    11
    11
    01
    10
    10
    10
    11
    10
    10
    01
    01
    11
    01
    10
    11
    11
    11
    10
    10
    10
    11
    10
    10
    10
    11
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    01
    10
    01
    11
    10
    11
    10
    11
    11
    11
    01
    01
    01
    01
    
    10
    10
    10
    10
    10
    10
    10
    10
    10
    10
    10
    10
    10
    10
    10
    10
    10
    10
    10
    10
    10
    10
    10
    10
    10
    10
    10
    10
    10
    10
    10
    10
    10
    10
    10
    10
    10
    10
    10
    10
    10
    10
    10
    10
    10
    10
    10
    10
    10
    10
    10
    10
    10
    10
    10
    11
    11
    11
    10
    10
    10
    10
    
    

    "There's no huge amount of massive material
    hidden in the rings that we can't see,
    the rings are almost pure ice."
  • Cluso99Cluso99 Posts: 14,594
    edited 2019-02-14 - 22:00:46
    Thanks Evan :smiley:
    So w=5 for reliable results at 80MHz.
    I will retry mine shortly at 25MHz on P2D2. I was running at 24MHz for timing above.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • Cluso99Cluso99 Posts: 14,594
    edited 2019-02-14 - 22:24:17
    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)

    This is the essence of the test
                    drvl    pin
                    waitx   #8
                    drvh    pin
                    waitx   w
                    testp   pin               wc
                    rcl     x,#1
    
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • Cluso99 wrote: »
    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)
    Damn, a range! Not just around one edge.

    Cluso,
    There is a good chance that all those lags go up by one in the re-spin. I don't understand it and I'm not confident that Chip has sorted it. We might just have to live with it in the Prop2.

    "There's no huge amount of massive material
    hidden in the rings that we can't see,
    the rings are almost pure ice."
  • jmgjmg Posts: 13,092
    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)

    This is the essence of the test
                    drvl    pin
                    waitx   #8
                    drvh    pin
                    waitx   w
                    testp   pin               wc
                    rcl     x,#1
    

    Hmm.. That test seems to be saying the async path delays exceed higher SysCLKs ( which the added delay is not going to fix, but I think that was done for other reasons).
    It also means
    * ROM code may not work at higher sysclks (some were wanting to call-into ROM routines ?)
    * Deterministic pin-pin paths may not be possible above some sysclk, and may require sysclk bands (with PVT edges) above that sysclk.
  • Cluso, Evanh,

    If you enable clocking in the digital pin mode, things should firm up. In your current test, you are stacking up a bunch of delays, whereas if clocking were to be enabled, the 3.3V I/O pin would register the input and output, hiding the internal propagation delays for which setup and hold time requirements ARE covered for clocked mode. If I could redesign the I/O pad, I would make it always synchronous (clocked).
  • cgracey wrote: »
    Cluso, Evanh,

    If you enable clocking in the digital pin mode, things should firm up. In your current test, you are stacking up a bunch of delays, whereas if clocking were to be enabled, the 3.3V I/O pin would register the input and output, hiding the internal propagation delays for which setup and hold time requirements ARE covered for clocked mode. If I could redesign the I/O pad, I would make it always synchronous (clocked).
    Chip,
    My ROM SD code is working nicely at 24MHz which is the target speed so I think I will just leave that part of the code as-is. Do you agree?

    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • Clocking the inputs was not necessary on the P1, which really simplified things. Why is it necessary on the P2?

    -Phil
    “Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away. -Antoine de Saint-Exupery
  • Cluso99 wrote: »
    cgracey wrote: »
    Cluso, Evanh,

    If you enable clocking in the digital pin mode, things should firm up. In your current test, you are stacking up a bunch of delays, whereas if clocking were to be enabled, the 3.3V I/O pin would register the input and output, hiding the internal propagation delays for which setup and hold time requirements ARE covered for clocked mode. If I could redesign the I/O pad, I would make it always synchronous (clocked).
    Chip,
    My ROM SD code is working nicely at 24MHz which is the target speed so I think I will just leave that part of the code as-is. Do you agree?

    I agree.
  • Clocking the inputs was not necessary on the P1, which really simplified things. Why is it necessary on the P2?

    -Phil

    There are many more levels of logic. Without those registers, the Fmax might otherwise be only 40 megahertz.
  • cgracey wrote: »
    If you enable clocking in the digital pin mode, things should firm up.
    Chip,
    That has never made one bit of difference to consistency right from first discovery! This is why I've always been raising concern.
    "There's no huge amount of massive material
    hidden in the rings that we can't see,
    the rings are almost pure ice."
  • All it does is add two clocks to the overall lag.
    "There's no huge amount of massive material
    hidden in the rings that we can't see,
    the rings are almost pure ice."
  • The problem appears to be with the input signal flow. Output seems to be okay.
    "There's no huge amount of massive material
    hidden in the rings that we can't see,
    the rings are almost pure ice."
  • cgraceycgracey Posts: 10,864
    edited 2019-02-15 - 06:03:11
    evanh wrote: »
    cgracey wrote: »
    If you enable clocking in the digital pin mode, things should firm up.
    Chip,
    That has never made one bit of difference to consistency right from first discovery! This is why I've always been raising concern.

    So, enabling clocking does increase latency by one clock, for both input and output, right?

    But you are seeing additional delay times that are longer than a clock at very high frequencies. Those delays must be from the circuitry in the 3.3V I/O pad, then, which is not going to become different from what it currently is. If I had known the chip was going to actually work at 300MHz, I would have designed the I/O pad to work faster.

    At this point, the I/O pad is what it is.

    Wendy at ON is implementing some extra timing constraints which will group the delivery of all core-to-pin signals within 300ps, aside from being within setup-time and hold-time requirements. The pin-to-core IN signals will be constrained similarly. This will regulate asynchronous pin I/O, so that all pins will behave as identically as is reasonably possible.
  • Testing with this v33j shows no improvement on the FPGA.

    And Cluso has just proven the problem is not only no better in the real silicon but the overall effect is worse because the finished product has so much over-clock-ability.
    "There's no huge amount of massive material
    hidden in the rings that we can't see,
    the rings are almost pure ice."
  • cgracey wrote: »
    So, enabling clocking does increase latency by one clock, for both input and output, right?
    That is my understanding, yes. +1 clock for each.
    But you are seeing additional delay times that are longer than a clock at very high frequencies. Those delays must be from the circuitry in the 3.3V I/O pad, then, which is not going to become different from what it currently is. If I had known the chip was going to actually work at 300MHz, I would have designed the I/O pad to work faster.
    The FPGA is showing the exact same behaviour. And always has.
    "There's no huge amount of massive material
    hidden in the rings that we can't see,
    the rings are almost pure ice."
  • Chip,
    Here is code to test this out. It scans pins 0-61 and outputs the results to serial.
    You can change the clock in the CON section (currently 300MHz for P2D2)

    This is the important bit
    loop            mov     x,#0
                    drvl    pin
                    waitx   #8
                    drvh    pin
                    waitx   w
                    testp   pin               wc
                    rcl     x,#1
                    or      x,#"0"
                    mov     lmm_x,x
                    call    #_hubTx
    
    I run thru this with w varying from #2 to #5 and outputting either a 0 or 1. I test both low and high initially.
    At different speeds w needs to be different, and at some frequencies, there is a variable w where the result can be either so we are on the edge with that value.

    from the main test section
    '+=============================================================================+
    '+ Test Section                                                                +
    '+=============================================================================+
    
    
                    mov     w,#2
                    mov     pin,#0                          ' start at P0
                    mov     c,#62
    .again          call    #loop
                    add     pin,#1
                    djnz    c,#.again
    
                    call    #_hubTxCR
    
                    mov     w,#3
                    mov     pin,#0                          ' start at P0
                    mov     c,#62
    .again3          call    #loop
                    add     pin,#1
                    djnz    c,#.again3
    
                    call    #_hubTxCR
    
                    mov     w,#4
                    mov     pin,#0                          ' start at P0
                    mov     c,#62
    .again4          call    #loop
                    add     pin,#1
                    djnz    c,#.again4
    
                    call    #_hubTxCR
    
                    mov     w,#5
                    mov     pin,#0                          ' start at P0
                    mov     c,#62
    .again5          call    #loop
                    add     pin,#1
                    djnz    c,#.again5
    
    '+-----------------------------------------------------------------------------+
                    jmp     #$                              ' loop here <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
    '+-----------------------------------------------------------------------------+
    
    
    loop            mov     x,#0
                    drvl    pin
                    waitx   #8
                    drvh    pin
                    waitx   w
                    testp   pin               wc
                    rcl     x,#1
                    or      x,#"0"
                    mov     lmm_x,x
                    call    #_hubTx
                    
                    mov     x,#0
                    drvh    pin
                    waitx   #8
                    drvl    pin
                    waitx   w
                    testp   pin               wc
                    rcl     x,#1
                    or      x,#"0"
                    mov     lmm_x,x
                    call    #_hubTx
                    call    #_hubTxCR
    
                    flth    pin
                    ret
    '+-----------------------------------------------------------------------------+
    

    The remaining code/equates are chaf to utilise the inbuilt ROM serial routines.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • cgraceycgracey Posts: 10,864
    edited 2019-02-15 - 06:13:48
    evanh wrote: »
    Testing with this v33j shows no improvement on the FPGA.

    And Cluso has just proven the problem is not only no better in the real silicon but the overall effect is worse because the finished product has so much over-clock-ability.

    I don't know what to do about it. An I/O pin is big and slow compared to internal signals. It's like the difference between a hydraulic backhoe and your hands on the controls. Just to implement ESD protection on the I/O pad, you incurr 1000x the capacitive loading of the core-side signals.
Sign In or Register to comment.