Сообщение Re[23]: Собрал ревизию B от 05.02.2020 22:18
Изменено 05.02.2020 22:18 Codealot
Re[23]: Собрал ревизию B
Здравствуйте, koandrew, Вы писали:
DDR4 типовая латентность интерфейса — 20 тактов если обращение выполняется в уже открытую строку, где-то вдвое больше, если в какую-то другую, но банк не занят, или втрое больше (>60 тактов), если нужно будет закрыть какую-то другую строку. Если ещё сверху добавить латентность контроллера памяти, плюс арбитража — то сотня наберётся очень легко. А если уж попадёшь на период рефреша — всё, тушите свет, сливайте воду
А если сравнить это с латентностью получения данных даже (в лучшем случае) через PCIe, то сколько там будет тактов? Я думаю, там счет пойдет уже на сотни тысяч, если еще не хуже.
K>Так что алгоритм с "много случайных обращений" — херовый, придумывай поточный, где не было бы такой дури. Кстати, это тебе здорово поможет и для компа, и для GPGPU, ибо они тоже страдают от латентности памяти.
Реальность — она вообще довольно херовая штука, и в удобные алгоритмы укладывается далеко не всегда
K>Если для USB 3 использовать чипы FT600 или FT601 — то дрова предоставляются FTDI (производителем чипа) уже готовые и забесплатно, то есть даром. И они обеспечивают реальную полосу пропускания, которой почти хватает для стриминга RGB 1080p@60 в реальном времени (я тут как-то постил результаты своих тестов скорости этого решения). Ещё со стороны FPGA он предоставляет очень удобный FIFO-style интерфейс, так что интегрировать его в свой проект элементарно.
K>Всё другие варианты требуют существенно бОльшего объёма усилий, чтобы интегрировать. В некоторых типовых случаях для PCI Express можно обойтись предоставляемыми забесплатно IP (но не стоит забывать, что они скушают немало ресурсов FPGA)
Интересно, на что оно их жрет?
DDR4 типовая латентность интерфейса — 20 тактов если обращение выполняется в уже открытую строку, где-то вдвое больше, если в какую-то другую, но банк не занят, или втрое больше (>60 тактов), если нужно будет закрыть какую-то другую строку. Если ещё сверху добавить латентность контроллера памяти, плюс арбитража — то сотня наберётся очень легко. А если уж попадёшь на период рефреша — всё, тушите свет, сливайте воду
А если сравнить это с латентностью получения данных даже (в лучшем случае) через PCIe, то сколько там будет тактов?
Я думаю, там счет пойдет уже на сотни тысяч, если еще не хуже.K>Так что алгоритм с "много случайных обращений" — херовый, придумывай поточный, где не было бы такой дури. Кстати, это тебе здорово поможет и для компа, и для GPGPU, ибо они тоже страдают от латентности памяти.
Реальность — она вообще довольно херовая штука, и в удобные алгоритмы укладывается далеко не всегда
K>Если для USB 3 использовать чипы FT600 или FT601 — то дрова предоставляются FTDI (производителем чипа) уже готовые и забесплатно, то есть даром. И они обеспечивают реальную полосу пропускания, которой почти хватает для стриминга RGB 1080p@60 в реальном времени (я тут как-то постил результаты своих тестов скорости этого решения). Ещё со стороны FPGA он предоставляет очень удобный FIFO-style интерфейс, так что интегрировать его в свой проект элементарно.
K>Всё другие варианты требуют существенно бОльшего объёма усилий, чтобы интегрировать. В некоторых типовых случаях для PCI Express можно обойтись предоставляемыми забесплатно IP (но не стоит забывать, что они скушают немало ресурсов FPGA)
Интересно, на что оно их жрет?
Re[23]: Собрал ревизию B
Здравствуйте, koandrew, Вы писали:
K>DDR4 типовая латентность интерфейса — 20 тактов если обращение выполняется в уже открытую строку, где-то вдвое больше, если в какую-то другую, но банк не занят, или втрое больше (>60 тактов), если нужно будет закрыть какую-то другую строку. Если ещё сверху добавить латентность контроллера памяти, плюс арбитража — то сотня наберётся очень легко. А если уж попадёшь на период рефреша — всё, тушите свет, сливайте воду
А если сравнить это с латентностью получения данных даже (в лучшем случае) через PCIe, то сколько там будет тактов? Я думаю, там счет пойдет уже на сотни тысяч, если еще не хуже.
K>Так что алгоритм с "много случайных обращений" — херовый, придумывай поточный, где не было бы такой дури. Кстати, это тебе здорово поможет и для компа, и для GPGPU, ибо они тоже страдают от латентности памяти.
Реальность — она вообще довольно херовая штука, и в удобные алгоритмы укладывается далеко не всегда
K>Если для USB 3 использовать чипы FT600 или FT601 — то дрова предоставляются FTDI (производителем чипа) уже готовые и забесплатно, то есть даром. И они обеспечивают реальную полосу пропускания, которой почти хватает для стриминга RGB 1080p@60 в реальном времени (я тут как-то постил результаты своих тестов скорости этого решения). Ещё со стороны FPGA он предоставляет очень удобный FIFO-style интерфейс, так что интегрировать его в свой проект элементарно.
K>Всё другие варианты требуют существенно бОльшего объёма усилий, чтобы интегрировать. В некоторых типовых случаях для PCI Express можно обойтись предоставляемыми забесплатно IP (но не стоит забывать, что они скушают немало ресурсов FPGA)
Интересно, на что оно их жрет?
K>DDR4 типовая латентность интерфейса — 20 тактов если обращение выполняется в уже открытую строку, где-то вдвое больше, если в какую-то другую, но банк не занят, или втрое больше (>60 тактов), если нужно будет закрыть какую-то другую строку. Если ещё сверху добавить латентность контроллера памяти, плюс арбитража — то сотня наберётся очень легко. А если уж попадёшь на период рефреша — всё, тушите свет, сливайте воду
А если сравнить это с латентностью получения данных даже (в лучшем случае) через PCIe, то сколько там будет тактов?
Я думаю, там счет пойдет уже на сотни тысяч, если еще не хуже.K>Так что алгоритм с "много случайных обращений" — херовый, придумывай поточный, где не было бы такой дури. Кстати, это тебе здорово поможет и для компа, и для GPGPU, ибо они тоже страдают от латентности памяти.
Реальность — она вообще довольно херовая штука, и в удобные алгоритмы укладывается далеко не всегда
K>Если для USB 3 использовать чипы FT600 или FT601 — то дрова предоставляются FTDI (производителем чипа) уже готовые и забесплатно, то есть даром. И они обеспечивают реальную полосу пропускания, которой почти хватает для стриминга RGB 1080p@60 в реальном времени (я тут как-то постил результаты своих тестов скорости этого решения). Ещё со стороны FPGA он предоставляет очень удобный FIFO-style интерфейс, так что интегрировать его в свой проект элементарно.
K>Всё другие варианты требуют существенно бОльшего объёма усилий, чтобы интегрировать. В некоторых типовых случаях для PCI Express можно обойтись предоставляемыми забесплатно IP (но не стоит забывать, что они скушают немало ресурсов FPGA)
Интересно, на что оно их жрет?