Author Topic: 6GSps FPGA to Memory Handling...  (Read 12266 times)

0 Members and 1 Guest are viewing this topic.

Offline ali_asadzadeh

  • Super Contributor
  • ***
  • Posts: 1896
  • Country: ca
Re: 6GSps FPGA to Memory Handling...
« Reply #50 on: April 25, 2018, 06:26:30 am »
Quote
torrent is invented by man, based on Laws created by God. anyway, torrent is of no good without a license provided.. ;)
If you search a bit more, under 30 seconds, you could get the torrents with the license too, with the latest version! ;)

almost about 70% of all internet traffic is torrents

https://en.wikipedia.org/wiki/BitTorrent

But if the project is commercial, I would suggest to buy the tools and help them, create better products for us :)
ASiDesigner, Stands for Application specific intelligent devices
I'm a Digital Expert from 8-bits to 64-bits
 
The following users thanked this post: Mechatrommer

Online MechatrommerTopic starter

  • Super Contributor
  • ***
  • Posts: 11537
  • Country: my
  • reassessing directives...
Re: 6GSps FPGA to Memory Handling...
« Reply #51 on: April 25, 2018, 08:40:25 am »
If you search a bit more, under 30 seconds, you could get...

if anything you want to say, say it in.... PM!
Nature: Evolution and the Illusion of Randomness (Stephen L. Talbott): Its now indisputable that... organisms “expertise” contextualizes its genome, and its nonsense to say that these powers are under the control of the genome being contextualized - Barbara McClintock
 

Offline Scrts

  • Frequent Contributor
  • **
  • Posts: 797
  • Country: lt
Re: 6GSps FPGA to Memory Handling...
« Reply #52 on: April 25, 2018, 05:54:15 pm »
It looks like the ECP5 DDR3 controller can do up to a 64-bus at 800Mbps. Which is 6.4Byte/s.

I don't understand this discussion... The idea is push 6Gbps of data into the memory and then what? Let's say you can achieve that speed, but you have absolute zero time then to read and process that data. The bus will always be busy writing.
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3137
  • Country: ca
Re: 6GSps FPGA to Memory Handling...
« Reply #53 on: April 25, 2018, 06:01:04 pm »
I don't understand this discussion... The idea is push 6Gbps of data into the memory and then what? Let's say you can achieve that speed, but you have absolute zero time then to read and process that data. The bus will always be busy writing.

Not necessarily. You may acquire event(s) of various duration and read them back later. It all depends on the application.
 

Online MechatrommerTopic starter

  • Super Contributor
  • ***
  • Posts: 11537
  • Country: my
  • reassessing directives...
Re: 6GSps FPGA to Memory Handling...
« Reply #54 on: April 26, 2018, 12:07:51 am »
I don't understand this discussion... The idea is push 6Gbps of data into the memory and then what? Let's say you can achieve that speed, but you have absolute zero time then to read and process that data. The bus will always be busy writing.
since you asked, lets open the worm can a little bit more. as i said earlier, during capture, the circuit will get input data to adc->fpga->ram at 6GSps until 50-100MB of RAM is filled up. after that, its called blind time, no capture but processing the data RAM->processor->display. how long is this blind time? its unspecified and mainly will depends on how fast post-processing is made. but i have the feeling that it is 99.999% certain that post processing will take alot slower to complete than capture rate, so any funny idea such as double buffering will be inapplicable here, except if i have to tolerate super expensive solution such as massive parallel processing involving super expensive fpga or massive amount of them marched/arranged on the pcb like brain cells. there are few possibilities during this "blind time":

a) another mcu or fpga is connected to the same bus where writing to the RAM from FPGA is made during capture, but this time fetching the data out of RAM from the same bus for FFT processing (at slower speed if cannot be fast). or if write and read can be done concurrently for the RAM from different bus, then so be it. i'm not sure if this even possible, i've never done this.

b) the same fpga which wrote to the RAM earlier will fetch back the RAM content for FFT processing, or maybe process the captured data concurrently (while capture in progress) but this will depend on algorithm used.

c) same as (a) except reading bus is from another pin of the 1st (capture) fpga. ie for reading RAM, mcu has to command the capture FPGA to read the RAM and send the content to the another output bus to mcu or another fpga.

