Fast ADC projects

r.miller 2018-07-17 11:12:14 UTC #21

It's helpful to know that DBG1 is intended as a signal from the STM32 to the Ice40. But suppose someone looking at the schematic sees the connection between DBG1 on the Ice40 and the status LED and makes a blinky circuit flashing the LED from the ICE40. If iceboot is running on the STM32 outputting HIGH or LOW to its DBG1 connection, will that be a Bad Thing? Should iceboot maybe just float DBG1 once the Ice40 is programmed?

I know about the Ice40 CDONE pin (65), which signals programming complete and can also be used as a GPIO for the programmed circuit. That's the source of one signal labelled DONE on the schematic. But Ice40 pin 52 is also labelled DONE. What's that connected to?

r.miller 2018-07-17 12:53:00 UTC #22

Actually, looking at the Lattice programming manual, CDONE as a user output is only applicable to the Ice40-LP part. For the HX, it's pulled HIGH after successful programming.

Folknology 2018-07-17 20:33:22 UTC #23

From memory the CDONE is an open drain output from the Ice40, thuis it does not drive it high, rather it stops pulling it down, it actually goes high of sorts via the pullup led/resistor.. If you use 'DONE' in your Verilog it should be configured as pullup active low it could then be used in your Verilog as a trigger/interrupt like signal back to the STM32.

Folknology 2018-07-17 20:39:33 UTC #24

DBG1 should not be driven from the Ice40, it should be used as an input or just hi-z, it was never intended to drive the status led which belongs to the STM32. Unless you change the firmware and Hi-Z it from the STM32 side you should not drive it from the Ice40.

Folknology 2018-07-17 20:44:42 UTC #25

CDONE is physically connected to 'DONE' (GBIN4 on Ice40) bothe are connected to the STM32 and the Done LED via a resistor which creates a pullup. The STM32 uses this as an input pin to detect the CDONE pulldown or optionally later (after programming) a pulldown state driven from user Verilog..

tbalon 2018-07-18 15:14:37 UTC #26

I have been able to use the the DBG1 output from my verilog code to signal the STM32 that data was ready for processing. I used the arduino package and set the LED_BUILTIN(DBG1) with mux_disabled(), as an INPUT. I changed the variants.cpp to allow interrupts on the pin so now I get an interrupt when data is ready and I used the spi_slave.v on the FPGA with the STM as master to move the data I collect using the ADC to the STM chip.

So far it all seems to work very nicely.

lawrie 2018-07-18 16:04:12 UTC #27

You could use QSPI master on the STM32 and the QSPI slave on the FPGA, which is faster and you wouldn't need to disable the mux. See https://github.com/millerresearch/arduino-mystorm/tree/master/libraries/QSPI/examples/QSPIswtoleds and https://github.com/lawrie/verilog_examples/tree/master/fpga/qspiplay and https://forum.mystorm.uk/t/arduino-sd-card-music-player/444/6.

Do you just get one byte from the FPGA when you get an interrupt? I am looking at doing similar things and notice that our Arduino SPI implementation does not implement slave mode (but other variants of the STM32 do), and neither does @r.miller's QSPI library. Slave mode would be more convenient as you could receive data when it was ready without using an interrupt.

lawrie 2018-07-18 16:19:42 UTC #28

Also, is DBG1 the best pin to use for the interrupt? I was thinking that one of the two button pins might be better for that, as they already seem to allow interrupts, and are connected to both chips. They are used by the SD card, though, if you were wanting to use that.

tbalon 2018-07-18 16:19:52 UTC #29

Yes, I thought about using quad-spi.

I'm collecting data from my 8-bit sample from my ADC at 100Mhz. (one read every cycle). I'm writing it to SRAM every other cycle (storing 2 samples - 16-bit). I'm collecting 20us of data so 16KBytes / 8KB words.

My STM32 acts as SPI Master and is clocking the SPI bus at 10Mhz. The Arduino code just starts a transaction and goes into a loop calling SPI.transfer16() .. I used 16-bit words since the SRAM is 16-bit. I don't care too much about disabling the mux as I have a 8-LED PMOD I used to show status.

I will most likely use a pre-scaler on the ADC clock and allow the STM to control the sample rate and buffer size. I don't anticipate the buffer ever being larger than about 16K bytes, so 8K SPI transfers. Right now that takes about 20 ms. I was dumping the data from the FPGA over the UART before.

tbalon 2018-07-18 16:21:53 UTC #30

I was using DBG1 based on my conversation with Al prior to purchasing the board. DBG1 is as good as any.

r.miller 2018-07-19 09:35:04 UTC #31

Lattice manual says CDONE has a "permanent, weak internal pull-up resistor", but recommends an internal pullup to VCC as well. I understand now that the LED resistor serves that function.

r.miller 2018-07-19 10:10:00 UTC #32

As far as I can see, the STM32 chip doesn't support QSPI slave mode. The chip does support slave mode on the single SPI interfaces, but as you say, the driver library underlying our Arduino package only implements master mode. It could be added with some unknown amount of effort. Or a different library could be used (eg STM32Cube) instead of Arduino.

tbalon 2018-07-28 15:58:06 UTC #33

I'd like to experiment with my fastADC project to allow for adding a delay of a few ns post trigger before reading the ADC. Right now I sample every 10ns but I'd like to sample using an equivalent time sample approach using a PLL. My idea is that on each 10ns trigger, to delay by N PLL cycles before reading the ADC. If the PLL were at 400Mhz, I could use this to record a few extra samples between my main 10ns clocks. (ETS)

My question is, how can I generate say a 400Mhz or 1Ghz PLL ? The documentation suggests this is possible but all the examples show a slower PLL than the input clock. When I try to generate a 400Mhz clock using ipll, it complains that the target is out of range and that the max PLL output would be 275Mhz. I could use a 200Mhz PLL but I was hoping to use a much higher ( 1Ghz ).

Folknology 2018-08-07 09:14:25 UTC #34

I'm pretty sure that both 400mhz and 1GHz is well outside the fabric range for Ice40.. Check the datasheet for max capability

tbalon 2018-08-07 22:11:19 UTC #35

Yeah, I was confused by the vco spec, 275 Mhz is the max PLL output. I wasn't going to run the FPGA at more than 100Mhz, I just wanted to generate a fast clock to use as a delta offset from my 100mhz clock. I would sample every 10ns + delta t where t runs from 1 to 9 ns. I waned to try and implement an equivalent time sample rate higher than the 100Msps so I could get better resolution on higher freq signals ( f > 20 Mhz )

I think I will try using an external trigger circuit.

lawrie 2018-08-19 07:19:33 UTC #36

Have you seen that Joel Holdsworth now has a live stream that follows on from that video:

afiskon 2018-08-20 13:08:59 UTC #37

No I missed it because it was published on a separate channel, OpenTechLab Live. Thanks!

lawrie 2018-08-30 17:21:15 UTC #38

Here is one myStorm with an AN108 using direct digital synthesis to generate a sine wave. The frequency is controlled by the rotary switch and the amplitude by the potentiometer on the AN108 DAC. The output is fed in via BNC probes to the flashy board on the second BlackIce II board.

This is the Direct Digital Synthesis code:

github.com

lawrie/verilog_examples/blob/master/fpgafun/dds/dds.v

module dds(
  input clk, 
  output DAC_clk, 
  input quadA,
  input quadB,
  input button,
  output[7:0] DAC_data
);

localparam BITS = 24;

assign DAC_clk = clk; // 100Mhz

reg [BITS-1:0] phase_acc;

//wire cnt_tap = cnt[7];
//assign DAC_data = {8{cnt_tap}};  
//assign DAC_data = cnt[7:0];   
//assign DAC_data = ~cnt[7:0];  
//assign DAC_data = cnt[8] ? ~cnt[7:0] : cnt[7:0];

This file has been truncated. show original