Suitability (and availability) of Parallax 1-2-3 A9 FPGA boards for some preproduction

124»

Comments

  • cgraceycgracey Posts: 13,179
    edited 2016-02-20 (12:47 AM)
    jmg wrote: »
    cgracey wrote: »
    Anyway, I understand your reaction. I went around and around with this before landing here.
    I think this is very close.

    What about the minor pin-swaps I suggested of TESn & Vdd and getting XO separation from Port pin (by slight move of VccIO) ?

    You can see that the delicate RESn and XI inputs are shielded by power pins. TESn, the scan-chain enable is going to be tied high. The XO is an ouput, so it doesn't really matter.
  • jmg wrote: »
    cgracey wrote: »

    The impedance of the circuit board traces is actually 10x less than the internal power routings on the chip, as those thin metals have 42 milliohms/square sheet resistance, at best. Most are 78 milliohms/square. That's why there are lots of power and ground bonds.

    Imagine an internal power strap, 70um wide, spanning 700um, or just two I/O pads from a VIO pin. In lowest-Z top metal of 42 milliohms/square, you'd have ten squares, yielding 0.42 ohms! The resultant IR drop starts dipping into the LSBs of a 75 ohm 8 bit pin DAC. Meanwhile, the power routing on the PCB is more like 1/10th that impedance, because the copper traces are proportionally 10x thicker than the routing metals on the chip.

    For PCB design, I think a bottom-side power ring for VDD with just four caps to ground, placed on the sides of the ring, with dual vias going up to each VDD pin would be quite sound.

    The DAC is powered from Vdd, or VccIO ?
    I was thinking 4 caps would be a likely OK for most Vdd uses scenario.
    (which was why I suggested getting a Vdd pad at each corner, where practical)

    All I/O signals are powered by the 3.3V VIO pins. Each VIO connects to two pins on each side, for four total.
  • cgracey wrote: »
    TESn, the scan-chain enable is going to be tied high.
    Yes, but the path to a corner placed top-cap and Vdd pin is longer than it needed to be.
    cgracey wrote: »
    The XO is an output, so it doesn't really matter.
    Yes and no.
    It is the output of a CMOS linear amplifier, which is not Low Z like a proper Digital output is.
    The Xtal buffer hysteresis is what sets the glitch disturbance, and with low CL values,(modern trend) less Pin-Pin parasitic C is needed to give enough injection to cross that buffer hysteresis band.
    Do OnSemi have a figure for that Xtal buffer hysteresis ?
    What is the lead-frame (PCB mounted) parasitic Pin-Pin C ?

  • cgraceycgracey Posts: 13,179
    edited 2016-02-20 (1:23 AM)
    jmg wrote: »
    cgracey wrote: »
    TESn, the scan-chain enable is going to be tied high.
    Yes, but the path to a corner placed top-cap and Vdd pin is longer than it needed to be.
    cgracey wrote: »
    The XO is an output, so it doesn't really matter.
    Yes and no.
    It is the output of a CMOS linear amplifier, which is not Low Z like a proper Digital output is.
    The Xtal buffer hysteresis is what sets the glitch disturbance, and with low CL values,(modern trend) less Pin-Pin parasitic C is needed to give enough injection to cross that buffer hysteresis band.
    Do OnSemi have a figure for that Xtal buffer hysteresis ?
    What is the lead-frame (PCB mounted) parasitic Pin-Pin C ?

    XO is a 32x inverter (single stage) fed through a pass gate by XI. I'm sure that P31 couldn't flip it, but it would shift the XO rise and fall times slighty, causing jitter on the XO/XI feedback loop. Probably nothing to get concerned about.

    The VDD pads are distributed quite evenly, which I think is more important than whether they land on a corner pin, or not. There's a nice symmetry to it. Just my opinion, of course.
  • cgracey wrote: »
    The VDD pads are distributed quite evenly, which I think is more important than whether they land on a corner pin, or not. There's a nice symmetry to it. Just my opinion, of course.

    That is certainly true. It is nicely symmetric. Then forget about the proposed changes, It seems that you have find the perfect balance.

    Now that we are talking about XI/XO. Do we have specs about system clock. Is it the same as P1 with RCFAST, RCSLOW, crystal oscillator 4Mhz to 8MHz (+ PLL 1x, 2x, 4x, 8x, 16x), and external clock signal?

    How will you improve the P1? My suggestions:

    1) Stable and deterministic behaviour when changing between RCFAST/RCSLOW and oscillator modes. (dynamic system clock changes)
    2) Wider range for crystal frequency (32 KHz .. 20 MHz) and capacitance.
    3) Ability to select clock not only from XI/XO but also from any pin pair / smart pin (clock recovery). I am thinking with this in crystal-less system.
    4) One single HUB clock for all COGs, but smartpins will be able to work either with 2 different clocks : either the HUB/System clock or Clock recovery from pins.

    This last one is for some applications that need to synchronize high speed data with two different external system clocks that are not the same as the P2 internal system clock.

    Example: two external FT232H in fast 245 Sync mode. Both FT232H provides a 60 MHz clock to the propeller + 8 parallel data bits.
  • jmgjmg Posts: 14,572
    Ramon wrote: »
    Now that we are talking about XI/XO. Do we have specs about system clock. Is it the same as P1 with RCFAST, RCSLOW, crystal oscillator 4Mhz to 8MHz (+ PLL 1x, 2x, 4x, 8x, 16x), and external clock signal?

    How will you improve the P1? My suggestions:

    1) Stable and deterministic behaviour when changing between RCFAST/RCSLOW and oscillator modes. (dynamic system clock changes)
    2) Wider range for crystal frequency (32 KHz .. 20 MHz) and capacitance.
    IIRC the Xtal range is wider than P1, and the PLL is integer granular and also wider.

    However, 32kHz needs a special Crystal Bias & Buffer, which may not be included ?
    Ramon wrote: »
    3) Ability to select clock not only from XI/XO but also from any pin pair / smart pin (clock recovery). I am thinking with this in crystal-less system.
    That also infers some special PLL modes, so that seems unlikely.
    Ramon wrote: »
    4) One single HUB clock for all COGs, but smartpins will be able to work either with 2 different clocks : either the HUB/System clock or Clock recovery from pins.

    This last one is for some applications that need to synchronize high speed data with two different external system clocks that are not the same as the P2 internal system clock.

    Example: two external FT232H in fast 245 Sync mode. Both FT232H provides a 60 MHz clock to the propeller + 8 parallel data bits.
    Sync Slave Modes can accept a clock, but it's unclear just how high that can go.
    As well as FT232H 60MHz there is FT600 that has 60 or 100MHz clock


    The PLL should be able to accept 60MHz + CMOS CLKIN ?

  • cgraceycgracey Posts: 13,179
    edited 2016-02-20 (1:07 PM)
    jmg wrote: »
    Ramon wrote: »
    Now that we are talking about XI/XO. Do we have specs about system clock. Is it the same as P1 with RCFAST, RCSLOW, crystal oscillator 4Mhz to 8MHz (+ PLL 1x, 2x, 4x, 8x, 16x), and external clock signal?

    How will you improve the P1? My suggestions:

    1) Stable and deterministic behaviour when changing between RCFAST/RCSLOW and oscillator modes. (dynamic system clock changes)
    2) Wider range for crystal frequency (32 KHz .. 20 MHz) and capacitance.
    IIRC the Xtal range is wider than P1, and the PLL is integer granular and also wider.

    However, 32kHz needs a special Crystal Bias & Buffer, which may not be included ?
    Ramon wrote: »
    3) Ability to select clock not only from XI/XO but also from any pin pair / smart pin (clock recovery). I am thinking with this in crystal-less system.
    That also infers some special PLL modes, so that seems unlikely.
    Ramon wrote: »
    4) One single HUB clock for all COGs, but smartpins will be able to work either with 2 different clocks : either the HUB/System clock or Clock recovery from pins.

    This last one is for some applications that need to synchronize high speed data with two different external system clocks that are not the same as the P2 internal system clock.

    Example: two external FT232H in fast 245 Sync mode. Both FT232H provides a 60 MHz clock to the propeller + 8 parallel data bits.
    Sync Slave Modes can accept a clock, but it's unclear just how high that can go.
    As well as FT232H 60MHz there is FT600 that has 60 or 100MHz clock


    The PLL should be able to accept 60MHz + CMOS CLKIN ?

    The crystal oscillator is designed to run off a 20MHz crystal. It can multiply the crystal by 2x,3x,4x,..16x.

    You can always drive a clock straight into XI if you don't want to mess with a crystal. As long as that clock is a few MHz to 80MHz, you can also use the internal PLL. You'd only want to multiply 80MHz by two, though.
  • jmgjmg Posts: 14,572
    edited 2016-02-20 (8:14 PM)
    cgracey wrote: »
    The crystal oscillator is designed to run off a 20MHz crystal.

    There will be some range to that ?

    eg SiLabs spec a Crystal Range like this :

    8.2 MHz < f ≤ 25 MHz for Bias Current of appx 2.6 mA
    20 kHz < f ≤ 58 kHz for Bias Current of appx 1.5 µA
    cgracey wrote: »
    It can multiply the crystal by 2x,3x,4x,..16x.

    You can always drive a clock straight into XI if you don't want to mess with a crystal. As long as that clock is a few MHz to 80MHz, you can also use the internal PLL. You'd only want to multiply 80MHz by two, though.

    Having a single 4 bit config is quite restrictive ? (but better than P1)

    Devices that have a PLL, usually have some Phase Detect Freq and use two numbers on the PLL.
    eg a 4MHz PFD, would take 20MHz Xtal and /5, and take 160MHz VCO and /40

    PFD = Xtal/M = VCO/N


    A quite recent trend is a significant drop in VCTCXO prices, and these come for under $1 now.
    You get low Icc (sub 2mA) and better than 2ppm of precision.
    Seems to be driven by GPS use. (ie high volume ), and this will shake out the whole Oscillator market.

    These do come with a couple of caveats :
    a) Frequency Choice is not large.
    26MHz is common, as is 19.2MHz, then 38.4 MHz 52 MHz 16MHz 33.6MHz etc
    They target a few common values, and go for volume.

    b) They output Clipped Sine, >= 0.,8V p-p into a 10k load, Zo is appx 200 ohms

    Clipped Sine brings Lower Icc, and lower RFI, so will quickly become de-facto.


    This means any Chip Oscillator design today should be spec'd to include these.

    Support of b) usually just needs AC coupling to a self-biased Xtal Amplifier. (CL=0)

    The limited choices of Fo, mean a second number to a few-MHz PFD, can expand usable PLL values.

    Taking one example: 48MHz multiples will be a focus, with USB looking likely.

    (48*3)/(19.2/2) = 15, for M=2, N=15 and 144MHz VCO
    (48*2)/(19.2/3) = 15, for M=3, N=15 and 96MHz VCO

    26MHz needs 2MHz PFD for precise 96MHz, but 2.6MHz PFD is ~0.2%, which comes inside
    USB tolerance of ±0.25% or 2,500ppm
  • Peter JakackiPeter Jakacki Posts: 9,940
    edited 2016-02-22 (3:24 AM)
    @jmg - thanks for that info, quite interesting.

    Since I am laying out new designs I am making schematic library components for the P2 both for Protel which I currently use and DipTrace which I'd like to use. The number of times I've tried to start a project with DipTrace and I can't believe that despite it's power and features that simple things like quick keyboard shortcuts aren't used, instead I have click through menus for every little thing and then I can't just select a resistor symbol and specify the footprint later etc, it has a separate symbol for every footprint!! Slooooww.

    Anyway, I will persevere in the meantime. The CV-A9 MEC style 80-pin connector will also feature as a "P2" component.

    edit: I still need to add the ground "pin" - updated
    P16X32-SCHSYM2.png
  • I ordered some CV-A9 boards today and hopefully also in a couple of weeks I should have my new P2 controller boards back with the P2 footprint plus the 80-pin edge connector for the CV-A9 board in the meantime. This will be a lot of fun as this controller will be loaded with goodies!!!!
  • T ChapT Chap Posts: 4,051
    edited 2016-02-23 (3:25 AM)
    Peter, very interesting concept you have. I am curious what is the issue with dropping in the A9 on your own board versus using the third party board via the connector? I assume the soldering is the biggest obstacle, so why is there not a breakout board available for the cyclone chip so you don't have to deal with the BGA soldering challenge.
  • Actual real preproduction quantities in the field can't have FPGA standalone boards connected across with third party connectors etc, way too unreliable and not a good look. However having the small cva9 board plugged into the main controller PCB via its 80 pin edge connector is plenty fine and when p2 chips are available I can retrofit these to those models as long as I can keep preproduction restricted until then.
Sign In or Register to comment.