[MadMakc 0]

Данные поступают на вход регистра, в моём случае это ASCII код по такту.

Какая частота этого такта? Если это 5 МГц, то вылечить можно, если 200, то надо думать.

[maksya 0]

Алгоритм упрощён, но уже понятно, что по такту такое заморочить сложновато, ещё сложнее сделать это очень красиво и эффективно!

я предполагал такой подход (см. мое собщение выше) :

[Rundll 0]

Частота 120 МГц

 

 

CLK - это ваша тактовая частота.

PLL_CLK - опорная частота, умноженная на PLL. Коэффициент умножения определите сами, в зависимости от операций преобразования.

 

Хм.. интересно!

 

Кстати, я вот тут ещё один вариант надумал, сейчас тружусь над ним:

 

А если по каждому клоку, додумывать логику предыдущего (если данные предыдущего цикла есть в ОЗУ, подготовить новый код, иначе записать в память по предыдущему адресу), а уж потом по результатам вычислять новую ХЕШ на базе пред. и нов. данных и посылать новые данные на компаратор ? ОЗУ с компаратором реализованы совместно в блок так что за один клок, он сразу выдаёт ответ есть ли по этому адресу такие данные или нет, т.е. на вых. блока, логический ноль или единица...

 

Пока смоделировал в отсутсвии ОЗУ, работает, и частота 270 МГц!

[des00 25]

Хмм прочитав что вы пишете об алгоритме я не вижу причин почему нельзя задержать поток на несколько тактов. Кстати похожая задача решаеться в декодерах видеопотока, где нужно вырезать тайм референс метки.

Рекомендую вам взять бумагу или софт для проектирования алгоритмов и разрисовать алгоритм с определением причинно следственных связей + расписать тайм лайн (пример см. у maksya) тогда сразу станет понятно, что можно отбрасывать, что нет а также задержки операций и т.д.

Думаю что задача должна решаться без финтов с частотой :)

 

2 maksya а в каком софте это у вас было нарисованно ?

[Rundll 0]

To des00

 

Я ведь отметил, что это лайт версия алгоритма, на самом деле, в нём также имеется два параллельных блока ОЗУ (1-ый 20 разрядный, 2-ой 14 разрядный по 16384 адресов каждый блок) кода и строк которые тоже требуют определённой логики. Кстати как вы относитесь к предложенной товарищем maksya финтом с частотой. По его предложении я смогу реализовать конвейер в моей системе, тем самым максимально увеличив тактовую частоту устройства вцелом, даже умножив на коэффициент внутр. частоты я получу впринципе неплохую схему, думаю не ниже 100 МГц . Меня интересует ваше мнение?! Что вы скажете о моём предложении додумывать логику в след. такте? Как вы себе представляете задерживание потока данных, честно, я вобще не представляю!?

Изменено 28 июня, 2006 пользователем Rundll

[Golikov 0]

Про частоту,

естественно обрабатывать по восходящему и падающему фронту частоты 50 МГц, это абсолютно тоже самое что работать по одному восходящему частоты 100 МГц. Это простая физика смысла частоты (нормально завернул :)).

 

Теперь далее в ксалинксах (да и других) есть блоки ПЛЛ которые умножают частоту на 2, или всегда на счетчике можно поделить частоту, поэтому всегда можно сделать так, что в системе будет быстрый и медленный клок, и вы всегда сможете сделать за 1 такт одного клока несколько тактов другого. Предложения идея с 2 клоками, настолько же работоспособна, насколько она очевидна, если частоты хватит, то работать будет!

 

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

 

На счет конвейера, я попробую привести пример алгоритма не конвейеризуемого и конвейеризуемого, и вы скажите на какой более похож ваш.

 

A0..N -входные данные

B0..N -выходные

B(n)=A(n)/B(n-1); - если эта операция несколько тактов.

Данную задачу нельзя конвейеризовать, потому что Бн нельзя вычислить до вычисления Б(н-1), а он вычисляется несколько тактов. И каждое новое а(н) удлиняет конвейер, на длину вычислений, и конвейер скоро переполниться.

 

а вот задача

B(n)=A(n)/A(n+k); - эта операция тоже несколько тактов.

