Is Ti_CLK 24 or 48 and is datain 8 or 16-bit?

FrontPanel
1

Using Pipetest.v / Pipetest.exe / XEM3010 / okBTPipeIn

The manual implies that ti_clk is 48 MHz but the data width to the BRAMs is always implemented as 16-bit wide (for a pipe), not 8. Given that USB 2.0 is 480 MHz (eqv 48 MByte/S after start/stop bits), something has to give.
Is the same BRAM address read/written twice at 48 MHz or once at 24MHz? … or is the Cypress part buffering somewhere ???

  • sorry in advance if I’m missing something obvious.
2

TI_CLK is 48 MHz. The databus is, indeed, 16-bit wide. USB 2.0 is also 480MHz. It is not true, however, that this is equivalent to 48 MB/s. First, USB is not an evolution of simple serial standards like RS-232 with start/stop bits. It is common for all serial standards to be specified by their signaling rate, but this can by no means be used to directly determine their throughput.

It’s not clear, however, where you think something is wrong. What is not adding up for you?

3

Ah - the 8->10 bit was indeed an assumption on my part (based on LVDS experience) - thanks for the clarification. Nevertheless, the timing didn’t seem to make sense on a continuous basis since the numbers still seem to be off by roughly a factor of two. The only explanation that makes sense to me is that the 4kB FIFO in the Cypress part is enabling the BRAM to be read out as fast as it is…

Read speed from BRAM = 48 MHz x 16 bits = 768 Mbit/S
USB throughput (assuming zero overhead) = 480 Mbit/S (significantly less than 768 MBit/S)

  • if the FIFO explains it, that is fine, I was just concerned at first that maybe only half the bits were used or something.
    … in which case, there must be a fairly significant gap between blocks being read (at least most of the time). I just want confirmation that I’m understanding this correctly.

Thanks!

4

Yes, transfers are not expected to be continuous. There will be breaks, but the lengths of these breaks are not defined.