fpga4fun.com

Hi all,


I have a couple of questions - I am designing a USB oscilloscope which I have a rough working prototype of - a basic windows app and a ADC connected to a PIC32. I am considering using an FPGA or CPLD to do the triggering with, and possibly also to genrate RAM addresses and read/write between RAM and the PIC32 (for better trigger capabilities, and in order to speed things up)
Any comments on the subject would be most appreciated.
Thanks,
Oli

Hi Oli,

I would suggest the use of a FPGA as the SPLD is really to small.
A 16V8 has only 8 macrocells (only 8 equations can be fit in this kind of device).

Thoma

Thanks for the reply Thomas, that confirms it for me. I will use the proAsic. Do you think 60K gates is enough for this type of job?

Roughly, I need:

14 bit ram address counter
8 bit data path to ram
8 bit digital comparator (able to detect rising/falling edge)
Trigger value shift register (or just parallel value on pins)
A few control pins (start capture, capture end, etc)

Hi Oli,

Could you give the whole FPGA part number?

I would suggest a system synoptic like the one below:


FPGA will contains:
- a RAM controller that forbid PIC32 access as long as acquisition is in progress (to avoid data corruption),
- your comparator for edge detection,
- a register that contains the comparison value and
- a control register (start capture, stop capture, interrupt mask, ...).

I made so kind of design for 4 years ago.

Thoma (without s )

Hi Thoma, (sorry about the extra s )

Thanks for the help.
Your diagram is exactly the layout I had in mind. Good to hear you also have done this already, any tips you might have would be great.

The part number is A3P060-VQG100. I have ordered a few from Mouser plus a Flash Pro 4 to program them with. I selected this family as they have flash memory, so I don't have to have external Eprom or similar.
I will be making my own prototype boards so any advice on ISP of these devices would be helpful. Which device did you use? Did you use a commercial development board?


Thanks,
Oli

Hi Oli,

The design was done on a Xilinx Spartan 2E device.
It was a full custom VXI board for a customer.

Concerning your project, as the FPGA is choosen, you have to take in consideration that you have only 71 I/O pins available.

I would say:
- count the required I/O pins to interface the ADC,
- then count the required I/O pins to interface the RAM and
- finally, with the remaining I/O pins, you have to imagine the processor interface (do not forget a interrupt signal, it is often useful).

Hope this help

If you need more advices, you can ask questions.

Thoma

Hi Thoma,

I can still change the FPGA if I wish, I just thought with there being so many choices, and not knowing too much about the subject, I should just buy a few and try them out.

I think 71 pins will do from rough calculations, but I will confirm this. I will dive into it all when the stuff arrives (the Flash Pro is on back order) and see where I get to. In the meantime I will get into the Verilog and simulation.

Thanks for all the advice so far it has been very helpful, I will undoubtedly be asking more questions later on.

Oli

Hi Thoma,

A quick question regarding clock generation. At the moment I am toggling a pin on the Pic32 to provide the ADC clock. This can only be done up to around 30MHz, and is not ideal.

What is the best way to generate a clock for the FPGA and/or the ADC - do I need a separate PLL/Clock Generator?
Also how do I change the clock rate easily while keeping sync with the Pic32?

I was thinking I can either run the ADC at full speed all the time and read samples according to the sample rate I want ( e.g. one read every n samples - this sounds like the best option to me), or I have to change the clock speed.

Oli

hi oli,

usually it is a good idea to connect at least a simple clock source (oscillator between 10 and 30 MHz) to the fpga. the fpga has an internal pll which can increase the frequency at the cost of some additional jitter. disadvantages of this solution are the jitter (still okay for your adc?) and that the pll can only be reconfigured by reconfiguring the complete fpga.

if you want to change the clockspeed at run time you can ether do a divide by n logic inside the fpga or use an external pll.

for the communication with the pic32 i have to few experience with the pic32

Hi Case23,

Thanks for the reply.
I was wondering about the PLL, the smaller proAsics(below 60K gates) don't seem to have one, so I was wondering how they generate the higher clock speeds. It's not really a problem though, as I ordered the 60K gate model.

The ADC is pretty sensitive to duty cycle and jitter, but I'll try it with the internal PLL and see how it goes, I'll probably keep it running at full speed and send one of every n samples to RAM, instead of trying to change the clock speed as this seems like an easier solution. If there are problems I can always change the logic, although the clock jitter will be harder to deal with if it causes problems. Do you know of any low cost ways to produce a low jitter clock? ( I am trying to keep the final price low, so stuff like TCXOs are too expensive really)

The pic32 communication is not a problem really, not sure why I mentioned that in my last post, wasn't thinking clearly.

Oli

Hi Oli,

Toggling a pin to obtain an ADC clock is a really bad idea because jitter appears and jitter on a ADC will appears as noise in the digitized signal spectrum.

What have you plan to use as PIC32 clock source?
In the case you use an external oscillator, with some precautions, you can use the OSC2 pin to clock also the FPGA.

If aliasing is not a concern, you can try with a DDS (http://www.fpga4fun.com/DDS.html) to generate several clock rates.

Again, taking one sample every n samples will produce aliasing. So if it is not a concern, why not.

A low jitter and low cost clock source could be:
- a DDS with a sine wave table (must run at very high speed),
- a really sharp filter @ half frequency (or less) of the DDS clock and
- a good comparator (to minimize the jitter).

With the A3P60, I would suggest to use some resources to build one or two DDS that run at 350 MHz.
The first one as system clock (50MHz or 100MHz) and the second one as ADC clock.

Hope this help

Thoma

Hi Thoma,

With the prototype board I have already built, I am usinig an external 20MHz crystal (with pic32 internal PLL to achieve 80MHz system clock) and then I am using an Output Compare peripheral (also tried toggling pin in code) to generate the clock. I built this board just to test the basic principle, and also as I am considering a slower speed version that only uses the pic32.

Using the Osc2 pin to drive the ADC sounds interesting - maybe I could use a comparator and filter here also? Though if we forget about the FPGA for a moment, how would I sync the reads properly? The slave Parallel Master Port takes 7 instructions to read on 8 bit value, so this would be too slow. If I do it faster, I cannot check the clock toggle, I would just have to hope it is in sync - I am thinking that internal delays may cause problems here.

Why will taking one sample every n samples produce aliasing? As long as the frequency measured is under half of the taken samples rate? I thought this was a reasonable alternative to changing the clock speed. If you know of a better way, I would be interested - I could also always sample at the maximum rate and then select what is displayed on the PC side (i thought this may be useful - to be able to "zoom" in on the waveform) but this may require a very large buffer to do properly.

I will have a good look at the DDS solution. What do you think of something like this?

http://uk.rs-online.com/web/search/searchBrowseAction.html?method=getProduct&R=463-836

Or this?

http://uk.rs-online.com/web/search/searchBrowseAction.html?method=getProduct&R=620-2173

Thanks again for the help.

Oli

Hi Oli,

Ok, you have already a board without a FPGA.

The filter is used to filter out the jitter produced by the DDS.

If we forget the FPGA for the moment then you did not provide enough information concerning the PIC32 part number and the ADC part number.

As the sampled signal is not only a sinusoid but also harmonics, interferences and noise. So, aliasing is always present when you sample a signal. Often, you can live with this situation. But sometimes, you will not observe the truth on an oscilloscope (DSO).

Concerning the choice of the DDS, I suggest to do that inside the FPGA.

Hope this help

Thoma

Hi Thoma,

Sorry, here are the part numbers - PIC32MX440F256H and ADS831

I understand that aliasing is always present, I thought you meant that taking one sample every n samples would cause aliasing by itself - but I see that aliasing would be possible with this technique. I am using a filter before the ADC and will look into other antialiasing techniques as I progress with the project. Seems like the ideal solution is to keep the ADC running at full speed, or I may even use oversampling to reduce the problem, although as I'm trying to keep the price down with RAM etc, some aliasing may have to be acceptable.

The parts in my last post are just alternative clock options, not to do with DDS, I was wondering what you thought of these as an alternative to DDS.

Oli