Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Проектирование LVDS на ПЛИС Altera
Форум разработчиков электроники ELECTRONIX.ru > Программируемая логика ПЛИС (FPGA,CPLD, PLD) > Работаем с ПЛИС, области применения, выбор
Страницы: 1, 2
yudu
Кто проектировал канал LVDS помогите!
Соединяю два плиса Cyclone3 по lvds. Передатчик пашет, а вот на приемнике не могу считать данные. Имею две диф. пары, одна DATA и одна CLK.
Все вроде бы обозначил как надо. Снимаю принятые данные и клок на линейные выводы - точная копия того что давал на передачу. Но вот зацепить
клок внутри приемника не могу, не получается даже сосчитать импульсы. Другим словом в коде сигнал OK меняется раньше чем 64 импульса клока..sad.gif


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 - самое оно laughing.gif
Там и примеры есть у альтеры как раз рабочие...
DmitryR
Во-первых, почитайте хорошенько книжки по основам синхронного дизайна, чтобы никогда больше (по крайней мере до тех пор, пока вы не начнете проектировать крутые заказные микросхемы) не пытаться тактовую частоту обрабатывать асинхронно ("if (ic='0')" etc.). Тогда станет ясно, что по линии clk надо передавать просто тактовый сигнал, непрерывно, а передачу пакетов данных осуществлять придумав формат пакета, передаваемый по линии данных. Наперед скажу, что если надо передавать данные не постоянно, а пачками проще протянуть третий провод, который будет как clock enable, чем заморачиваться пакетами.
nonedub
Цитата(DmitryR @ Aug 26 2009, 18:01) *
Во-первых, почитайте хорошенько книжки по основам синхронного дизайна, чтобы никогда больше (по крайней мере до тех пор, пока вы не начнете проектировать крутые заказные микросхемы) не пытаться тактовую частоту обрабатывать асинхронно ("if (ic='0')" etc.). Тогда станет ясно, что по линии clk надо передавать просто тактовый сигнал, непрерывно, а передачу пакетов данных осуществлять придумав формат пакета, передаваемый по линии данных. Наперед скажу, что если надо передавать данные не постоянно, а пачками проще протянуть третий провод, который будет как clock enable, чем заморачиваться пакетами.


А что делать, если имеется двухпроводной (двухпарный) LVDS, да еще с gated clock?
Shtirlits
Цитата(nonedub @ Aug 27 2009, 01:15) *
А что делать, если имеется двухпроводной (двухпарный) LVDS, да еще с gated clock?

А с gated clock лучше кого-то застрелить сразу.
Откуда они вообще берутся эти gated clock-и в местах, где применяется LVDS ?
des00
Цитата(Shtirlits @ Aug 26 2009, 16:14) *
А с gated clock лучше кого-то застрелить сразу.
Откуда они вообще берутся эти gated clock-и в местах, где применяется LVDS ?


да есть такие фанаты, которым надо передать кадры без потерь на синху а отдельную линию под строб зажали...
yudu
Цитата(Kuzmi4 @ Aug 26 2009, 17:08) *
2 yudu - зачем вам чтото городить своё ? Всё уже украдено до вас - есть ALT_LVDS (в мегавизарде) или как то так - там и клок и сериализатор, линий мало, скорость нормальная... Если соединять 2 циклона - с минимум линий и по LVDS - самое оно laughing.gif
Там и примеры есть у альтеры как раз рабочие...


Все дело в том, что канал LVDS должен давать данные пачками. После передачи должен быть основной режим для остальной части схемы,
а для плиса наступает режим молчания(подведено только питание). И еще, работа плиса должна на момент приема тактироваться сигналом клок(clk),
внешнего кварца нет. Data приходит на выводы 128/129, а клок на 49/50.
nonedub
Цитата(Shtirlits @ Aug 27 2009, 02:14) *
А с gated clock лучше кого-то застрелить сразу.
Откуда они вообще берутся эти gated clock-и в местах, где применяется LVDS ?

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


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

Камень какой ?
DmitryR
Цитата(yudu @ Aug 27 2009, 08:27) *
Все дело в том, что канал LVDS должен давать данные пачками. После передачи должен быть основной режим для остальной части схемы, а для плиса наступает режим молчания(подведено только питание).
То есть у вас еще ко всему на этих двух несчастных проводах несколько источников сигнала, ПЛИС и еще кто-то. Застрелиться, это и для опытного-то человека гимор. А частоты-то какие?

Цитата(nonedub @ Aug 27 2009, 11:28) *
Например, линк-порты DSP TS201 TigerShark от Analog Devices.
Ну это же неправда, там контроль передачи ведется через ACK/BCMP.
Kuzmi4
Если
Цитата
..на этих двух несчастных проводах несколько источников сигнала, ПЛИС и еще кто-то..
то тут действительно ALTLVDS не покатит, но почему не взять I2C, он же TWI, - защищённость от шумов похуже чем у LVDS-ных, но можно много посадить товарищей на шину без особого гемора, да и скорости свои можно задать + корка не сложная..
yudu
Цитата(Kuzmi4 @ Aug 27 2009, 14:53) *
Если то тут действительно 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 - идеи есть всегда biggrin.gif
100Мб/с - это мегабайты или мегабиты ?? Если это мегабайты - что-то у меня есть сомнения, что по одной паре такое можно вытянуть на 3-м циклоне..

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

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

Как говорится - "..огласите весь список пжалуста.." laughing.gif
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
Цитата(yudu @ Aug 27 2009, 15:55) *
Cyclon3. На проводах никого кроме 2-х плисов. Скорость передачи 100Мб/c.

Итак, у вас 4 провода (2 пары) между ПЛИС. Берете делаете их как LVCMOS25, и прекрасно делаете все без гейтованного клока. По одной проволке постоянно идет клок, по другой - данные, по третьей - 1 когда данные есть и 0 когда их нет, по четвертой - можно потверждение приема сделать.
nonedub
Цитата(DmitryR @ Aug 27 2009, 14:05) *
Ну это же неправда, там контроль передачи ведется через ACK/BCMP.

А причем здесь контроль передачи? Да, он имеется, но это не мешает использовать для передачи gated clock, который молчит, когда линк свободен. То есть, постоянного клока из порта нет. Хотя, согласен, наличие линий управления упрощает интерфейс между ДСП и ПЛИС.
DmitryR
Наличие линий управления не просто упрощает интерфейс, оно делает ненужным анализ тактовой частоты на присутствие/молчание, поэтому молчание тактовой влечет в данном случае только одно неудобство - невозможность подать его на PLL, а в остальном это нормальный клок, распространяемый только по выделенным тактовым линиям. А автор пытается тактовую частоту анализировать, что влечет уход клока в логику и известные проблемы с анализом времянки.
yudu
Цитата(Kuzmi4 @ Aug 27 2009, 16:38) *
2 yudu - идеи есть всегда biggrin.gif
100Мб/с - это мегабайты или мегабиты ?? Если это мегабайты - что-то у меня есть сомнения, что по одной паре такое можно вытянуть на 3-м циклоне..

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

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

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



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

Цитата(DmitryR @ Aug 28 2009, 10:04) *
Наличие линий управления не просто упрощает интерфейс, оно делает ненужным анализ тактовой частоты на присутствие/молчание, поэтому молчание тактовой влечет в данном случае только одно неудобство - невозможность подать его на 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;


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


lvds нужно однозначно-условие. Как можно по двум диф. парам давать синхрониз. данные на плис вместе с синхронизацией плиса?
Получается нужно ваять десериализатор самому. Главный вопрос как ловить границы (или старт/стопы).
И повторю что заводя диф. пары inclk и indat сквозь плис на два 3.3 V выходных пина, получаю четкие копии и клока и данных отправляемые с передатчика в lvds..
В чем дело пока не понимаю
DmitryR
Цитата(yudu @ Aug 28 2009, 15:52) *
синхронизация плиса, она же синхронизация данных для lvds, идет пачками.
Если синхронизацию пачками мы еще делали (SpaceWire называется), то не имея стабильного источника синхронизации самой ПЛИС по-моему за дело браться совсем не стоит. Ну просто поиск проблем на свою голову: CMOS вам не подходит, синхронизации нету...
nonedub
Цитата(DmitryR @ Aug 28 2009, 10:04) *
Наличие линий управления не просто упрощает интерфейс, оно делает ненужным анализ тактовой частоты на присутствие/молчание, поэтому молчание тактовой влечет в данном случае только одно неудобство - невозможность подать его на PLL, а в остальном это нормальный клок, распространяемый только по выделенным тактовым линиям. А автор пытается тактовую частоту анализировать, что влечет уход клока в логику и известные проблемы с анализом времянки.

Увы, но наличие _BCMP не избавляет вас от необходимости анализа тактовой частоты на присутствие/молчание для определения начала передачи. Я рассматриваю случай, когда линк-порт ДСП является передатчиком, а ПЛИС - приемником. _BCMP переходит в активное состояние (низкий уровень) только на последних 128 битах блока данных (если, например, используется ДМА).
yudu
Цитата(DmitryR @ Aug 28 2009, 16:59) *
Если синхронизацию пачками мы еще делали (SpaceWire называется), то не имея стабильного источника синхронизации самой ПЛИС по-моему за дело браться совсем не стоит. Ну просто поиск проблем на свою голову: CMOS вам не подходит, синхронизации нету...


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

Тоесть кроме посылок синхронизированных данных по линииям lvds, нужно отдельно давать синхронизацию для плиса на время этих посылок
или даже чуть раньше. Выбрать еще одну диф. пару и раньше начала посылки запускать синхронизацию? А частоту синхры брать какую?
DmitryR
Цитата(yudu @ Aug 31 2009, 09:31) *
Кстати сделал этот проект по двум ТТЛ 3.3V проводам, один клок и один данные. Все работает. А диф. пары нет.
Это вы где-то накривили, ищите. Если просто сменить тип буфера с CMOS на LVDS - разваливаться не должно.
Алексей_1990
Здравствуйте. Разъясните, пожалуйста, как я могу принять 16 битный параллельный код и отправить его на одну lvds пару. При этом использовать желательно altlvds_tx. Предусмотрено ли у этого передатчика подобие каскадного подключения?
andrew_b
Цитата(Алексей_1990 @ Feb 10 2016, 16:46) *
Здравствуйте. Разъясните, пожалуйста, как я могу принять 16 битный параллельный код и отправить его на одну lvds пару
Делаете преобразователь параллельного кода в последовательный и передаёте.
Цитата
При этом использовать желательно altlvds_tx.
Quartus сделает это за вас, если вы объявите выходные пины как lvds.
Цитата
Предусмотрено ли у этого передатчика подобие каскадного подключения?
Что такое "подобие каскадного подключения" и зачем вам оно нужно?
Алексей_1990
Цитата(andrew_b @ Feb 11 2016, 09:47) *
Делаете преобразователь параллельного кода в последовательный и передаёте.
Quartus сделает это за вас, если вы объявите выходные пины как lvds.
Что такое "подобие каскадного подключения" и зачем вам оно нужно?

Насколько я понял, altlvds_tx может принять 16 бит параллельного кода только, преобразовав его в 2 последовательных канала. А мне бы хотелось получить один канал.
andrew_b
Цитата(Алексей_1990 @ Feb 15 2016, 11:09) *
Насколько я понял, altlvds_tx может принять 16 бит параллельного кода только, преобразовав его в 2 последовательных канала. А мне бы хотелось получить один канал.


Не нужно никаких altlvds_tx.
Загружаете свои 16 bit в сдвиговый регистр, потом сдвигаете. Выход регистра подаёте на ножку, которую констрейните как lvds.
Алексей_1990
Цитата(andrew_b @ Feb 15 2016, 11:26) *
Не нужно никаких altlvds_tx.
Загружаете свои 16 bit в сдвиговый регистр, потом сдвигаете. Выход регистра подаёте на ножку, которую констрейните как lvds.

