Products > Test Equipment
A High-Performance Open Source Oscilloscope: development log & future ideas
<< < (23/71) > >>
tom66:
Indeed, but the shame about the Zynq-030 is it's the only package option there in FBG484.

So, if you go for the cheapest 484 ball part, you are stuck with the -030, no route to upgrade.

You can go for the 676 ball part which also has -035 and -045 series variants. But now the BOM is larger, and you might not need the extra IO.  (The 400 ball part with the extra bank of the 7020 is enough for 2 x ADC interfaces + plenty of IO to spare, with an 8 layer board to route it all out.)

I'm still not convinced I need a Kintex part.  The current 7014S solution has been tested up to 1.25GSa/s which is the max I could get from HMCAD1511 before it lost PLL lock.  At least some of that is down to the PLL not having sufficient amplitude to meet the specification of the HMCAD ADC even at 1GHz.   That is also without any line training on the SERDES inputs and with the internal logic running at 180MHz,  ADC frontend running at 1/8th sample clock.  I do encounter timing issues above 200MHz causing periodic AXI lockup conditions though, I believe that is down to the lack of timing optimisation.  (Currently have a -4ns worst negative slack)

Really it depends on the goals for this project,  I never considered much more than 2.5GSa/s which could be achieved with a second ADC port and 128-bit internal bus on a Zynq 7020.    Moving to a Kintex might allow that to run at 250MHz with a 64-bit port,   but it's not as if there is a lack of fabric capacity now for a large bus.
tom66:

--- Quote from: nctnico on November 19, 2020, 10:20:48 pm ---
--- Quote from: tom66 on November 19, 2020, 10:09:47 pm ---Does anyone know what fabric is in the Zynq UltraScale?
It doesn't seem to be the same as the other 7 series devices, being on a 20nm process (Spartan/Artix/Kintex/Virtex-7 are all 28nm)

I'll have to give the DDR3 MIG a second thought.  But,  I don't think memory bandwidth is the ultimate limit here unless we were looking at sampling rates above 2.5GSa/s and those start requiring esoteric ADC parts with large BOM figures attached to them.

Could build a $3000 oscilloscope but would people really buy that in enough volume to make it worthwhile?

--- End quote ---
You also need to think about how long it will take to process the data. In my own USB design data came in at 200Ms/s but it could process acquired data at over 1000Ms/s. Say you have 4 channels with 500Mpts of memory with a maximum samplerate of 250Ms/s. Having a memory bandwidth of 1Gs/s would be enough for acquisition purposes. However in such a case you don't want the memory bandwidth between the processing part (whether inside the FPA or external) to become a bottleneck. Especially if the memory bandwidth needs to be shared between sampling and processing (think about double buffering here). Otherwise things like decoding and full record math will become painfully slow.

--- End quote ---

Yes so that is the goal: 32-bit DDR3 interface @ 667MHz, assuming a standard Zynq 7020 in enhanced speed grade, gets us up to 5.3GB/s. 

100,000 wfm/s at ~600 points per waveform is only a read back bandwidth of 60MB/s.  It's mostly the write bandwidth you need.  (You need the write bandwidth for the pre-trigger, assuming you want a (pre-trigger*nwaves) bigger than the blockRAM supports.)

Read bandwidth starts trending higher, strangely enough as you go to a longer timebase and the blind time reduces as a fraction of the active acquisition time.  At which point the current limitation is the CSI-2 bus to the Pi,  and the Pi itself has memory bandwidth issues.

I have the capability to implement a 4 lane CSI-2 peripheral,  which doubles bandwidth to around 3.2Gbit/s (400MB/s).  At which point we are nearing the capacity of PCI-e or USB3, although only in one direction.

One reason to go to 32-bit interface is that we then have the performance available to do a write-read-DSP-write-read cycle -- we can start using the DSP blocks to work on the waveform data we just acquired,  and then render it for the next frame.  That would allow the DSP fabric to be used in a (psuedo-)pipelined manner.    I'm working on a concept for the render-engine on the FPGA to see how practical it would be.
nctnico:

--- Quote from: tom66 on November 19, 2020, 10:21:23 pm ---Really it depends on the goals for this project,  I never considered much more than 2.5GSa/s which could be achieved with a second ADC port and 128-bit internal bus on a Zynq 7020.    Moving to a Kintex might allow that to run at 250MHz with a 64-bit port,   but it's not as if there is a lack of fabric capacity now for a large bus.

--- End quote ---
Maybe it is just a cost versus benefit (future growth) question. A Kintex would open the option to go for a design which has 4x 1Gs/s (maybe 1.25Gs/s to break the magic 500MHz barrier) without doing a major re-design of the PCB and internal FPGA logic.
free_electron:
cool ! . couple of ideas
-memory as dimm so i is user expandable
-cm4 , which you already mentioned.
-each acquisition channel as a pci card. ( not necessarly form factor. ) the beauty of that is that you can make a machine that has 1,2,3,4,5,6,7,8,9 whatever channels you need. just plug in more cards. there are pci hub chips avaialble.
nctnico:
The thought of using PCIexpress to aggregate more channels over seperate boards has crossed my mind too but you'll need seperate FPGAs on each board and ways to make triggers across channels happen. You quickly end up with needing to time-stamp triggers and correlate during post processing because the acquisition isn't fully synchronous.
Navigation
Message Index
Next page
Previous page
There was an error while thanking
Thanking...

Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod