Group Actions
Engagement
  • Author Author: michaelkellett
  • Date Created: Date Created
  • Views 2164 views
  • Likes 4 likes
  • Comments 4 comments
Related
Recommended

ARMP ADC, DAC and FPGA

michaelkellett

Overview

 

Once again there are few (if any) component vlaues on the schematic, these will appear in the BOM later on.

Treat the pin numbering on the FPFA with caution, I shall swap pins as appropriate when I layout the board.

 

image

 

The Details

 

The DAC digital interface is forced to SPI mode by pulling pin SPI2C low.

The FPGA drives it s three SPI signals (the DAC can't return any data to the FPGA.

The analogue signal from the DAC is low pass filtered by the Sallen and Key filter

based on U9. We can easily over sample the DAC drive by a large margin so

we don't need a fancy filter.

 

The ADC has a few more options:

The Rate pin is pulled high so that the sample rate =  SCKI / 512.

The S/M pin is pulled high so that the data interface operates in slave mode (ie is controlled by the FPGA).

SCKI is the primary clock for the ADC and is divided to make the acqusition clock, in many cases it would be

bad practice to drive it from the FPGA because FPGA outputs are rather jittery. Because we are only operating at

very low frequencies the FPGA levels of jitter won't cause a problem.

The FPGA also controls the BCK (data bit clock), the DATA and FSYNC pins. (Read the PCM4201 data sheet

for a full explanation. BCK and SCKI must be synchronised, so that SCKI is an exact multiple of BCK - no problem

for the FPGA.

All the signals between FPGA and the DAC and ADC are also available on J1. This is for debugging. I'm

assuming that people will want to tinker with this design and even re-purpose it - so I'm trying to make it easy

for them. J1 is a 0.1" pitch header - OK for debugging but to keep the size down no provision for locking connectors.

The input to the ADC has already been low pass filtered and because the ADC is  a sigma delta type

it doesn't need an exotic anti alias filter, having its own built in oversampling.

The ADC's reset and high pass filter enable are not connected to the FPGA but will be controlled directly

by the micro.

 

A 16MHz oscillator is connected to an FPGA clock input and will (probably) be up-converted by the PLL

to make the FPGA internal clock.

 

J2 is a Molex Picoblade connector to allow the FPGA to eb connected to the operator controls.

At present these are not defined. The 8 connections to the FPGA are sufficient for 8 pushbuttons or a couple

rotary encoders and two buttons or even a serial interface to shift registers or other input devices.

I've used a Molex Picoblade connector because they are rather less likely to fall off and are tiny.

 

The second FPGA block on the right shows its power and programming connections. The processor must

program the FPGA on power up (the FPGA keeps its bit pattern in RAM) and an SPI interface is used for this.

Once the FPGA is running it will use the same SPI pins to communicate with the processor but will operate as

the SPI master.

The spare signals are for as yet undefined hand shaking purposes. The FPGA to processor signals

are available on a second debugging header. (There wasn't room for CRESET_B - but it is controlled by the

processor and slow, so not very interesting. It's only used during FPGA programming.)

 

The FPGA needs 3.3V for its IO pins and 1.2V (at not much current) for its core.

 

I've used this FPGA in this configuration before - so I'm confident that it will work OK.

 

It says ICE5LP on the schematic but I think we'll actually use an ICE40UP5k, (same pin-out (or near enough)).

 

I've changed my ideas for the input and output overload monitoring as well. Now I'm using a quad comparator rather

than the micro's ADC - this ends up with fewer parts and allows the FPGA to easily deal with overload monitoring.

 

MK

Parents

  • Hi Michael,

     

    This is great, another easy-to-follow explanation. Regarding the to-be-defined handshaking, one of them will need to be to a microcontroller interrupt, so it could be used for the signal for indicating when the DAC output is about to be set to zero degrees of the sine output. For the overload circuitry, maybe an OR'ing is enough into another single interrupt, i.e. the microcontroller can then try to enable the input attenuators, if it doesn't clear the issue then the microcontroller knows the source level needs adjustment.

    Perhaps the overload could also be noticed from a harmonic, but it will be good to have the hardware method too.

Comment

  • Hi Michael,

     

    This is great, another easy-to-follow explanation. Regarding the to-be-defined handshaking, one of them will need to be to a microcontroller interrupt, so it could be used for the signal for indicating when the DAC output is about to be set to zero degrees of the sine output. For the overload circuitry, maybe an OR'ing is enough into another single interrupt, i.e. the microcontroller can then try to enable the input attenuators, if it doesn't clear the issue then the microcontroller knows the source level needs adjustment.

    Perhaps the overload could also be noticed from a harmonic, but it will be good to have the hardware method too.

Children
  • in reply to shabaz

    Hello Shabaz, thanks for your comments,

     

    It's interesting how different our instinctive approaches are to this !

     

    I come from a background where every interrupt request (at design level image) is refused out of hand and only granted if an overwhelming case can be made for it.

    The premise is that interrupts are bad and that the badness is at least proportional to n^2, probably worse. (I know that this is not entirely rational !)

    Now you know why I don't like RTOSs !

     

    So the idea in my head was that the overload comparators are connected to the FPGA which will latch any event lasting longer than maybe 100us. The FPGA will

    also be collecting ADC samples and sending out DAC samples. This activity will be synchronised to the single system clock (which runs at 16MHz). The processor will

    periodically (probably about once every ms but might be slower) ask the FPGA for a packet of data, so the FPGA can send the data packet with its associated

    overload status as one high integrity blob. So we get blobs of data with known synchronisation (between ADC and DAC) with known integrity with no interrupts.

    The processor clock is synchronised to the FPGA clock so the periodicity of the poling is completely predictable.

     

    For "SPI" I usually use two handshake signals between processor and FPGA, the FPGA being the SPI master. One handshake signal is ucr (microprocessor command ready) and the other

    if fsb (fpga spi busy). The other three signals are the usual MOSI, MISO and SCK. The FPGA is the SPI master, which means that it controls the clock and the pacing of the data.

    The processor uses DMA to transfer SPI data to memory, but doesn't need to use interrupts !

     

    The great thing is that this is an FPGA, so, to paraphrase Groucho Marx, "That's my handhsake protocol, but if you don't like it, I have others !"

     

    When the pcb layout is almost done I always try to connect all the FPGA pins to either the processor or to debug connectors.

    This stood me in good stead recently where I was able to add an additional 8 channels to an 8 channel lock in amp by connecting

    an extension board to the debug connectors. The SPI interface was hardwired between processor and primary FPGA so it had to

    multiplex the SPI between itself and the extension FPGA.

     

    So in the end I expect to have several uncommitted FPGA to processor signals.

     

    The FPGA can be re-coded by the processor without changing the processor code if we store the FPGA pattern in external flash memory.

     

    MK