А сдвиговый регистр потянет битрейт 768 Mgps? То есть параллельные данные идут с частотой 48 МГц. И разрешите ещё вопрос: вы знакомы с ядром custom PHY?
andrew_b
Цитата(Алексей_1990 @ Feb 15 2016, 11:51) *
А сдвиговый регистр потянет битрейт 768 Mgps? То есть параллельные данные идут с частотой 48 МГц.
А почему вы об этом сразу не сказали? Ещё какие нюансы есть? Плисина какая?
Цитата
И разрешите ещё вопрос: вы знакомы с ядром custom PHY?
Работать с ним не доводилось. Название знаю.
Алексей_1990
Цитата(andrew_b @ Feb 15 2016, 12:02) *
А почему вы об этом сразу не сказали? Ещё какие нюансы есть? Плисина какая?
Работать с ним не доводилось. Название знаю.

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

Теперь облегчили задачу: нужно хотябы для начала принять 16 битный параллельный поток и преобразовать его в последовательность. Скорость параллельного потока 48 МГц, выходной соответственно 769 Mgps. Выходная последовательность нужна lvds. Кристалл Cyclone V 5cgxfc5c6f27c7n. За любую помощь буду благодарен.
Александр77
Цитата(Алексей_1990 @ Feb 15 2016, 14:40) *
...Теперь облегчили задачу: нужно хотябы для начала принять 16 битный параллельный поток и преобразовать его в последовательность. Скорость параллельного потока 48 МГц, выходной соответственно 769 Mgps. Выходная последовательность нужна lvds.

А насколько строго должна быть передача по одной паре?
Если требование не жесткое, то можно пустить поток по нескольким парам и снизить требования к скорости в единичном канале.
Цитата(Алексей_1990 @ Feb 15 2016, 14:40) *
Кристалл Cyclone V 5cgxfc5c6f27c7n.

Имея циклон с GXB (со скоростями больше 1Gb/s), несколько странно упираться в lvds. Это имеет смысл лишь при занятых приемо-передатчиках.
Алексей_1990
Цитата(Александр77 @ Feb 15 2016, 22:36) *
А насколько строго должна быть передача по одной паре?
Если требование не жесткое, то можно пустить поток по нескольким парам и снизить требования к скорости в единичном канале.

