I am currently doing a rewrite/refactor of some of the CW host software. My main purpose in doing so is to get a better understanding of what is going on under the hood, which I hope will help when crafting my own attacks on new targets. So I will have lots of questions along the way to ensure I fully understand everything.
Anyway the first Qs are about sample acquisition. The sourcecode shows two modes; a FIFO based mode and a DDR based mode. However it appears that the DDR based mode no longer exists and so FIFO mode is always used. Is this correct?
Also there is a “max samples” value that is stored on the hardware that you can read and write via address:
ADDR_SAMPLES = 16
Is this “max samples value” the size of the FIFO?
When I read this out from the hardware without first setting it, it is 24573 (0x5FFD)
I can set this to any value including very high values that would be way larger than the FIFO would be. I wonder if this is the intended behaviour or is it more for use to limit the capture to the size of the FIFO or less?
The hardware is returning the number of “max samples” as 24573 (0x5FFD).
If I try to read 50,000 samples it will read out 24588 (0x600C) samples.
The “extra” samples on the end appear at a glance to be ok. I am not hooked up to anything currently, just reading in random noise data. The “extra” samples also look like random noise data, they don’t look like fixed zeros or maxed out data.
If I try setting the max samples to a higher value, like 50,000, it will still only return 24588 samples. This suggests that “max samples” should probably be a read only value and that perhaps it is incorrectly reporting its size?
If this is the case then 24588 max samples doesn’t seem like a whole lot. What is the feasibility of using the DDR ram on the CW Rev2 to store samples during aquisition (as ddrmode enticingly suggests). Being able to capture (64MB/4) * 3 = 50,331,648 consecutive sample points would be great
Correct - DDR mode was broken a while back, I never re-enabled it.
Basically, although there is some fudging as the FIFO width is not the same as the sample width. The FIFO write width is 32-bits, so stores 3 10-bit samples per FIFO word.
Correct - the maxsamples is really a maximum of this register OR the fifosize. It is read/write as at reset it’s defaulted to the FIFO size, but you can set it lower to capture less samples.
Very feasible - it’s on my TODO list, as this will basically be a free upgrade for all current users since the DDR is there already The previous DDR code was actually for another device on the LX9 board, but the memory controller interface should be the same. I just need to check if that still works (the memory controller to openadc subsystem link).
This hasn’t been too high on the list as the software needs to be improved to deal with huge traces. Although if you are only capturing a few large traces it would be fine… which would be the case to asymmetric crypto attacks.
I think all the FIFO depths are ‘guaranteed minimums’, so there may be a few extra samples.
The previous DDR code was actually for another device on the LX9 board, but the memory controller interface should be the same. I just need to check if that still works (the memory controller to openadc subsystem link).