i should sketch something but i'm in the office right now, MechCAD is a bit difficult from here here we go (see attached). anyway this is what i can think of from spherical dead cow point of view. as for RAM, what i prefer is, it should not have the "refresh cycle" or internal housekeeping job that blocked writing to RAM. if capture fpga has to wait for the RAM to do something then its not good (unless the condition can outrun the capture rate). i prefer a RAM that we simply set the address either to serial or parallel pin, and incremented by shift register or something, if RAM can automatically increment the address internally without fpga doing anything, then this is the ideal RAM i'm looking for. another thing is how to fetch data from ram, is from the same bus? or is ram have another pin for output, this i need to study later and will impact design decision, this is another deeper into the worm can or the spherical dead cow gray matter stuffs.

feel free to share thoughts, my intention for this thread is already answered, ie the question of "whether a fpga can do 6GSps". My best regards to you all.
Nature: Evolution and the Illusion of Randomness (Stephen L. Talbott): Its now indisputable that... organisms “expertise” contextualizes its genome, and its nonsense to say that these powers are under the control of the genome being contextualized - Barbara McClintock
 

Offline C

  • Super Contributor
  • ***
  • Posts: 1346
  • Country: us
Re: 6GSps FPGA to Memory Handling...
« Reply #55 on: April 26, 2018, 01:07:12 am »

You have many options if you break project apart some.

First as stated you could use four sync's fpga's as input.

Then you could have many outputs on each input fpga. With a small buffer in input fpga you could output packets. A packet would be a chunk of time.
With two ports, your rate drops to 3GSps, with four ports to 1.5GSps.
This has many benefits. First the reduced data rate helps a lot. If the input fpga can do packets you can start processing each packet when received.
When you want to goto 12GSps, you just need to get the input split into two 6GSps to have a working system.

If you can not do packets, then you most likely still have to stop the capture.

When you split the four ADC to separate fpga's, it becomes a small step to do more ADC's

One FPGA puts some hard limits in place. The many fpgs's way is something that can scale. likely with lower cost fpga's.

C

 

Online MechatrommerTopic starter

  • Super Contributor
  • ***
  • Posts: 11537
  • Country: my
  • reassessing directives...
Re: 6GSps FPGA to Memory Handling...
« Reply #56 on: April 26, 2018, 02:16:06 am »
The problem with 4 fpga is how to synch them in 6GSps (interleaving) resolution with acceptable jitter figure? That can be a whole lot chapter for that, i will need the clean 6GHz runs on the pcb traces. If we do it in 1 fpga, we can say use 50 or 60 MHz TCXO connected close to a fpga, and do the 100x multiplication in the chip, can?  If not, i may learn from Rigol circuit because that what they did. Rigol is my living proof that this concept can be done.

Edit:  or wait, we can use adf4355 synthesizer for this, yes 4 fpga each running at 1.5GHz can be another option... :-+
« Last Edit: April 26, 2018, 02:24:24 am by Mechatrommer »
Nature: Evolution and the Illusion of Randomness (Stephen L. Talbott): Its now indisputable that... organisms “expertise” contextualizes its genome, and its nonsense to say that these powers are under the control of the genome being contextualized - Barbara McClintock
 

Offline C

  • Super Contributor
  • ***
  • Posts: 1346
  • Country: us
Re: 6GSps FPGA to Memory Handling...
« Reply #57 on: April 26, 2018, 03:02:12 am »
Now packets

When you have sync, you have many streams of data.
If you have 8-bit data then to get transparent data you need an extra bit.
The 9-th bit could mark the start of a packet.
The other 8-bits could still contain sample data.
The 9-th would give you a time sync marker.

A different way would be the 9-th bit marking the difference between command/status or data.

When you look at current bit streams you find 8b-10b or something like this and you can get the sync from this.
with fpga you might convert to equal of one of these streams and still use a parallel connection. You can gain speed by increasing the 8b to larger number with smaller scale of the 10b. You might think of this as shifting from byte data to 64-bit data or larger.

The parallel connection could make displaying data easer. Think of many bit planes making up actual color display data. X bits input gets mapped to a color pixel. You can process each bit plane in parallel. Your menu or other display data could be additional planes.

Again you get to scale.

C
 
The following users thanked this post: Mechatrommer

Offline Berni

  • Super Contributor
  • ***
  • Posts: 4923
  • Country: si
Re: 6GSps FPGA to Memory Handling...
« Reply #58 on: April 26, 2018, 06:09:51 am »
You likely want to go with the "Option C" where the MCU talks to the FPGA

The DDR3 memory controller will usually have the capability to have multiple buses accessing it (If not you can mux the bus to the controller inside the FPGA very easily). This extra bus can then be used to allow the MCU access to all of the DDR3 memory. A lot of MCUs have external memory interfaces that are mostly meant to give the MCU capability to expand its memory using a external RAM chip. What you can do is hook up a FPGA to the same pins and have it act like its a SRAM chip. That way the MCU will send all read/write operations on that area of memory out into the FPGA. There you can then interpret the simple SRAM memory bus as read/write commands and translate them into read/write commands to the DDR3 controller. As a result you have memory mapped the entire DDR3 memory into the MCU where its processor can access it in the same was as it would access its main internal RAM.

As far as FFT goes if you need it calculated fast then FPGA is the place to do it. A decent sized FPGA will have about 10 to 1000 times faster integer math performance in FFT compared to ARM microcontrollers. As for doing FFT on the fly as its coming out of the ADC that's only possible on short chunks like for example 1024 samples at a time. The reason is that the way FFT works means it needs the first and last data sample in the  beginning of the calculation so you need to hold the entire FFT length in memory before you can start calculating it. So you will need to shuffle things in and out of main memory to calculate things like 100Mpt long FFTs

If you also want to draw to the display very fast too (like 60fps) then it likely also makes sense to move the LCD and connect it directly to the FPGA too while just having the MCU continue to sit on that SRAM emulated memory bus. That way you can built a sort of custom graphics card in the FPGA that takes the waveform data and turns it into a bitmap picture. The MCU in the meantime can also fill up a framebuffer with the image of the menus that the FPGA merges on the fly with the waveform bitmap while sending it to the LCD.
 
The following users thanked this post: Mechatrommer

Offline asmi

  • Super Contributor
  • ***
  • Posts: 2728
  • Country: ca
Re: 6GSps FPGA to Memory Handling...
« Reply #59 on: April 26, 2018, 11:21:12 am »
If you also want to draw to the display very fast too (like 60fps) then it likely also makes sense to move the LCD and connect it directly to the FPGA too while just having the MCU continue to sit on that SRAM emulated memory bus. That way you can built a sort of custom graphics card in the FPGA that takes the waveform data and turns it into a bitmap picture. The MCU in the meantime can also fill up a framebuffer with the image of the menus that the FPGA merges on the fly with the waveform bitmap while sending it to the LCD.
This begs the question - what's the reason to have external MCU as opposed to using a softcore like Microblaze (which is free BTW for 7 series devices)? That softcore natively supports AXI4 bus which is also supported by memory controller, and you can implement input datapath as a AXI Master and connect it to the same memory controller interface (via interconnect), or you can implement it as a AXI-Stream master and use one of DMA controllers (also free IPs) to send the data into memory.
 
The following users thanked this post: Mechatrommer

Offline Berni

  • Super Contributor
  • ***
  • Posts: 4923
  • Country: si
Re: 6GSps FPGA to Memory Handling...
« Reply #60 on: April 26, 2018, 01:24:00 pm »
This begs the question - what's the reason to have external MCU as opposed to using a softcore like Microblaze (which is free BTW for 7 series devices)? That softcore natively supports AXI4 bus which is also supported by memory controller, and you can implement input datapath as a AXI Master and connect it to the same memory controller interface (via interconnect), or you can implement it as a AXI-Stream master and use one of DMA controllers (also free IPs) to send the data into memory.

That is also a perfectly valid way of doing it.

The reasons for using an external MCU might be:
- Cheap
- Higher performance than a softcore (You can get 400MHz ARM MCUs with tons of peripherals)
- Perhaps great OS support on that particular microprocessor
- Familiar development environment if you used one for a long time.
- Low power modes made easier
- Saving on development time if you haven't worked with softcores before.
- Saving resources inside the expensive FPGA if things get tight.

What you end up choosing depends entirely on your particular situation at hand.
 

Offline C

  • Super Contributor
  • ***
  • Posts: 1346
  • Country: us
Re: 6GSps FPGA to Memory Handling...
« Reply #61 on: April 26, 2018, 01:33:23 pm »
Mechatrommer

You might want to keep differential in mind.

High speed digital logic, differential.

The high speed ADC I have looked at, differential

The high speed analog, differential.

You should think of not crippling input an do full differential from input.

C
« Last Edit: April 26, 2018, 01:34:56 pm by C »
 

Offline asmi

  • Super Contributor
  • ***
  • Posts: 2728
  • Country: ca
Re: 6GSps FPGA to Memory Handling...
« Reply #62 on: April 26, 2018, 01:59:31 pm »
- Cheap
Softcore is $0 so MCU is definitely more expensive. Not to mention additional board space which also costs $$.
- Higher performance than a softcore (You can get 400MHz ARM MCUs with tons of peripherals)
If you need an MPU, you can use Zynq. As for peripherals - Xilinx provides free IPs for most peripherals you might find inside typical MCUs. Or you can implement several softcores if you need more horsepower.
- Perhaps great OS support on that particular microprocessor
Softcore can be configured to have MMU and there is a Linux build for that core. If you want to use something like Windows CE (which is quite popular as creating GUI is easier with it), you will need a full-blown MPU like ARM Cortex-AXX. Again, Zynq will be very fitting here with it's A9 hard MPU(s) and it will eliminate all layout-related hassle of making MCU-to-FPGA interface.
- Low power modes made easier
Low power and FPGAs don't tend to coexist peacefully as latter usually aren't that low power. For example Artix-100T device can consume up to 6 Amps just on it's Vccint rail. Same goes for DDR3 - it consumes quite a bit of power because of termination. My board with x16 DDR3L (low power version!) consumes up to 0.5 Amp from Vccddr rail (1.35V).
- Saving on development time if you haven't worked with softcores before.
If you choose to use OS, then it doesn't really matter if it's running on a softcore or on some other platform.
- Saving resources inside the expensive FPGA if things get tight.
Microblaze in MCU configuration takes less than 1k LUTs, so even the smallest Artix-A12 can fit a dozen of them. Implementing a SRAM-like interface is also going to take some resources, so it might end up being a wash.

Online MechatrommerTopic starter

  • Super Contributor
  • ***
  • Posts: 11537
  • Country: my
  • reassessing directives...
Re: 6GSps FPGA to Memory Handling...
« Reply #63 on: April 26, 2018, 02:14:44 pm »
You should think of not crippling input an do full differential from input.
:-\ :-\ :-\

Microblaze in MCU configuration takes less than 1k LUTs, so even the smallest Artix-A12 can fit a dozen of them. Implementing a SRAM-like interface is also going to take some resources, so it might end up being a wash.
a dozen? well thats interesting, its like having duodeca-core cpu running FFT thats fantastic. but well, here is the first time i heard the name Microblaze, i cant say negative or positive about it, the only think in mind is how am i going to program a GUI for it, what IDE etc.. there are a lot to catch up about this stuffs.
Nature: Evolution and the Illusion of Randomness (Stephen L. Talbott): Its now indisputable that... organisms “expertise” contextualizes its genome, and its nonsense to say that these powers are under the control of the genome being contextualized - Barbara McClintock
 

Offline C

  • Super Contributor
  • ***
  • Posts: 1346
  • Country: us
Re: 6GSps FPGA to Memory Handling...
« Reply #64 on: April 26, 2018, 02:54:11 pm »
When you start looking at differential analog, one set of circuits you often find in examples is going from or to single ended, often just a resistor.
If you think, a circuit driven from single ended input has no common mode at this point. The big advantage here for differential is getting the return signal path isolated from other signals like power supply noise.

Keep thinking on what could be big picture.
When you have ADC input, could be small change to logic input. It might also be a small change to get DAC or logic output.

For ADC you have collect data, display data some way or both.

When you have input & output, then you have network analyzer.

With the chips that lets you adjust timing, you can have many things working in sync. Even programming can get easer when working on separate but parallel.
 
