Thanks for your nice comment.
Ok, I apologize that I didn't mention that it, MHz measurement, is going to be multiplied by 4Bytes (cuz the basic wide is 32-bit). We are using 1 sample data at every 32bit wide.
(To inform you we also consider that multiple sample data can be compacted on 32bit wide in any case though.)
Nevertheless, the practical throughput on recieving procedure from okHost to PC is seemingly 300 MB/s or around.
Theoretically, in my idea, since okHost clock speed is 100.8MHz, the throughput is expected to reach to 403.2MB/s. So, our sensor data speed is originally designed to be worked at about 400MB/s, cuz it is sampled at speed of 100MHz.
All our data loss seem to caused by the speed gap between 400MB/s on sensor and practical throughput of 300 MB/s on okHost side.
So, based on your advice, I wonder if we are using DDR2 memory interface, is it reasonable to use much faster throughput on the side of okHost and PC?
Because DDR2 memory might allow us to use faster clock as your official document said, "300MHz clock seems to be available"(on XEM6310-UM.pdf). So is that setting for TS_okHostClk on ucf file setting?
NET "okUH" TNM_NET = "okHostClk";
TIMESPEC "TS_okHostClk" = PERIOD "okHostClk" 9.92 ns HIGH 50%;
I just need a little comment about how to assign faster clock to receiving clock pin, okHostClk.