Hardware Projects » E1/T1 Hardware Interface (including icE1usb)

The clocking architecture might be highly dependent on the choice of 'MCU' (sam3/xmos/ti/fpga...).

Most of these would have timer peripheral that will allow to do the counting, possibly even do the division to generate the 2.048M clock (if the vctxo clocks that 'mcu' directly) or have DAC, ...

I was thinking of two options (that I'll illustrate using the SAM4S here, didn't check XMOS):

1. Timers have an external clock input pin and feed that with the VCXO. I actually thought that this would synchronously feed the counter directly, but you're right, it's actually re-synced to the internal peripheral clock. Now, I don't think it would be that much of an issue because:
   • The peripheral clock is going to be much higher in any case
   • By progressively increasing the time constant of the software filtering (to get quick lock at the beginning, but be more stable after), that jitter wouldn't matter much I think
   • In any case I don't think the jitter of the clock we generate any way is all that important (well, needs to be reasonable of course and withing E1 spec), because the BTS is going to have its own oscillator and will just lock the long term frequency to what we send.

1. But any way, a better option I would think is to clock the MCU itself with the VCXO as well. So for instance for the SAM4S:
   • You'd use a 30.72M VCXO and feed that to the SAM4S
   • Using the internal PLL, you can divide it by 8 and then multiply by 25 to generate the 96 MHz output needed for USB.
   • Using the other PLL you can generate the core clock, something like divide by 3, multiply by 10 to generate a 102.4 MHz clock.
   • Using a PWM peripheral it should be possible to output 2.048 MHz that's perfectly synced to the input 30.72M
   • Use the TC to count pulse between PPS and drive a DAC, or even possibly use a heavy filtered PWM channel.

If we do it all within a microcontroller, and to receive E1 bits we probably want to sample the incoming signal at a rate ≥4×f_E1 (pulses are ~250ns), so we would need two synchronized SPI blocks at 8,192 Mhz. Same holds true for generating the pulses.

Otherwise the idea of running the MCU from the VCXO seems to be a good idea.

I've drawn up the clocking scheme proposed by tnt on top of a page of the SAM4S user manual. The programmable clock controller can output the 2,048 MHz for the LIU directly to a pin. That way we use up both PLLs and we will run the core at 96 MHz.

SAM-BA over USB works for an 18.432 MHz XTAL (9*2.048), but the boot code seems to expect a crystal, not an external oscillator which has different input requirements on the signal fed to XIN. (§24.2, Note 1). We will have to attenuate the 3.3V crystal oscillator output to not overdrive the xtal input amplifier.

If 18.432 MHz oscillators are unavailable, we could add a separate one only for SAM-BA, and alternate between them outputs via the oscillator enable pins.

as much as it pains me, sylvain's ICE40 approach has turned out to be the more attractive approach, if not only from the per-unit cost (no LIU, smaller PCB, etc.). So I'm rejecting this ticket.

I might at some point not be able to resist implementing the missing firmware bits to make it USB-protocol compatible to the ICE40 so I can use the 2-3 boards of the SAM4 based approach.

I'm particularly sorry for vogelchr who spent significant time and effort on this SAM4 based approach. Thanks!