Have you looked at Current mode analog. Cures some things that Voltage mode has problems with.

C
« Last Edit: April 26, 2018, 02:59:42 pm by C »
 
The following users thanked this post: Mechatrommer

Offline asmi

  • Super Contributor
  • ***
  • Posts: 2728
  • Country: ca
Re: 6GSps FPGA to Memory Handling...
« Reply #65 on: April 26, 2018, 03:09:34 pm »
a dozen? well thats interesting, its like having duodeca-core cpu running FFT thats fantastic. but well, here is the first time i heard the name Microblaze, i cant say negative or positive about it, the only think in mind is how am i going to program a GUI for it, what IDE etc.. there are a lot to catch up about this stuffs.
That's the name of the softcore developed by Xilinx and offered for it's FPGAs. They are often used to orchestrate hardware when doing everything in hardware is not feasible, as well as some advanced scenarios like partial reconfiguration, where some of the hardware is swapped in and out as required. It's also usually used to react to user input as usually you don't need fast clock speed for that because input is going to be very slow anyway.
Xilins also provides free IPs for Mutex and Mailbox to facilitate inter-processor communication if you want to implement a multi-core SMP system, as well as some IPs to implement triple modular redundancy if that is your thing (of course you'd better match this will memory bus with ECC). Like I said above, there is a lot of things you can do using IPs that are provided for free, and that is a distinct advantage Xilinx have over competitors, which all only offer paid IPs.
 
The following users thanked this post: Mechatrommer

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3137
  • Country: ca
Re: 6GSps FPGA to Memory Handling...
« Reply #66 on: April 26, 2018, 04:05:16 pm »
Like I said above, there is a lot of things you can do using IPs that are provided for free, and that is a distinct advantage Xilinx have over competitors, which all only offer paid IPs.

Xilinx promotes so called BD design flow where you design is graphically represented as interconnected blocks. Most blocks are IPs. If you need something customized, you create your own block. This looks like some sort of virtual Arduino on steroids - you can assemble practically anything in a matter of few hours (excluding compile time). So, if you like such style, it'll be very easy for you.
 

Offline C

  • Super Contributor
  • ***
  • Posts: 1346
  • Country: us
Re: 6GSps FPGA to Memory Handling...
« Reply #67 on: April 26, 2018, 05:47:45 pm »
Xilinx promotes so called BD design flow where you design is graphically represented as interconnected blocks. Most blocks are IPs. If you need something customized, you create your own block. This looks like some sort of virtual Arduino on steroids - you can assemble practically anything in a matter of few hours (excluding compile time). So, if you like such style, it'll be very easy for you.
I would think this would be a great time saver if you can work with it.

Is coping a Rigol DSO a good idea?
What you get from Rigol is down to a cost often for a savings of cents.

Think GW Instek have shifted their foundation to Xilinx Zynq.

One scope I have read about is using two ADC's for 1 G. The ADC that supports 4 channels at 250 M so if not down to cost could be an 8 channel input.

One of the tear-downs had a separate analog board.

The more modules you create, the more options for the future. Can become easy if each channel is a clone.

Data packets with a time stamp lets you put packets in order.
Time stamps can be a simple binary counter that rolls over to 0.
Your mouse is based on a small counter for direction. With PC reading often, distance is unlimited.

I keep thinking if you keep it simple so that it can scale, you will save time building and have easer job in future to scale. The many modules makes it easer to test and for future changes or a different use.

Look at micro controller and how things have changed.
Was SPI or Jtag now often it looks like a disk drive.
A good CAN buss controller these days can get first firmware over CAN bus. Keep in mind that this could be the best/easiest bus for operator interface. You can have many and it is still just CAN packets if you do not let yourself get barrier in someone's idea of a higher level.

My look at Xilinx Zynq being inside the FPGA could make a lot of things simpler/easer then a CPU outside FPGA, and you don't lose capability for a CPU outside.


C
 

Online MechatrommerTopic starter

  • Super Contributor
  • ***
  • Posts: 11537
  • Country: my
  • reassessing directives...
Re: 6GSps FPGA to Memory Handling...
« Reply #68 on: April 26, 2018, 06:03:35 pm »
Data packets with a time stamp lets you put packets in order.
Time stamps can be a simple binary counter that rolls over to 0.
i dont think timestamp or extra bit is necessary, esp in high speed rate it can degrade performance quite significantly, in the design we usually set the ordering fixed, ie this is fpga1 that goes 1st, and then this is the second fpga and so on. when fetching the data, we do by the same ordering. whats troubling about timestamping is the jitter generated by the (interleaved) clock since nyquist theory requiring capture interval to be the same from point to point, otherwise the true signal cannot be reconstructed faithfully. but in order to handle for jitter, other mechanism or external (maybe analog) monitor/calibration circuit should be made since fpga cant detect this, it will be happy to do the job when the clock goes high or low without any sense of temporal axis well, this can be for another discussion in another thread.
« Last Edit: April 26, 2018, 06:18:21 pm by Mechatrommer »
Nature: Evolution and the Illusion of Randomness (Stephen L. Talbott): Its now indisputable that... organisms “expertise” contextualizes its genome, and its nonsense to say that these powers are under the control of the genome being contextualized - Barbara McClintock
 

Offline C

  • Super Contributor
  • ***
  • Posts: 1346
  • Country: us
Re: 6GSps FPGA to Memory Handling...
« Reply #69 on: April 26, 2018, 07:16:20 pm »

sorry did not state that very well.

Say you have 4 ADC's at X sample rate.

You get better results if all take sample at exactly the same time.
For example one is volts, one current, if not same time watts has an error.

With a mux input first step is de-mux data to process.
With parallel data input you can assume time sync.

If you break each stream into blocks, then you can parallel process. This is again assuming that each takes the same time to process.
Adding a time stamp & channel at start of each block does not change sample rate, just output data rate for short time. You now have needed information to rebuild original streams from original or computed data from the blocks of data.
This overhead of this decreases the larger the data block.

With time stamps in stream, many options become possible as you have time to link data and not just position.
With processing you often get many streams that need to be in time sink with original.
Your source is very high speed data, to decrease time not sampled you need more parallel processing cheap.

Important thing is get the best data you can at start of chain and not be so crippled in hardware.

While you are thinking of getting time sync of 4 ADC, you might think of time sync of two or more of what you are building.

With this in mind, easy be for another discussion in another thread.

C

 

Offline Berni

  • Super Contributor
  • ***
  • Posts: 4923
  • Country: si
Re: 6GSps FPGA to Memory Handling...
« Reply #70 on: April 26, 2018, 07:43:08 pm »
I would think its the easiest to simply phase shift the clock signal to the ADC and the FPGA processing it as a whole while also having a sync pulse that each FPGA samples along with the ADC data.

At these sort of speeds you can already generate the delay by simply making the clock take long squiggly route to that last ADC. Additionally digital clock delay chips can be put in the path or a few pF of capacitance placed on the clock line in order to fine tune the delays to be exactly 1/4 the clock period.

Additionally if the ADCs don't have the required analog bandwidth you might need to have a separate sample and hold in front that can take bites at full bandwidth and hold them steady for the ADC to convert correctly. Having 10GSPS is not very useful if your bandwidth is only 100MHz for example.
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3137
  • Country: ca
Re: 6GSps FPGA to Memory Handling...
« Reply #71 on: April 26, 2018, 08:28:07 pm »
At these sort of speeds you can already generate the delay by simply making the clock take long squiggly route to that last ADC.

Not that long - slightly less than an inch (22-25 mm) for 6Gs/s :)

Many ADCs will have an ability to adjust phase through SPI or alike. Thus, the delay can be inserted and calibrated at run time with great precision (such as 10 ps). You can use a fast comparator to produce calibration edges.

 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7661
  • Country: ca
Re: 6GSps FPGA to Memory Handling...
« Reply #72 on: April 27, 2018, 01:42:06 am »
Make sure you get top notch, impedance controlled PCBs with this project.  Plus, PCB cad software which will calculate and manage delay routing.  Even with this, you will most likely need to have calibrated delay timing settings for each PCB and have a test jig with reference signals to perform calibration.  Also, don't forget about temperature drift.

I'm not saying it's impossible, it's just going to be difficult to make many of these with such tight tolerances across 4 FPGA to weave those ADCs the way you want.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf