Jump to content

    
Sign in to follow this  
DENth

Интерфейс между МК и ПЛИС

Recommended Posts

Уважаемое сообщество! Есть следующий вопрос по взаимодействию ПЛИС и МК:

Имеем ARM7 LPC2468 и ПЛИС Cyclone 2. ПЛИС подключена к контроллеру внешней памяти ARMа. Данный интерфейс предназначен для работы с асинхронной памятью. Относительно ПЛИС сигналы Write, Read с МК асинхронны. На МК и ПЛИС поступает частота с единого генератора - 12Мгц, но в МК она перемножается до 72МГц - частота ядра. Длительность сигналов контроллера внешней памяти зависит от этой частоты. Частота 72МГц на ПЛИС не идет. Вопрос - как обеспечить максимальное быстродействие между МК и ПЛИС?

 

Read и Write пропускаю через два последовательных триггера для исключения метастабильного состояния. Но как поступать дальше? Использовать их для тактирования внутренних цепей ПЛИС для записи или чтения состояния регистров и памяти вроде как нельзя. Нужен явный клок. Но его нет с МК.

 

Сейчас получилось сделать так: стробирую эти сигналы внутренней частотой 72МГц, сформированной на PLL ПЛИС. Получаю сигнал длительностью один период частоты 72МГц. Этот сигнал подаю как сигнал разрешения на внутренние цепи. А клок 72МГц как клок на эти же цепи. Все работает. Но если в МК ускорять работу по этому интерфейсу, то всё перестает работать. Видимо пока я синхронизирую Read, Write внутри ПЛИС, МК уже захлопывает данные, а ПЛИС их еще не успела выставить. Стробировать большей частотой не получается, начинает ругаться временной анализатор.

 

Как сделать правильно?

Share this post


Link to post
Share on other sites

Во-первых, лично я для исключения метастабильности использую защелкивание входных сигналов только на один триггер. До сих пор не подводило. Поэтому считаю, что два последовательных триггера - это лишняя перестраховка.

Во-вторых, у Вас частота данных на борту МК и частота защелкивания входнух данных на ПЛИС - одинаковые. Поэтому, если Вы защелкиваете Write, также и защелкивайте DATA_IN, а уже потом работайте с результатом в домене 72 МГц.

Share this post


Link to post
Share on other sites

а что значит «ускорять»? И что именно перестает работать? Вы пишите данные с МК а потом забирает результат с ПЛИС? Какая латентность этой обработки? И честно гоаоря не вижу криминала стробы чтения записи подать на входы глобал клоков, а потом передать из на обработку в другой плисовый клоковый домен через фифо например. Также неясно ,что вы там наворотили, что уже на 72 мгц ругается анализатор.

Share this post


Link to post
Share on other sites

Относящиеся к делу фрагменты кода - в студию! Тогда разговор будет конкретным, а помощь - быстрой и эффективной. Вроде ничего потенциально высокоценного в описанном интерфейсном модуле не предвидится, так что от его публикации никто не пострадает :).

Share this post


Link to post
Share on other sites
И что именно перестает работать?

Правильный вопрос. Что значит "перестает работать"?

Я так понял - при однократном WRITE с МК - ПЛИС принимает данные корректно. При зацикливании этого процесса на МК - ПЛИС принимает абракадабру/нули/единицы/предыдущее значение/... Подчеркните нужное.

Share this post


Link to post
Share on other sites
Read и Write пропускаю через два последовательных триггера для исключения метастабильного состояния. Но как поступать дальше? Использовать их для тактирования внутренних цепей ПЛИС для записи или чтения состояния регистров и памяти вроде как нельзя. Нужен явный клок. Но его нет с МК.

 

Как сделать правильно?

 

Два триггера - это правильно.

А дальше усть варианты. Если ПЛИС значительно быстрее, чем МК, то с точки зрения МК все будет укладываться в один цикл "записи". А вот если их скорости примерно одинаковы, то тогда при чтении надо будет переходить к "пакетному" режиму. Т.е. при первом чтении в ПЛИС запишется адрес и перетактируются данные из памяти в выходной регистр, а при втором - данные уйдут в МК. И далее, если сделаете пост-инкремент адреса, то можно будет делать чтение берстом (пакетом)...