ее можно конвейеризовать. Длина конвейера ровна числу тактов обработки+k на запасание следующих к значения А, и темп поступления данных равен темпу вывода.

 

Так вот по описанию, ваша задача больше похоже на 2 вариант, потому вам все и предлагают ее конвейеризовать. Хотя может это просто сложность понимания математической идеи изложенной вами.

[des00 25]

Я ведь отметил, что это лайт версия алгоритма, на самом деле, в нём также имеется два параллельных блока ОЗУ (1-ый 20 разрядный, 2-ой 14 разрядный по 16384 адресов каждый блок) кода и строк которые тоже требуют определённой логики.

 

почему я вам и говорю вы распишите алгоритм сразу станет видно всю контекстную зависимость между тактами по данным. я предпочитаю работать так: алгоритм -> timeline -> функционал реализации -> реализация на ХДЛ.

 

Кстати как вы относитесь к предложенной товарищем maksya финтом с частотой. По его предложении я смогу реализовать конвейер в моей системе, тем самым максимально увеличив тактовую частоту устройства вцелом, даже умножив на коэффициент внутр. частоты я получу впринципе неплохую схему, думаю не ниже 100 МГц .

 

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

 

Меня интересует ваше мнение?! Что вы скажете о моём предложении додумывать логику в след. такте?

 

тоже нормальное решение, обычный пример конвейеризации. Т.е. что то сложное разбиваем на 2 ступени, развязанные по данным между собой и имеем конвейер с латентностью в 2 такта и периодом счета в 1 такт. Если по данным развязки нет, то имеем мини АЛУшку с периодом счета 2 такта.

 

Как вы себе представляете задерживание потока данных, честно, я вобще не представляю!?

 

На примере декодера потока ITU-T 656 в реализации от хилых. На декодирование TRS у них уходит 2 такта и естественно если прямо в лоб снять сигнал и синхру у них будет расфазирование в 2 такта. Чтобы этого избежать они задерживают поток на 2 такта. В результате у них на выходе декодера идет сфазированая синхра и данные.

[Rundll 0]

Ваша позиция мне ясна, попробую расписать алгоритм и подумать над реализацией, спасибо!

[maksya 0]

2 maksya а в каком софте это у вас было нарисованно ?

КОМПАС 5.11 LT :) + Paint (для конвертации в JPEG) LT весит мало, удобно на флешке держать, а так 7-ой версией пользуюсь.

[Rundll 0]

B(n)=A(n)/B(n-1); - если эта операция несколько тактов.

Данную задачу нельзя конвейеризовать, потому что Бн нельзя вычислить до вычисления Б(н-1), а он вычисляется несколько тактов. И каждое новое а(н) удлиняет конвейер, на длину вычислений, и конвейер скоро переполниться.

 

а вот задача

B(n)=A(n)/A(n+k); - эта операция тоже несколько тактов.

ее можно конвейеризовать. Длина конвейера ровна числу тактов обработки+k на запасание следующих к значения А, и темп поступления данных равен темпу вывода.

 

Так вот по описанию, ваша задача больше похоже на 2 вариант, потому вам все и предлагают ее конвейеризовать. Хотя может это просто сложность понимания математической идеи изложенной вами.

 

Я вас сейчас немного удевлю наверное, но в проект подразумевает вариант и 1 и 2, только какой из них решает именно ЛОГИКА!

Если условие истино выполняется вариант 2, если ложно- вариант 1. Только вместо операции деления- функция хэширования.

[maksya 0]

Про частоту,

естественно обрабатывать по восходящему и падающему фронту частоты 50 МГц, это абсолютно тоже самое что работать по одному восходящему частоты 100 МГц. Это простая физика смысла частоты (нормально завернул :)).

 

Теперь далее в ксалинксах (да и других) есть блоки ПЛЛ которые умножают частоту на 2, или всегда на счетчике можно поделить частоту, поэтому всегда можно сделать так, что в системе будет быстрый и медленный клок, и вы всегда сможете сделать за 1 такт одного клока несколько тактов другого. Предложения идея с 2 клоками, настолько же работоспособна, насколько она очевидна, если частоты хватит, то работать будет!

 

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

Не факт, что работать с двумя фронтами внутри ПЛИС хорошо. Вообще, насколько мне известно, DDR архитектура применяется только при передаче данных (обмен с DDR SDRAM, LINK-порты с LVDS ...), а не для обработки. Сейчас не вспомню где читал заметку, но было мнение что FPGA Altera терпеть ненавидят задние фронты (исключением являются только IP контроллера DDR SDRAM). Сама архитектура FPGA не предполагает двухфронтовости. Однако, меня в форуме уже один раз поправляли - есть Coolrunner II у Xilinx, так вот у них триггеры по двум фронтам фурычат.

[Rundll 0]

Однако, меня в форуме уже один раз поправляли - есть Coolrunner II у Xilinx, так вот у них триггеры по двум фронтам фурычат.

 

Не хотелось бы ограничиваться одним лишь кулранером. Да и вобще идея дву-фронтового контроля событий была не совсем удачной ИМХО. Тем более, как видите, были найдены более изящные и эффективные способы устранения проблемы, осталась чисто исследовательская работа, для выбора наиболее подходящего и лучшего.

[disel 0]

A0..N -входные данные

B0..N -выходные

B(n)=A(n)/B(n-1); - если эта операция несколько тактов.

Данную задачу нельзя конвейеризовать, потому что Бн нельзя вычислить до вычисления Б(н-1), а он вычисляется несколько тактов. И каждое новое а(н) удлиняет конвейер, на длину вычислений, и конвейер скоро переполниться.

 

Не очень понял, почему нельзя? Вы привели обычное рекурсивное вычисление. Например сумма квадратов входной величины так вычисляется: Е(n) = E(n-1) + x2(новое) - x2(старое). И между Е(n) и E(n-1) один такт конвейера. Как уже было совершенно справедливо замечено выше, конвейер не может переполнится, поскольку данные из него выходят с той же скоростью, с какой заходят.

 

Я вас сейчас немного удевлю наверное, но в проект подразумевает вариант и 1 и 2, только какой из них решает именно ЛОГИКА!

Если условие истино выполняется вариант 2, если ложно- вариант 1. Только вместо операции деления- функция хэширования.

 

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

[Golikov 0]

ну один и тот же триггер по 2 фронтам щелкать это конечно не очень хорошо... а 2 триггера друг за другом стоящие вполне... А по заданию 2 друг за другом можно, потому и говорил что нет разницы между по 2 фронтам и по одному фронту двойной частоты

 

 

на счет удивления, не удивили, просто хотелось прояснить, если такая вещь то конвейер вам и вправду не поможет это точно, разгоняйте клок. Можно попробовать распараллелить алгоритм, работать на меньшем клоке, но в параллель...

 

насчет почему нельзя конвейеризовать, берем мой пример

допустим Б0 уже есть.

 

берем А1, считаем Б1=А1/Б0, допустим результат имеем через 2 такта.

на следующем такте получаем А2, для расчета Б2, нам необходим Б1, но оно будет только через такт, тут можно поставить накопитель

Сохраним А2, А3, и в этот момент у нас готов Б1 и мы можем считать Б2, но у нас уже сохранено А3, и через 2 такта появления Б2, которое нам необходимо для Б3 пройдет еще 2 такта и мы вынуждены уже сохранить А4, А5, и так далее,

с каждым вычисленным очередным Б, у нас накапливается еще 2 А сверху уже накопленных, и такая ситуация не разрешиться до тех пор пока не прекратиться поток А. А если он большой конвейер переполниться... Вот почему нельзя.

 

Насчет в параллель 2 варианта , я думаю

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

Изменено 28 июня, 2006 пользователем Golikov A.

[disel 0]

Да, действительно если вычисление операции занимает несколько тактов, плохо с конвейером. 2 Golikov A. :cheers: Тут есть над чем подумать.

А в Вашем случае вычисление в несколько тактов необходимо? Если операция (в примере это /) не требует памяти, а является комбинационной, то ее можно вычислить за один такт. И следовательно она легко заталкивается в конвейер. Вопрос только в длительности этого такта.