[DmitryR 0]

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

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

[nonedub 0]

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

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

Изменено 27 августа, 2009 пользователем nonedub

[DmitryR 0]

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

[yudu 0]

2 yudu - идеи есть всегда

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

 

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

 

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

 

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

 

 

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 0]

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

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

[nonedub 0]

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

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

[yudu 0]

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

 

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

 

Тоесть кроме посылок синхронизированных данных по линииям lvds, нужно отдельно давать синхронизацию для плиса на время этих посылок

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

[DmitryR 0]

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

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

[Алексей_1990 0]

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

[andrew_b 14]

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

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

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

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

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

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

[Алексей_1990 0]

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

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

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

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

[andrew_b 14]

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

 

Не нужно никаких altlvds_tx.

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

[Алексей_1990 0]

Не нужно никаких altlvds_tx.

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

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

[andrew_b 14]

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

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

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

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

[Алексей_1990 0]

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

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

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

Для решения этой задачи начал разбираться с высокоскоростными аппаратными приемопередатчиками custom PHY. Не вышло, очень много неизвестных параметров.

 

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