А более подробно - у меня на сайте "Краткий Курс", раздел CDC... Кстати и Вам, olegras тоже рекомендую...

 

Share this post


Link to post
Share on other sites
Два триггера - это правильно.

... раздел CDC... Кстати и Вам, olegras тоже рекомендую...

Читал, и постоянно пользуюсь. Насчет двух триггеров - я ведь не отрицаю и полностью подтверждаю. Я лишь говорю что если частоты двух доменов равны (а у DENth они равны) - то достаточно одного триггера. Но он должен быть! Во всяком случае, этот факт проверен много раз на практике на частотах до 100 МГц включительно.

Share this post


Link to post
Share on other sites
Во-первых, лично я для исключения метастабильности использую защелкивание входных сигналов только на один триггер. До сих пор не подводило. Поэтому считаю, что два последовательных триггера - это лишняя перестраховка.

Во-вторых, у Вас частота данных на борту МК и частота защелкивания входнух данных на ПЛИС - одинаковые. Поэтому, если Вы защелкиваете Write, также и защелкивайте DATA_IN, а уже потом работайте с результатом в домене 72 МГц.

 

Частоты одинаковы, но источники частот разные. Не знаю - можно ли их считать синхронными друг другу. Обе частоты формируются PLL. Но одна в МК, другая в ПЛИС. Если завести обе частоты в SignalTap квартуса, то выглядят они синхронными друг другу, но можно ли достоверно сказать, что это так? Во-вторых в документации на МК нет временной диаграммы, связывающей частоту ядра с времянками чтения и записи по интерфейсу внешней памяти. Из-за этого всего не ясно - когда защелкивать входные данные и когда должны быть выставлены выходные для их правильного защелкивания в МК?

 

Привожу временные диаграммы чтения и записи МК, а также табличку с длительностями сигналов.

3129063.png

 

3098343.png

 

3092199.png

Share this post


Link to post
Share on other sites
Я лишь говорю что если частоты двух доменов равны (а у DENth они равны) - то достаточно одного триггера. Но он должен быть!

 

Да заявы пошли не шуточные. Ну так на всякий случай сообщаю что флопов должно быть как минимум два.

Share this post


Link to post
Share on other sites
а что значит «ускорять»? И что именно перестает работать? Вы пишите данные с МК а потом забирает результат с ПЛИС? Какая латентность этой обработки? И честно гоаоря не вижу криминала стробы чтения записи подать на входы глобал клоков, а потом передать из на обработку в другой плисовый клоковый домен через фифо например. Также неясно ,что вы там наворотили, что уже на 72 мгц ругается анализатор.

 

Под ускорением подразумеваю увеличение количества циклов чтения/записи со стороны МК за единицу времени. В ARMе сделано так, что при этом длительности сигналов write, read уменьшаются с увеличением частоты обращений. Зависят от неких величин, которые приведены в табличке выше.

 

Стробы записи и чтения я как раз-таки завел на глобал клоки. При 72МГц анализатор пока не ругается, но при увеличении частоты стробирования начинаются проблемы. Код попробую подготовить, чтобы стало более понятнее.

 

Правильный вопрос. Что значит "перестает работать"?

Я так понял - при однократном WRITE с МК - ПЛИС принимает данные корректно. При зацикливании этого процесса на МК - ПЛИС принимает абракадабру/нули/единицы/предыдущее значение/... Подчеркните нужное.

 

Нет, дело не в однократном-многократном. Проблема именно в общих принципах правильного построения подобного взаимодействия.

 

Два триггера - это правильно.

А дальше усть варианты. Если ПЛИС значительно быстрее, чем МК, то с точки зрения МК все будет укладываться в один цикл "записи". А вот если их скорости примерно одинаковы, то тогда при чтении надо будет переходить к "пакетному" режиму. Т.е. при первом чтении в ПЛИС запишется адрес и перетактируются данные из памяти в выходной регистр, а при втором - данные уйдут в МК. И далее, если сделаете пост-инкремент адреса, то можно будет делать чтение берстом (пакетом)...

А более подробно - у меня на сайте "Краткий Курс", раздел CDC... Кстати и Вам, olegras тоже рекомендую...

 

Считаем, что нужно построить систему с одним циклом записи, чтения. При пакетном производительность упадет в два раза? Это крайне не желательно.

Ваш курс по описанию временных ограничений с удовольствием читал и постоянно заглядываю при случае. Пожалуй, самое толковое, что есть в рунете по данной теме. Спасибо!

Edited by DENth

Share this post


Link to post
Share on other sites
Стробы записи и чтения я как раз-таки завел на глобал клоки. При 72МГц анализатор пока не ругается, но при увеличении частоты стробирования начинаются проблемы.

Конечно не ругается - ему ведь неизвестны времянки на СРАМ интерфейсе ЛПЦ

 

Share this post


Link to post
Share on other sites
Конечно не ругается - ему ведь неизвестны времянки на СРАМ интерфейсе ЛПЦ

 

Не могли бы вы подсказать, как анализатору их сообщить? А то у меня как и у анализатора видимо проблемы с этим =)

Share this post


Link to post
Share on other sites
Да заявы пошли не шуточные. Ну так на всякий случай сообщаю что флопов должно быть как минимум два.

Зря Вы иронизируете. Давайте разберемся. Может мы говорим о разных вещах.

Есть входные данные. Пусть будут write_in и data_in. Для простоты остальные сигналы не рассматриваем.

Код на VHDL:

port(
...
write_in: in std_logic; -- строб записи
data_in: in std_logic_vector(15 downto 0) -- данные
);

Есть сигналы

signal	write_in_t: std_logic;
signal	write_in_t0: std_logic;
signal	data_in_t: std_logic_vector(15 downto 0);
signal	data_in_t0: std_logic_vector(15 downto 0);
...
signal	data_s: std_logic_vector(15 downto 0);

Пример первый - без защелки

...
if rising_edge(clk) then
if(write_in = '1') then
	data_s <= data_in + x"abcd";
end if;
end if;

Пример второй - с одной защелкой

...
if rising_edge(clk) then
write_in_t <= write_in;
data_in_t <= data_in;
if(write_in_t = '1') then
	data_s <= data_in_t + x"abcd";
end if;
end if;

Пример третий - с двумя защелками

...
if rising_edge(clk) then
write_in_t <= write_in;
write_in_t0 <= write_in_t;
data_in_t <= data_in;
data_in_t0 <= data_in_t;
if(write_in_t0 = '1') then
	data_s <= data_in_t0 + x"abcd";
end if;
end if;

Я говорю про второй пример. Использую на практике несколько лет. На частотах до 100 МГц включительно. Еще ни разу не сбоило. При одинаковых частотах входного и внутреннего доменов - стабильность (и корректность) от сдвига фаз не зависит. Попробуйте сами.

 

DENth я похожую задачу делал для связки ЦСП от TI со Спартаном 3. Работало на частоте шины (между ними) 85 МГц. Представьте свою часть кода.

 

 

Share this post


Link to post
Share on other sites
Я говорю про второй пример. Использую на практике несколько лет. На частотах до 100 МГц включительно. Еще ни разу не сбоило. При одинаковых частотах входного и внутреннего доменов - стабильность (и корректность) от сдвига фаз не зависит. Попробуйте сами.

 

DENth я похожую задачу делал для связки ЦСП от TI со Спартаном 3. Работало на частоте шины (между ними) 85 МГц. Представьте свою часть кода.

Вау. А на данные то зачем синхронизаторы ставить?????

 

> от сдвига фаз не зависит

А вы их сдвигали?

 

Share this post


Link to post
Share on other sites
Вау. А на данные то зачем синхронизаторы ставить?????

 

> от сдвига фаз не зависит

А вы их сдвигали?

 

А Вы поставьте и проверьте. А сдвиг фаз смотрел на осцилле. В разных проектах и в разных реализациях - сдвиг был ессно разный. И вообще я поднял этот вопрос в ответ на "Видимо пока я синхронизирую Read, Write внутри ПЛИС, МК уже захлопывает данные, а ПЛИС их еще не успела выставить". Если защелкивать только WRITE (при чтении с МК) - так и будет. Но у DENth стробы заведены на клоковые входы. Значит он (предполагаю) принимает и передает данные по фронтам этих стробов, и значит у него проблема в другом. Выложит код - посмотрим.

Насчет двух флопов - я ведь не против. Ставьте хоть 15.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this