Имея циклон с 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 (cool.gif" равным 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*cool.gif, то должно быть 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
Цитата(Tue @ Aug 23 2017, 17:16) *
Еще остались непонятными следующие вопросы:

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 отвечает за свой канал. Как я понял их можно дергать независимо друг от друга. Но лучше посмотрите при моделировании.
bogaev_roman
Цитата(Flip-fl0p @ Aug 24 2017, 10:26) *
В модуле 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
Цитата(bogaev_roman @ Aug 24 2017, 10:57) *
Есть проект, в котором используется именно внешняя pll и data_alignment, работоспособность зависит от компиляции к компиляции, т. е. вроде проблемы с таймингами. При попытке посмотреть временные пути столкнулся с проблемой - физика реализована на жестких блоках, анализ закрыт. Как там вообще физика реализована, нужно что-то прописывать во временных ограничениях кроме мультицикла на выходе и частоты на входе pll и ее производных? Временных ошибок нет, анализ unconstraint_patch говорит, что необконстрейненых путей тоже нет.

Скажу так: В LVDS SERDES Transmitter/Receiver IP Cores User Guide явного указания что-либо констрейнить кроме входного клока и данных я не увидел, хотя если честно я совсем плохой советчик по констрейнам. Изучать боле-менее осмысленно я их стал относительно недавно, для меня они ещё темный лес wacko.gif
Интересно, а можно ли как-то получить доступ к жестким блокам ALT_LVDS_RX ? Уж jочень заманчива мысль получить доступ к IR_FIFO_SERDES, который , как я понял, является "железным" высокоскоростным FIFO.
А в режиме extrenal PLL вы так-же ставили клоковый буфер между PLL и LVDS_RX ?
bogaev_roman
Цитата(Flip-fl0p @ Aug 24 2017, 11:20) *
А в режиме extrenal PLL вы так-же ставили клоковый буфер между PLL и LVDS_RX ?

Проект не мой, я пока не ковырял подробно, но на сколько я понял там буфер стоит. Тут еще момент появился - все работает со скоростью 600Mb/s в режиме SDR для циклон5, в документации вроде максимальная частота отталкивается от максимально возможной частоты с выход pll, т.е. 550МГц, что меньше требуемой.
Flip-fl0p
Цитата(bogaev_roman @ Aug 24 2017, 11:25) *
Проект не мой, я пока не ковырял подробно, но на сколько я понял там буфер стоит. Тут еще момент появился - все работает со скоростью 600Mb/s в режиме SDR для циклон5, в документации вроде максимальная частота отталкивается от максимально возможной частоты с выход pll, т.е. 550МГц, что меньше требуемой.

А каков коэффициент дессерелизации ? Может смысл имеет запустить в режиме DDR ? Тогда и частоту можно в 2 раза понизить...
bogaev_roman
Цитата(Flip-fl0p @ Aug 24 2017, 11:34) *
А каков коэффициент дессерелизации ? Может смысл имеет запустить в режиме DDR ? Тогда и частоту можно в 2 раза понизить...

Я об этом и думаю коэффициент - 10, просто все расчеты велись изначально по этому документу https://www.altera.com/support/support-reso...142011_962.html
Flip-fl0p
Цитата(bogaev_roman @ Aug 24 2017, 11:42) *
Я об этом и думаю коэффициент - 10, просто все расчеты велись изначально по этому документу https://www.altera.com/support/support-reso...142011_962.html

В каком режиме работает PLL ? А если вручную фазу частоты приёма крутить, получается стабильный приём ?
bogaev_roman
Цитата(Flip-fl0p @ Aug 24 2017, 11:49) *
В каком режиме работает PLL ?

Direct mode, есть возможность подключить lvds mode. Что это даст?
Flip-fl0p
Цитата(bogaev_roman @ Aug 24 2017, 11:54) *
Direct mode, есть возможность подключить lvds mode. Что это даст?

На сколько я понял там по-разному компенсируется задержка. Точно сказать не могу в чем принципиально отличаются. Где-то я видел хорошее объяснение режимов работы PLL, постараюсь найти и выложить. На сколько я понял правильнее всего применять source-synchronous compensator mode. Но тут я могу ошибаться.
Tue
Цитата(Flip-fl0p @ Aug 24 2017, 10:26) *
В модуле ALT_LVDS_RX в режиме с внутренним PLL, порт rx_inclock - это опорная частота PLL. В режиме внешнего PLL (external PLL) порт rx_inclock - частота дессерилизации


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

Цитата(Flip-fl0p @ Aug 24 2017, 10:26) *
(учитывайте в каком режиме работает 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
Цитата(Tue @ Aug 24 2017, 15:34) *
Это понятно sm.gif



Как это учитывать ? Из документации и каких-то разрозненных источников я понял, что до 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 на данный момент реализовал автоматическую калибровку на центр. Сейчас добавляю динамическую калибровку. В конкретно вашем случае динамическая подстройка нафиг не нужна. У вас положение синхроимпульса и фронтов данных известно заранее и всегда одно и то-же, поскольку зависит только от разводки платы. У меня случай несколько другой. У меня эти значения неизвестны, и всегда разные при каждом включении.
Magnum
А на какое расстояние надо передавать данные?
Tue
Цитата(Flip-fl0p @ Aug 24 2017, 16:36) *
Да действительно 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 на этапе Ассемблера крашится (возникает какая-то ошибка)

Цитата(Magnum @ Aug 25 2017, 08:56) *
А на какое расстояние надо передавать данные?


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

Вчера попробовал не 600Мбит/с, а 300. Та же самая история.
Magnum
Цитата
Если для rx_inclock меняю I/O Standard на 2.5V (хоть это и неправильно)

А почему это неправильно? Все банки с LVDS должны от 2,5 питаться.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.