Products > Test Equipment

SDG6052X waveform memory size

<< < (4/5) > >>

gf:

--- Quote from: egonotto on October 29, 2024, 12:24:39 pm ---
--- Quote from: gf on October 29, 2024, 12:10:43 pm ---
--- Quote from: suspension on October 29, 2024, 08:43:24 am ---in trueARB, is 300 the max sampling rate (MSps) or maximum bandwidth of the signal fundamental?

--- End quote ---

It is the maximum "virtual" sampling rate. TrueArb is not DDS. It reproduces the given wavetable 1:1 (i.e. with phase increment of 1 sample) at a virtual sample rate of your choice (maximum 300MSa/s). The resulting discrete-time signal (stream of samples) is then resampled/interpolated by the engine from the virtual sample rate to the output sample rate of 1.2 GSa/s.

--- End quote ---
Why would you resample the signal? It certainly won't get any better.

--- End quote ---

Because the DAC sample rate is still fixed, and so is the reconstruction filter which must fit with the sample rate. An analog high-order reconstruction filter which is adjustable over many decades would be very difficult to realize. OTOH, an adjustable digital resampling filter is quite feasible.

EDIT: However, in the sense of the Nyquist–Shannon sampling theorem, I find linear interpolation suboptimal, and sin(x)/x interpolation seems to be only supported by SDG7000A.

TurboTom:

--- Quote from: suspension on October 29, 2024, 10:50:40 am ---...
But then, why did they have external DDR in earlier models?

--- End quote ---

That's a good question. Since the SDG6000X series had been designed more than seven years ago when Siglent just moved to the Zynq SoC plaform on their (back then) most recent products, maybe they had little experience and designed the SDG6000X better "safe than sorry" with dedicated sample memory. Only later on they may have realized that a direct sample data transfer from SoC memory through the sample engine FPGA to the DAC works okay at 1.2GBytes/s (plus overhead) to meet their instrument's specs.

Standard waveforms may reside completely within the Kintex's Block RAM or may possibly be generated on-the-fly, so they can be transfered to the DAC at a higher rate.

Or they may have thought of certain software extensions that may have required dedicated sample memory and that they discarded further down the line. Probably only Siglent engineers can answer this question accurately. Anyway, I think it's safe to say that it certainly went along with some cost-cutting measures from the management department...  ::)

egonotto:

--- Quote from: gf on October 29, 2024, 12:49:02 pm ---
--- Quote from: egonotto on October 29, 2024, 12:24:39 pm ---
--- Quote from: gf on October 29, 2024, 12:10:43 pm ---
--- Quote from: suspension on October 29, 2024, 08:43:24 am ---in trueARB, is 300 the max sampling rate (MSps) or maximum bandwidth of the signal fundamental?

--- End quote ---

It is the maximum "virtual" sampling rate. TrueArb is not DDS. It reproduces the given wavetable 1:1 (i.e. with phase increment of 1 sample) at a virtual sample rate of your choice (maximum 300MSa/s). The resulting discrete-time signal (stream of samples) is then resampled/interpolated by the engine from the virtual sample rate to the output sample rate of 1.2 GSa/s.

--- End quote ---
Why would you resample the signal? It certainly won't get any better.

--- End quote ---

Because the DAC sample rate is still fixed, and so is the reconstruction filter which must fit with the sample rate. An analog high-order reconstruction filter which is adjustable over many decades would be very difficult to realize. OTOH, an adjustable digital resampling filter is quite feasible.
....

--- End quote ---

Hello,

that sounds very reasonable.

I have now made a waveform with 15 times 1 and 15 times 0.
If you sample it at 300 MHz you get 60 pts 1 and 60 pts 0 (regarding 1.2 GHz)
But if you sample at 297.5 MHz you get 60.5 pts 1 and 60.5 pts 0.
With 10 s persistence at 297.5 MHz, shouldn't you see somewhat broader edges?

I don't see any difference.
Best regards
egonotto

suspension:

--- Quote from: TurboTom on October 29, 2024, 01:10:04 pm ---
--- Quote from: suspension on October 29, 2024, 10:50:40 am ---...
But then, why did they have external DDR in earlier models?

--- End quote ---

That's a good question. Since the SDG6000X series had been designed more than seven years ago when Siglent just moved to the Zynq SoC plaform on their (back then) most recent products, maybe they had little experience and designed the SDG6000X better "safe than sorry" with dedicated sample memory. Only later on they may have realized that a direct sample data transfer from SoC memory through the sample engine FPGA to the DAC works okay at 1.2GBytes/s (plus overhead) to meet their instrument's specs.

Standard waveforms may reside completely within the Kintex's Block RAM or may possibly be generated on-the-fly, so they can be transfered to the DAC at a higher rate.

Or they may have thought of certain software extensions that may have required dedicated sample memory and that they discarded further down the line. Probably only Siglent engineers can answer this question accurately. Anyway, I think it's safe to say that it certainly went along with some cost-cutting measures from the management department...  ::)

--- End quote ---

I guess this is a good explanation.

However I am bit unclear if the latest versions that use ZynQ use it for DDS engine or just user control/UI/connectivity? the way I see based on some photos, it looked like they have one FPGA (Kintex?) for DDS and one for embedded control which can be a ZynQ (and no DDR for Kintex). I doubt that it will be possible to transfer wave samples on the fly to DDS engine from ZynQ as this will require connectivity with two FPGA's at 2.5 x 2 GB/s which is very unlikely. Also the DDR chips associated with ZynQ are probably not capable of supporting this data rate requirements anyway. There is no point in using ZynQ block RAM to store wavedata and transfer them to Kintex on the fly as they can just be stored in Kintex blockram instead. 


BTW, I asked this question from Siglent and got the usual response asking me to check the data sheet.

gf:

--- Quote from: suspension on October 30, 2024, 08:22:55 am ---However I am bit unclear if the latest versions that use ZynQ use it for DDS engine or just user control/UI/connectivity? the way I see based on some photos, it looked like they have one FPGA (Kintex?) for DDS and one for embedded control which can be a ZynQ (and no DDR for Kintex). I doubt that it will be possible to transfer wave samples on the fly to DDS engine from ZynQ as this will require connectivity with two FPGA's at 2.5 x 2 GB/s which is very unlikely. Also the DDR chips associated with ZynQ are probably not capable of supporting this data rate requirements anyway. There is no point in using ZynQ block RAM to store wavedata and transfer them to Kintex on the fly as they can just be stored in Kintex blockram instead. 

--- End quote ---

IMO we must distinguish DDS and TrueArb. The DDS wavetable isn't that large, so I think it can live in the FPGA anyway. Only the TrueArb wavetable can be huge. If you consider transfer on the fly only for TrueArb wave samples, then the maximum rate is 2 x 600 MB/s (not 2.5 x 2 GB/s). RAM access for TrueArb is sequential (except at the wrap-around), which may also help.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod