Проектирование LVDS на ПЛИС Altera, проектирование канала LVDS на Cyclone3 Опции

[yudu]

Кто проектировал канал LVDS помогите!
Соединяю два плиса Cyclone3 по lvds. Передатчик пашет, а вот на приемнике не могу считать данные. Имею две диф. пары, одна DATA и одна CLK.
Все вроде бы обозначил как надо. Снимаю принятые данные и клок на линейные выводы - точная копия того что давал на передачу. Но вот зацепить
клок внутри приемника не могу, не получается даже сосчитать импульсы. Другим словом в коде сигнал OK меняется раньше чем 64 импульса клока..


LIBRARY ieee;
USE ieee.std_logic_1164.all;


-- Entity Declaration

ENTITY priem IS
-- {{ALTERA_IO_BEGIN}} DO NOT REMOVE THIS LINE!
PORT
(
inclk : IN STD_LOGIC;
indat : IN STD_LOGIC;
data : out STD_LOGIC :='0';-- линия данных
buff : out STD_LOGIC_VECTOR(55 downto 0):=x"00000000000000"; --data dly upravlyemogo ustroystva
st,s1,s2: out STD_LOGIC:='0';
C : out STD_LOGIC :='0';
EN : out STD_LOGIC_vector(0 to 1):=b"00"
);
-- {{ALTERA_IO_END}} DO NOT REMOVE THIS LINE!
END priem;


-- Architecture Body
ARCHITECTURE priem_architecture OF priem IS
signal adr:STD_LOGIC_vector (3 downto 0):=x"5";-- АДРЕСС ПРИЕМНИКА
signal datbuf:STD_LOGIC_VECTOR(0 to 63):=x"0000000000000000"; -- adres + data
signal id,ic:STD_LOGIC:='0';
signal ok,pr_adr,c1:STD_LOGIC:='0';
signal sta:STD_LOGIC:='0'; --сигнал старт-бита / сброс передачи данных


BEGIN

id<=indat;
ic<=inclk;
--прием старт-бита / сброс передачи данных
--при выполнении условия приема старт-бита
--на линии STA появляется импульс
--priem start bita
---------------------------------------------------------------------------------------------
process (id,ic)
variable i: integer:=0;
begin
if (ic='0') then i:=0; sta<='0';
end if;
if ic='1' then
if (id='0' and i=0) then i:=1;
elsif (id='1' and i=1) then i:=2;
elsif (id='0' and i=2) then sta<='1';
end if;
end if;
end process;
---------------------------------------------------------------------------------------------

---------------------------------------------------------------------------------------------
process (sta,ic) --запись данных
variable i: integer:=0;
begin
if (ic'event and ic='1') then
if i<64 then
datbuf(i)<=id;
i:=i+1;
if i=64 then ok<=not ok;
end if;
end if;
end if;

if sta='1' then i:=0;
end if;
end process;
---------------------------------------------------------------------------------------------

st<=sta;
s1<=ic;
s2<=ok;

END priem_architecture;

[Kuzmi4]

2 yudu - зачем вам чтото городить своё ? Всё уже украдено до вас - есть ALT_LVDS (в мегавизарде) или как то так - там и клок и сериализатор, линий мало, скорость нормальная... Если соединять 2 циклона - с минимум линий и по LVDS - самое оно
Там и примеры есть у альтеры как раз рабочие...

[DmitryR]

Во-первых, почитайте хорошенько книжки по основам синхронного дизайна, чтобы никогда больше (по крайней мере до тех пор, пока вы не начнете проектировать крутые заказные микросхемы) не пытаться тактовую частоту обрабатывать асинхронно ("if (ic='0')" etc.). Тогда станет ясно, что по линии clk надо передавать просто тактовый сигнал, непрерывно, а передачу пакетов данных осуществлять придумав формат пакета, передаваемый по линии данных. Наперед скажу, что если надо передавать данные не постоянно, а пачками проще протянуть третий провод, который будет как clock enable, чем заморачиваться пакетами.

[nonedub]

Во-первых, почитайте хорошенько книжки по основам синхронного дизайна, чтобы никогда больше (по крайней мере до тех пор, пока вы не начнете проектировать крутые заказные микросхемы) не пытаться тактовую частоту обрабатывать асинхронно ("if (ic='0')" etc.). Тогда станет ясно, что по линии clk надо передавать просто тактовый сигнал, непрерывно, а передачу пакетов данных осуществлять придумав формат пакета, передаваемый по линии данных. Наперед скажу, что если надо передавать данные не постоянно, а пачками проще протянуть третий провод, который будет как clock enable, чем заморачиваться пакетами.

А что делать, если имеется двухпроводной (двухпарный) LVDS, да еще с gated clock?

[Shtirlits]

А что делать, если имеется двухпроводной (двухпарный) LVDS, да еще с gated clock?

А с gated clock лучше кого-то застрелить сразу.
Откуда они вообще берутся эти gated clock-и в местах, где применяется LVDS ?

[des00]

А с gated clock лучше кого-то застрелить сразу.
Откуда они вообще берутся эти gated clock-и в местах, где применяется LVDS ?

да есть такие фанаты, которым надо передать кадры без потерь на синху а отдельную линию под строб зажали...

[yudu]

2 yudu - зачем вам чтото городить своё ? Всё уже украдено до вас - есть ALT_LVDS (в мегавизарде) или как то так - там и клок и сериализатор, линий мало, скорость нормальная... Если соединять 2 циклона - с минимум линий и по LVDS - самое оно
Там и примеры есть у альтеры как раз рабочие...

Все дело в том, что канал LVDS должен давать данные пачками. После передачи должен быть основной режим для остальной части схемы,
а для плиса наступает режим молчания(подведено только питание). И еще, работа плиса должна на момент приема тактироваться сигналом клок(clk),
внешнего кварца нет. Data приходит на выводы 128/129, а клок на 49/50.

[nonedub]

А с gated clock лучше кого-то застрелить сразу.
Откуда они вообще берутся эти gated clock-и в местах, где применяется LVDS ?

Например, линк-порты DSP TS201 TigerShark от Analog Devices.

[Kuzmi4]

2 yudu - это конечно всё хорошо, но всё же не ясно , ЧТО ИМЕННО мешает использовать ALTLVDS?? Ставьте примитив и гоняйте данные пачками Или вопрос стоит именно соорудить всё это чЮдо самому ? Кстати , а у вас клок кто разадаёт ? Он не глохнет случаем когда ктот орешает что передача окончена ??


И что значит

..Data приходит на выводы 128/129, а клок на 49/50...

Камень какой ?

[DmitryR]

Все дело в том, что канал LVDS должен давать данные пачками. После передачи должен быть основной режим для остальной части схемы, а для плиса наступает режим молчания(подведено только питание).

То есть у вас еще ко всему на этих двух несчастных проводах несколько источников сигнала, ПЛИС и еще кто-то. Застрелиться, это и для опытного-то человека гимор. А частоты-то какие?

Например, линк-порты DSP TS201 TigerShark от Analog Devices.

Ну это же неправда, там контроль передачи ведется через ACK/BCMP.

[Kuzmi4]

Если

..на этих двух несчастных проводах несколько источников сигнала, ПЛИС и еще кто-то..

то тут действительно ALTLVDS не покатит, но почему не взять I2C, он же TWI, - защищённость от шумов похуже чем у LVDS-ных, но можно много посадить товарищей на шину без особого гемора, да и скорости свои можно задать + корка не сложная..

[yudu]

Если то тут действительно ALTLVDS не покатит, но почему не взять I2C, он же TWI, - защищённость от шумов похуже чем у LVDS-ных, но можно много посадить товарищей на шину без особого гемора, да и скорости свои можно задать + корка не сложная..

Cyclon3. На проводах никого кроме 2-х плисов. Синхронизация 64 периода, 7 байт данных и 1 адресс. Эта синхронизация для диф. пары
данных и для работы самого плиса. Скорость передачи 100Мб/c.
Для ALTLVDS нужен PLL, для которого в свою очередь нужно время для запуска. Нужно городить самому. Есть предложения?

[SFx]

PLL в визарде лучше выбирать встроенную в корку ALT_LVDS. Все работает. проверял на цикло2->циклон3 до 260 мегабит/c по одной линии. единственное требование. CLk должен заходить на входы CLK_IN на плисене. иначе не выдет.
я по началу пытался использовать PLL отдельно сгенерированную - ничего не вышло. самое главное указать на LVDS_RX правильную выходную частоту.

[Kuzmi4]

2 yudu - идеи есть всегда
100Мб/с - это мегабайты или мегабиты ?? Если это мегабайты - что-то у меня есть сомнения, что по одной паре такое можно вытянуть на 3-м циклоне..

На счёт времени запуска PLL - это только в начале, после старта плиски, пару десятков клоков он конфигурироваться будет, а потом выставит валид и будет работать пока питание не пропадёт. Или у вас жёсткие условия начала работы после включения питания ?

И на счёт камня - какой именно циклончик ? а то может у вас клок приходит не на дедикейтед лапы и тогда и с ALTLVDS нужно будет тоже сильно колдовать

Как говорится - "..огласите весь список пжалуста.."

[IT_Pavel]

А вы правильно подключили ножки ПЛИС? Входной клок подается на ножки DIFFCLK ?
Вместо конструкций: "if (ic='0') then i:=0; sta<='0';" используйте: if falling_edge(inclk) then ...
вместо "if ic='1' then ..." используйте "if rising_edge(inclk) then ..." Если подаете тактовый сигнал, то и используйте его.

Если есть сомнения происходит ли передача данных вообще, то можно это посмотреть в SignalTap.

[DmitryR]

Cyclon3. На проводах никого кроме 2-х плисов. Скорость передачи 100Мб/c.

Итак, у вас 4 провода (2 пары) между ПЛИС. Берете делаете их как LVCMOS25, и прекрасно делаете все без гейтованного клока. По одной проволке постоянно идет клок, по другой - данные, по третьей - 1 когда данные есть и 0 когда их нет, по четвертой - можно потверждение приема сделать.

[nonedub]

Ну это же неправда, там контроль передачи ведется через ACK/BCMP.

А причем здесь контроль передачи? Да, он имеется, но это не мешает использовать для передачи gated clock, который молчит, когда линк свободен. То есть, постоянного клока из порта нет. Хотя, согласен, наличие линий управления упрощает интерфейс между ДСП и ПЛИС.

Сообщение отредактировал nonedub - Aug 27 2009, 17:14

[DmitryR]

Наличие линий управления не просто упрощает интерфейс, оно делает ненужным анализ тактовой частоты на присутствие/молчание, поэтому молчание тактовой влечет в данном случае только одно неудобство - невозможность подать его на PLL, а в остальном это нормальный клок, распространяемый только по выделенным тактовым линиям. А автор пытается тактовую частоту анализировать, что влечет уход клока в логику и известные проблемы с анализом времянки.

[yudu]

2 yudu - идеи есть всегда
100Мб/с - это мегабайты или мегабиты ?? Если это мегабайты - что-то у меня есть сомнения, что по одной паре такое можно вытянуть на 3-м циклоне..

На счёт времени запуска PLL - это только в начале, после старта плиски, пару десятков клоков он конфигурироваться будет, а потом выставит валид и будет работать пока питание не пропадёт. Или у вас жёсткие условия начала работы после включения питания ?

И на счёт камня - какой именно циклончик ? а то может у вас клок приходит не на дедикейтед лапы и тогда и с ALTLVDS нужно будет тоже сильно колдовать

Как говорится - "..огласите весь список пжалуста.."

Cyclone EP3C5E144. Питание подключено всегда, синхронизация плиса, она же синхронизация данных для lvds, идет пачками.

Наличие линий управления не просто упрощает интерфейс, оно делает ненужным анализ тактовой частоты на присутствие/молчание, поэтому молчание тактовой влечет в данном случае только одно неудобство - невозможность подать его на PLL, а в остальном это нормальный клок, распространяемый только по выделенным тактовым линиям. А автор пытается тактовую частоту анализировать, что влечет уход клока в логику и известные проблемы с анализом времянки.

Но если их нет. как быть с двумя витыми парами?
уже пробую просто получить меандр на "ok" - обычный 3.3V пин из клока, с входной частотой inclk около 1МГц и не получается
на осциллографе только длительность пачки такая же, а импульсы разной скважности

LIBRARY ieee;
USE ieee.std_logic_1164.all;


-- Entity Declaration

ENTITY priem IS
-- {{ALTERA_IO_BEGIN}} DO NOT REMOVE THIS LINE!
PORT
(
inclk : IN STD_LOGIC;
indat : IN STD_LOGIC;
data : out STD_LOGIC :='0';-- ëèíèÿ äàííûõ
s1,s2: out STD_LOGIC:='0'
);
-- {{ALTERA_IO_END}} DO NOT REMOVE THIS LINE!
END priem;


-- Architecture Body
ARCHITECTURE priem_architecture OF priem IS

signal ok:STD_LOGIC:='0';


BEGIN

---------------------------------------------------------------------------------------------
process (inclk)
begin
if rising_edge(inclk) then
ok<=not ok;
end if;
end process;
--------------------------------------------------------------------------------------------
s1<=ok;

END priem_architecture;

Итак, у вас 4 провода (2 пары) между ПЛИС. Берете делаете их как LVCMOS25, и прекрасно делаете все без гейтованного клока. По одной проволке постоянно идет клок, по другой - данные, по третьей - 1 когда данные есть и 0 когда их нет, по четвертой - можно потверждение приема сделать.

lvds нужно однозначно-условие. Как можно по двум диф. парам давать синхрониз. данные на плис вместе с синхронизацией плиса?
Получается нужно ваять десериализатор самому. Главный вопрос как ловить границы (или старт/стопы).
И повторю что заводя диф. пары inclk и indat сквозь плис на два 3.3 V выходных пина, получаю четкие копии и клока и данных отправляемые с передатчика в lvds..
В чем дело пока не понимаю

[DmitryR]

синхронизация плиса, она же синхронизация данных для lvds, идет пачками.

Если синхронизацию пачками мы еще делали (SpaceWire называется), то не имея стабильного источника синхронизации самой ПЛИС по-моему за дело браться совсем не стоит. Ну просто поиск проблем на свою голову: CMOS вам не подходит, синхронизации нету...

[nonedub]

Наличие линий управления не просто упрощает интерфейс, оно делает ненужным анализ тактовой частоты на присутствие/молчание, поэтому молчание тактовой влечет в данном случае только одно неудобство - невозможность подать его на PLL, а в остальном это нормальный клок, распространяемый только по выделенным тактовым линиям. А автор пытается тактовую частоту анализировать, что влечет уход клока в логику и известные проблемы с анализом времянки.

Увы, но наличие _BCMP не избавляет вас от необходимости анализа тактовой частоты на присутствие/молчание для определения начала передачи. Я рассматриваю случай, когда линк-порт ДСП является передатчиком, а ПЛИС - приемником. _BCMP переходит в активное состояние (низкий уровень) только на последних 128 битах блока данных (если, например, используется ДМА).

[yudu]

Если синхронизацию пачками мы еще делали (SpaceWire называется), то не имея стабильного источника синхронизации самой ПЛИС по-моему за дело браться совсем не стоит. Ну просто поиск проблем на свою голову: CMOS вам не подходит, синхронизации нету...

Кстати сделал этот проект по двум ТТЛ 3.3V проводам, один клок и один данные. Все работает. А диф. пары нет.

Тоесть кроме посылок синхронизированных данных по линииям lvds, нужно отдельно давать синхронизацию для плиса на время этих посылок
или даже чуть раньше. Выбрать еще одну диф. пару и раньше начала посылки запускать синхронизацию? А частоту синхры брать какую?

[DmitryR]

Кстати сделал этот проект по двум ТТЛ 3.3V проводам, один клок и один данные. Все работает. А диф. пары нет.

Это вы где-то накривили, ищите. Если просто сменить тип буфера с CMOS на LVDS - разваливаться не должно.

[Алексей_1990]

Здравствуйте. Разъясните, пожалуйста, как я могу принять 16 битный параллельный код и отправить его на одну lvds пару. При этом использовать желательно altlvds_tx. Предусмотрено ли у этого передатчика подобие каскадного подключения?

[andrew_b]

Здравствуйте. Разъясните, пожалуйста, как я могу принять 16 битный параллельный код и отправить его на одну lvds пару

Делаете преобразователь параллельного кода в последовательный и передаёте.

При этом использовать желательно altlvds_tx.

Quartus сделает это за вас, если вы объявите выходные пины как lvds.

Предусмотрено ли у этого передатчика подобие каскадного подключения?

Что такое "подобие каскадного подключения" и зачем вам оно нужно?

[Алексей_1990]

Делаете преобразователь параллельного кода в последовательный и передаёте.
Quartus сделает это за вас, если вы объявите выходные пины как lvds.
Что такое "подобие каскадного подключения" и зачем вам оно нужно?

Насколько я понял, altlvds_tx может принять 16 бит параллельного кода только, преобразовав его в 2 последовательных канала. А мне бы хотелось получить один канал.

[andrew_b]

Насколько я понял, altlvds_tx может принять 16 бит параллельного кода только, преобразовав его в 2 последовательных канала. А мне бы хотелось получить один канал.

Не нужно никаких altlvds_tx.
Загружаете свои 16 bit в сдвиговый регистр, потом сдвигаете. Выход регистра подаёте на ножку, которую констрейните как lvds.

[Алексей_1990]

Не нужно никаких altlvds_tx.
Загружаете свои 16 bit в сдвиговый регистр, потом сдвигаете. Выход регистра подаёте на ножку, которую констрейните как lvds.

А сдвиговый регистр потянет битрейт 768 Mgps? То есть параллельные данные идут с частотой 48 МГц. И разрешите ещё вопрос: вы знакомы с ядром custom PHY?

[andrew_b]

А сдвиговый регистр потянет битрейт 768 Mgps? То есть параллельные данные идут с частотой 48 МГц.

А почему вы об этом сразу не сказали? Ещё какие нюансы есть? Плисина какая?

И разрешите ещё вопрос: вы знакомы с ядром custom PHY?

Работать с ним не доводилось. Название знаю.

[Алексей_1990]

А почему вы об этом сразу не сказали? Ещё какие нюансы есть? Плисина какая?
Работать с ним не доводилось. Название знаю.

Спасибо, что заинтересовались. Так вот, первоначально стояла задача принять асинхронный последовательный сигнал со старт/стоповыми битами. Источником данной последовательности является сериалайзер d59lv18tvv. Скорость потока, если учитывать стартовые и стоповые биты - 960 Mgps. Из этой последовательности интересуют 16 бит информации, которые идут сразу после старт-бита. Всего же между стартом и стопом 18 бит. Верхние два (17 и 18) не используются.
Для решения этой задачи начал разбираться с высокоскоростными аппаратными приемопередатчиками custom PHY. Не вышло, очень много неизвестных параметров.

Теперь облегчили задачу: нужно хотябы для начала принять 16 битный параллельный поток и преобразовать его в последовательность. Скорость параллельного потока 48 МГц, выходной соответственно 769 Mgps. Выходная последовательность нужна lvds. Кристалл Cyclone V 5cgxfc5c6f27c7n. За любую помощь буду благодарен.

[Александр77]

...Теперь облегчили задачу: нужно хотябы для начала принять 16 битный параллельный поток и преобразовать его в последовательность. Скорость параллельного потока 48 МГц, выходной соответственно 769 Mgps. Выходная последовательность нужна lvds.

А насколько строго должна быть передача по одной паре?
Если требование не жесткое, то можно пустить поток по нескольким парам и снизить требования к скорости в единичном канале.

Кристалл Cyclone V 5cgxfc5c6f27c7n.

Имея циклон с GXB (со скоростями больше 1Gb/s), несколько странно упираться в lvds. Это имеет смысл лишь при занятых приемо-передатчиках.

[Алексей_1990]

А насколько строго должна быть передача по одной паре?
Если требование не жесткое, то можно пустить поток по нескольким парам и снизить требования к скорости в единичном канале.

Имея циклон с GXB (со скоростями больше 1Gb/s), несколько странно упираться в lvds. Это имеет смысл лишь при занятых приемо-передатчиках.

Дело в том, что эта задача промежуточная. То есть у меня есть ацп с параллельным 16битным выходом, так вот преобразованный последовательный сигнал необходимо подать как раз на тот десириалайзер. Это делается дабы проверить адекватность преобразования параллельного кода в последовательный в плис.

Ну и отвечая на вопрос о жёсткости привязки к одному каналу: к сожалению, нужен только один канал.

[Tue]

Пытаюсь разработать два независимых (один туда, другой обратно) LVDS-канала передачи данных между двумя ПЛИС Cyclone 5 GX (конкретно 5CGXFC7C6F23I7). "Путаница" в документации, практически полное отсутствие примеров завели меня в тупик и я вынужден обратиться сюда.

В обоих ПЛИС делаю одинаковые ALTLVDS_TX, ALTLVDS_RX. Частота входных данных 150МГц, коэффициент сериализации 4, выходной поток 600Мбит/с на один LVDS-канал. Думаю это комфортные условия для данного кристалла. Всего 17 LVDS-каналов. ALTLVDS_TX, ALTLVDS_RX делаю НЕ в режиме "External PLL mode". То есть все частоты для работы блоки делают внутри себя сами.

В ALTLVDS_TX задаю параметр "outclock divide factor (" равным 4, ставлю галку "Use 'tx_outclock' output port" и "Use 'tx_coreclock' output port". На входной порт ALTLVDS_TX/tx_inclock подаю 150МГц, питаю данными, выдаваемым схемой, которая запитывается от частоты tx_coreclock

В ALTLVDS_RX и задавать то особо нечего. Input data rate ставлю 600Мбит/с, input clock rate clock frequency ставлю 150МГц.

Выходной порт tx_outclock блока ALTLVDS_TX в одной ПЛИС соединяю с входным портом rx_inclock блока ALTLVDS_RX в другой ПЛИС. В моделировании tx_outclock выдает частоту 150МГц, в железе пока непонятно. В ModelSim все работает замечательно. В железе не работает, возникает много вопросов.

1. В документе "LVDS SERDES Transmitter/Receiver IP Cores User Guide" 2017.06.19 в таблице 2 для ALTLVDS Transmitter указаны частоты для моего (четного) коэффициента сериализации:

Fast Clock = Data Rate/2
Slow Clock (outclock)= Data Rate/2*B
Core Clock = Data Rate/J

То есть для моего случая должы быть такие значения: Fast Clock = 300МГц. Slow Clock = 1200МГц (если буквально понимать формулу). Если понимать ее как Slow Clock = Data Rate/(2*, то должно быть 75МГЦ. Core clock = 150МГц. В TimeQuest'е я вижу Fast Clock = 600МГц, Slow Clock = 150МГц, Core Clock (который имеет скважность 100/J = 25% в моем случае) равен 150МГц.

Это первая неопределенность (фундаментальная), которая у меня возникает в разработке LVDS-канала.
Возможно документация (достаточно новая) для Cyclone-семейства исходит из того, что Cyclone до 5-го используют DDIO, а в 5-ом уже используется аппаратный блок сериализации, без DDIO. Отсюда возникает эта путаница, но от осознания этого легче не становится.

2. Из-за того, что в документации я вижу одно, в ModelSim другое, а в TimeQuest третье решил вывести в SignalTAP счетчики, запитать их разными частотами и посмотреть что же получается в железе.



На картинке фрагмент из SignalTAP'a. Частота SignalTAP равна 150МГц (назовем ее avl_clk). Счетчик здесь немного необычный. Считает не каждый первый такт, а каждый второй такт. Так лучше видно.

2.1 Из диаграмы видно, что первый счетчик (запитанный tx_coreclock) и второй счетчик (запитанный частотой SignalTAP avl_clk) идут одним темпом. Из этого становится понятно, что частота tx_coreclock равна avl_clk и обе равны 150МГц.

2.2 Дальше идет счетчик с частотой rx_coreclock (частота приемных десериализированных данных). Видно что он изменяется каждый первый такт. Это, как я понимаю, означает, что она в два раза выше частот avl_clk, tx_coreclock и равна 300МГц. Почему ? Непонятно

2.3 Дальше идет lvds_rx_inclk. Это tx_outclock (Slow Clock) от блока ALTLVDS_TX из соседней ПЛИС. Судя по тому, ка к меняются значения каждый такт (090h, 092h, 094h, 096h, 098h, ...) у меня складывается ощущение, что она в 4 раза выше частоты SignalTAP, то есть 600МГц. Почему ? Непонятно. Еще непонятны замирания счетчика (например на значении 0B6h на картинке)

2.4 Из-за такого поведения счетчика lvds_rx_inclk у меня нет уверенности в том, что tx_outclock равен 150МГц. Когда писал эти вопросы провел эксперимент. Подал на tx_outclock частоту не с ALTVDS_TX/tx_outclock, а частоту с PLL с гарантированно известной частотой 150МГц. Эта частота поступает с другой ПЛИС на lvds_rx_inclk в ПЛИС, с которой снимаю SignalTAP. 4-й счетчик стал считать аналогично 3-ему, то есть каждый такт менять значение. Как такое может быть, если эта частота и частота SignalTAP номинально равны (могут и быть незначительные отклонения в несколько десятков ppm) ?

3. Может быть я как-то неправильно настраиваю ALTLVDS_TX, ALTLVDS_RX ? Может кто-нибудь подсказать, как будет правильно их настроить? Что с чем соединять, чтобы получить LVDS-канал. Где какие должны быть частоты ? Поняв как правильно настроить передатчики и приемники буду двигать дальше.

[Flip-fl0p]

LVDS у Вас запускается на DDR регистрах. Соответственно частота дессерелизации не 600 МГц а 300.
Крайне желательно после включения "обучить" приёмник. Т.е по какой-либо тестовой последовательности найти правильный порядок бит.
Например приёмник и передатчик включились не одновременно. Передатчик отдает биты в таком порядке 3-2-1-0 3-2-1-0 3-2-1-0 А приёмник ловит данные неправильно:
2-1-0-3 2-1-0-3 2-1-0-3.

[Tue]

Да, обучения я предусмотрел и сделал (в модели). Но пока до этого не дошло. Мне бы с частотами разобраться.

[Tue]

Еще остались непонятными следующие вопросы:

1. Если говорим о передаче (ALTLVDS_TX) нужно ли вместе с tx_out выдавать tx_outclock ?
1.1 Если да, то что за частоту нужно выдавать, откуда ее брать ? Частоту параллельных данных (slow_clock) ?
1.2 Выдавать как I/O Standard LVDS ? Или как обычный, не диф. парой, однополярный ?
1.3 Как вообще констрейнится через sdc такой интерфейс ?

2. По приему (ALTLVDS_RX) тоже подобные вопросы. Нужно ли заводить rx_inclock ?
2.1 Он нужен просто для получения частоты fast_clock (скажем 600Мбит/с -> 600МГц) ? Могу ли для получения такой частоты (а также rx_enable, rx_coreclock) использовать обычную PLL и любую частоту для разгона PLL ?
2.2 Непонятно про сигнал rx_channel_data_align. Дергаю его, но никакого изменения. Если речь идет о многоразрядном LVDS-канале, то каждый разряд rx_channel_data_align отвечает за свою LVDS линию и их можно дергать независимо ли это не так ?
2.3 Тот же вопрос про констрейны через sdc ?


Если у кого-то есть рабочий проект с LVDS-приемником/передатчиком для Cyclone 5, можно выложить тут архив проекта, касающийся только приема-передачи. Вместе с назначениями пинов и их I/O Standard ?

[Flip-fl0p]

Еще остались непонятными следующие вопросы:

1. Если говорим о передаче (ALTLVDS_TX) нужно ли вместе с tx_out выдавать tx_outclock ?
1.1 Если да, то что за частоту нужно выдавать, откуда ее брать ? Частоту параллельных данных (slow_clock) ?
1.2 Выдавать как I/O Standard LVDS ? Или как обычный, не диф. парой, однополярный ?
1.3 Как вообще констрейнится через sdc такой интерфейс ?

2. По приему (ALTLVDS_RX) тоже подобные вопросы. Нужно ли заводить rx_inclock ?
2.1 Он нужен просто для получения частоты fast_clock (скажем 600Мбит/с -> 600МГц) ? Могу ли для получения такой частоты (а также rx_enable, rx_coreclock) использовать обычную PLL и любую частоту для разгона PLL ?
2.2 Непонятно про сигнал rx_channel_data_align. Дергаю его, но никакого изменения. Если речь идет о многоразрядном LVDS-канале, то каждый разряд rx_channel_data_align отвечает за свою LVDS линию и их можно дергать независимо ли это не так ?
2.3 Тот же вопрос про констрейны через sdc ?


Если у кого-то есть рабочий проект с LVDS-приемником/передатчиком для Cyclone 5, можно выложить тут архив проекта, касающийся только приема-передачи. Вместе с назначениями пинов и их I/O Standard ?

В модуле ALT_LVDS_RX в режиме с внутренним PLL, порт rx_inclock - это опорная частота PLL. В режиме внешнего PLL (external PLL) порт rx_inclock - частота дессерилизации (учитывайте в каком режиме работает ALT_LVDS_RX. В режиме DDR или SDR. Если в режиме DDR - то частота дессерилизации соответственно в 2 раза ниже).
Сигнал rx_channel_data_align нужен для "обучения" приёмника, подали одиночный сигнал, и приём сдвинулся на 1 бит. Таким образом вы настраиваетесь на правильный порядок приёма бит. При многоканальном приёме каждый rx_channel_data_align отвечает за свой канал. Как я понял их можно дергать независимо друг от друга. Но лучше посмотрите при моделировании.

Сообщение отредактировал Flip-fl0p - Aug 24 2017, 07:29

[bogaev_roman]

В модуле ALT_LVDS_RX в режиме с внутренним PLL, порт rx_inclock - это опорная частота PLL. В режиме внешнего PLL (external PLL) порт rx_inclock - частота дессерилизации (учитывайте в каком режиме работает ALT_LVDS_RX. В режиме DDR или SDR. Если в режиме DDR - то частота дессерилизации соответственно в 2 раза ниже).

Есть проект, в котором используется именно внешняя pll и data_alignment, работоспособность зависит от компиляции к компиляции, т. е. вроде проблемы с таймингами. При попытке посмотреть временные пути столкнулся с проблемой - физика реализована на жестких блоках, анализ закрыт. Как там вообще физика реализована, нужно что-то прописывать во временных ограничениях кроме мультицикла на выходе и частоты на входе pll и ее производных? Временных ошибок нет, анализ unconstraint_patch говорит, что необконстрейненых путей тоже нет.
ЗЫ. Кстати, каким образом принудительно задать режим работы DDR - там настройки такой нет, только с помощью настроек pll?

[Flip-fl0p]

Есть проект, в котором используется именно внешняя pll и data_alignment, работоспособность зависит от компиляции к компиляции, т. е. вроде проблемы с таймингами. При попытке посмотреть временные пути столкнулся с проблемой - физика реализована на жестких блоках, анализ закрыт. Как там вообще физика реализована, нужно что-то прописывать во временных ограничениях кроме мультицикла на выходе и частоты на входе pll и ее производных? Временных ошибок нет, анализ unconstraint_patch говорит, что необконстрейненых путей тоже нет.

Скажу так: В LVDS SERDES Transmitter/Receiver IP Cores User Guide явного указания что-либо констрейнить кроме входного клока и данных я не увидел, хотя если честно я совсем плохой советчик по констрейнам. Изучать боле-менее осмысленно я их стал относительно недавно, для меня они ещё темный лес
Интересно, а можно ли как-то получить доступ к жестким блокам ALT_LVDS_RX ? Уж jочень заманчива мысль получить доступ к IR_FIFO_SERDES, который , как я понял, является "железным" высокоскоростным FIFO.
А в режиме extrenal PLL вы так-же ставили клоковый буфер между PLL и LVDS_RX ?

Сообщение отредактировал Flip-fl0p - Aug 24 2017, 08:21

[bogaev_roman]

А в режиме extrenal PLL вы так-же ставили клоковый буфер между PLL и LVDS_RX ?

Проект не мой, я пока не ковырял подробно, но на сколько я понял там буфер стоит. Тут еще момент появился - все работает со скоростью 600Mb/s в режиме SDR для циклон5, в документации вроде максимальная частота отталкивается от максимально возможной частоты с выход pll, т.е. 550МГц, что меньше требуемой.

[Flip-fl0p]

Проект не мой, я пока не ковырял подробно, но на сколько я понял там буфер стоит. Тут еще момент появился - все работает со скоростью 600Mb/s в режиме SDR для циклон5, в документации вроде максимальная частота отталкивается от максимально возможной частоты с выход pll, т.е. 550МГц, что меньше требуемой.

А каков коэффициент дессерелизации ? Может смысл имеет запустить в режиме DDR ? Тогда и частоту можно в 2 раза понизить...

[bogaev_roman]

А каков коэффициент дессерелизации ? Может смысл имеет запустить в режиме DDR ? Тогда и частоту можно в 2 раза понизить...

Я об этом и думаю коэффициент - 10, просто все расчеты велись изначально по этому документу https://www.altera.com/support/support-reso...142011_962.html

[Flip-fl0p]

Я об этом и думаю коэффициент - 10, просто все расчеты велись изначально по этому документу https://www.altera.com/support/support-reso...142011_962.html

В каком режиме работает PLL ? А если вручную фазу частоты приёма крутить, получается стабильный приём ?

[bogaev_roman]

В каком режиме работает PLL ?

Direct mode, есть возможность подключить lvds mode. Что это даст?

[Flip-fl0p]

Direct mode, есть возможность подключить lvds mode. Что это даст?

На сколько я понял там по-разному компенсируется задержка. Точно сказать не могу в чем принципиально отличаются. Где-то я видел хорошее объяснение режимов работы PLL, постараюсь найти и выложить. На сколько я понял правильнее всего применять source-synchronous compensator mode. Но тут я могу ошибаться.

Сообщение отредактировал Flip-fl0p - Aug 24 2017, 09:07

[Tue]

В модуле ALT_LVDS_RX в режиме с внутренним PLL, порт rx_inclock - это опорная частота PLL. В режиме внешнего PLL (external PLL) порт rx_inclock - частота дессерилизации

Это понятно :)

(учитывайте в каком режиме работает ALT_LVDS_RX. В режиме DDR или SDR. Если в режиме DDR - то частота дессерилизации соответственно в 2 раза ниже).

Как это учитывать ? Из документации и каких-то разрозненных источников я понял, что до Cyclone 5 DDR использовался, начиная с Cyclone 5 там аппаратный SERDES, без DDR. Так ли это ?

Вот если бы у вас стояла задача соединить два Cyclone 5 по LVDS, вы бы делали это через ALTLVDS_TX/RX ? tx_outclock выдавать вообще надо ? Или если на приемном конце разгоняем PLL в ALTLVDS_RX (в режиме External PLL или нет, неважно) от какой-то своей частоты (не tx_outclock от передатчика), то можно и не выдавать tx_outclock ? Тогда получается что принимаемые данные не привязаны ни к какой частоте, ничто не разграничивает байты. Как приемник будет понимать когда защелкивать сериализированные данные, чтобы это было надежно ?

Про rx_channel_data_align да, понятно что он делает bit-slip, сдвигает биты в байте. А как добиваться в приемнике верного защелкивания самого бита (это все без DPA ибо Cyclone5) ? Ну вот есть у PLL (если делаем ALTLVDS_RX в режиме External PLL) возможность (pll_phase_en, pll_updn, pll_cntsel сигналы) динамического изменения фазы любых выходящих с нее клоков . Как понять в какую сторону и на сколько двигать, какие критерии ?

[Flip-fl0p]

Это понятно



Как это учитывать ? Из документации и каких-то разрозненных источников я понял, что до Cyclone 5 DDR использовался, начиная с Cyclone 5 там аппаратный SERDES, без DDR. Так ли это ?

Вот если бы у вас стояла задача соединить два Cyclone 5 по LVDS, вы бы делали это через ALTLVDS_TX/RX ? tx_outclock выдавать вообще надо ? Или если на приемном конце разгоняем PLL в ALTLVDS_RX (в режиме External PLL или нет, неважно) от какой-то своей частоты (не tx_outclock от передатчика), то можно и не выдавать tx_outclock ? Тогда получается что принимаемые данные не привязаны ни к какой частоте, ничто не разграничивает байты. Как приемник будет понимать когда защелкивать сериализированные данные, чтобы это было надежно ?

Про rx_channel_data_align да, понятно что он делает bit-slip, сдвигает биты в байте. А как добиваться в приемнике верного защелкивания самого бита (это все без DPA ибо Cyclone5) ? Ну вот есть у PLL (если делаем ALTLVDS_RX в режиме External PLL) возможность (pll_phase_en, pll_updn, pll_cntsel сигналы) динамического изменения фазы любых выходящих с нее клоков . Как понять в какую сторону и на сколько двигать, какие критерии ?

Да действительно DDR нигде не применяется. Нашёл вот такое видео: https://www.youtube.com/watch?v=02lgfcxSjQA
Если бы 2 платы было я бы применял ALTLVDS_TX, и ALTLVDS_RX. Частотой tx_outclock я бы запускал PLL приёмника ALTLVDS_RX. В вашем случае разрабатывается плата, подсчитываются задержки на выходе, и и задаются правильные констрейны. И настраивается проект как везде советуют. По сути Вы просто настраиваете проект так, чтобы данные автоматически защелкивались по центру. Более подробно смотрите AN433 https://www.altera.com/en_US/pdfs/literature/an/an433.pdf
А вот автоматически подстроиться на центр окна Sample window - задача далеко не тривиальная, особенно на cyclone V. Я как раз занимаюсь сейчас вплотную этой задачей https://electronix.ru/forum/index.php?showtopic=142289 на данный момент реализовал автоматическую калибровку на центр. Сейчас добавляю динамическую калибровку. В конкретно вашем случае динамическая подстройка нафиг не нужна. У вас положение синхроимпульса и фронтов данных известно заранее и всегда одно и то-же, поскольку зависит только от разводки платы. У меня случай несколько другой. У меня эти значения неизвестны, и всегда разные при каждом включении.

Сообщение отредактировал Flip-fl0p - Aug 24 2017, 13:39

[Magnum]

А на какое расстояние надо передавать данные?

[Tue]

Да действительно DDR нигде не применяется.
...
Частотой tx_outclock я бы запускал PLL приёмника ALTLVDS_RX.

Я так и делал вначале. И почему-то rx_inclock приемной ПЛИС, на который заведен tx_outclock передающей ПЛИС оказывается в два раза выше, чем ожидаю (показывал на картинке на третьей странице в данной теме). Для rx_inclock и tx_outclock I/O Standard в назначении пинов задаю как LVDS.
Если для rx_inclock меняю I/O Standard на 2.5V (хоть это и неправильно), то частота становится нормальной, ожидаемой, не в два раза выше. Для tx_outclock (который выдается из ALTLVDS_TX, если выбрана конфигурация без внешней PLL) поменять I/O Standard на 2.5V не могу, почему-то Квартус 15.0 на этапе Ассемблера крашится (возникает какая-то ошибка)

А на какое расстояние надо передавать данные?

Расстояние небольшое, около 2см. Тут дело не в расстоянии, а в необходимой высокой скорости передачи. GXB-трансиверы исчерпались для другого.

Вчера попробовал не 600Мбит/с, а 300. Та же самая история.

[Magnum]

Если для rx_inclock меняю I/O Standard на 2.5V (хоть это и неправильно)

А почему это неправильно? Все банки с LVDS должны от 2,5 питаться.

[Tue]

Я говорил об установлении стандарта ввода-вывода пина в Assignment Editor. Там можно для пина задать LVDS - тогда он будет дифференциальным, а можно задать 2.5V - тогда он будет однополярным. Понятно что питание банков этих выводов будет 2.5В в обоих случаях.

[Magnum]

А, невнимательно прочитал. Для LVDS, есть некоторые требования по разводке дифф. пар на плате, они все выполнены? И есть некоторые ограничения по числу LVDS линий в одном банке, если слишком много то безошибочная работа не гарантируется, об этом ква. предупреждает.