AlexZabr 0 31 января, 2008 Опубликовано 31 января, 2008 · Жалоба Пишу дизайн где есть более чем 2х ступеньчатые условия как фунция от отсчетов счетчиков. Можно реализовать с помощью, скажем 4 if/elsif либо с помошью case. Кроме того есть другой кусок дизайна где условия реализуються с помощью 8 if/elsif либо опять-же через case. Счетчик отсчитывает клоки, определенные действия выполняются в определенных "окнах" счетчика, "окна" идут последовательно одно за другим. 4х ступенчатая часть реализуется с помощью первого ifа и затем 3 eslifов (каждый проверяет счетчик на условия count < X, где Х - потолок отсчета заданного окна, ессно Х меняется как функция от нужного окна). У 8-ступенчатого куска - тоже самое только там первый if и далее 7 elsifов. С другой стороны можно написать более эстетично с помощью caseов, но тогда в каждом условии caseа нужно определять взаимо-исключающее состояние счетчиков (т.е. Х1 < count < Х2) что не требовалось в eslifах (ибо они сами взаимо-исключающие). Я так понимаю в случае if/elsif синтезатор строит компараторы на счетчик с заданными значениями границ "окон", затем делает взаимо-исключающую логику. А в случае с case, наверно синтезатор не будет наверно строить взаимо-исключающую логику после компараторов, но сами компараторы будут строиться многоступеньчато... Так что-же будет более оптимально в плане ресурсов/скорости ? (хотя в конкретном случае нет надобности в крайних скоростях...) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
RHnd 0 31 января, 2008 Опубликовано 31 января, 2008 · Жалоба Не пытаясь угадывать заранее, предлагаю собрать простенький проект из счетчика и if-elsif, а потом из счетчика и case. И сравнить их по результатам разводки, а так же посмотреть, что там в RTL создалось. Времени займет немного, а полезно. Сам бы сейчас сделал, но на той машине, за которой сижу, квартуса нет. :) Вообще, это еще и от кристалла зависит, скольки входовые там LUT и прочее. Например, на сколько помню, альтера рекомендует делать примерно так: x1=0<=Counter<Up1; x2=Up1<=Counter<Up2; x3=Up2<=Counter<Up3; x4=Up3<=Counter; Далее x1x2x3x4 сводится к {a1,a2}, давая все варианты от 00 до 11. a1=!(x1||x2); a2=(x2||x4); а потом делается full case для {a1,a2}. Но воспоминания эти смутны, могу что-то напутать. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
YuryL 0 6 февраля, 2008 Опубликовано 6 февраля, 2008 · Жалоба case более компактный и быстрый, т.к. у него нет приоритетов межде условиями Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
iosifk 3 6 февраля, 2008 Опубликовано 6 февраля, 2008 · Жалоба У 8-ступенчатого куска - тоже самое только там первый if и далее 7 elsifов. Так что-же будет более оптимально в плане ресурсов/скорости ? (хотя в конкретном случае нет надобности в крайних скоростях...) То, что Вы описываете - это решение "в лоб", а оно никогда не будет эффективным. Ведь счетчик не может одновременно иметь несколько значений. Следовательно на самом деле всего-то и нужно иметь вычитатель нижнего значения и только два уровня для сравнений. В начале заносим в уровни данные для первого окна - низ и верх. Добежал счетчик до нижнего уровня - производим вычитание этого значения из уровней и из счетчика и запоминает, что находимся в первом окне. Переросли за первое окно - назначаем уровни для второго окна. Ну и так далее. Что-то типа нониуса на штанген-циркуле... Вместо 7 схем сравнения - имеем только две, но загружаемые и один вычитатель. Константы можно хранить в маленьком блоке памяти... Ну и простейший автомат, который будет загружать уровни и заносить в регистр номер ступени. По номеру ступени нужно выбирать уставки. А если в проекте есть контроллер, то такие дела можно ему дать как команду и он легко справится с такой работой. Даже без наращивания схем сравнения. Удачи! Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AsJohnAs 0 6 февраля, 2008 Опубликовано 6 февраля, 2008 · Жалоба Ну и так далее. Что-то типа нониуса на штанген-циркуле... Вместо 7 схем сравнения - имеем только две, но загружаемые и один вычитатель. Константы можно хранить в маленьком блоке памяти... Ну если рассмотреть эту схему с загружаемым сравнением и конвеерное сравнение то надо обезательно смотреть на кристал и на разрядность данных. Потому как иногда загрузка и сравнение могут выполняться дольше ... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
iosifk 3 6 февраля, 2008 Опубликовано 6 февраля, 2008 · Жалоба Ну если рассмотреть эту схему с загружаемым сравнением и конвеерное сравнение то надо обезательно смотреть на кристал и на разрядность данных. Потому как иногда загрузка и сравнение могут выполняться дольше ... А на самом деле можно иметь только одну уставку... Только трактовать ее по-разному: "Нижняя" - "Верхняя" ... Действительно, для сравнения с загружаемой уставкой требуется больше ресурсов, чем для сравнения с константой. Но ведь "сравнивалка" нужна только одна, а не 7 ! Да и при разбивке на зоны общая разрядность уменьшится... Пусть хоть и на 2 разряда, но все же.. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AsJohnAs 0 6 февраля, 2008 Опубликовано 6 февраля, 2008 · Жалоба А на самом деле можно иметь только одну уставку... Только трактовать ее по-разному: "Нижняя" - "Верхняя" ... Действительно, для сравнения с загружаемой уставкой требуется больше ресурсов, чем для сравнения с константой. Но ведь "сравнивалка" нужна только одна, а не 7 ! Да и при разбивке на зоны общая разрядность уменьшится... Пусть хоть и на 2 разряда, но все же.. Я об этом не подумал :) Но для трактовки нижней/верзней тоже нужно что-то сделать.... Но в итоге тогда этот алгоритм будет здорого выигравать! Круто - возьму на вооружение! Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
iosifk 3 6 февраля, 2008 Опубликовано 6 февраля, 2008 · Жалоба Я об этом не подумал :) Но для трактовки нижней/верзней тоже нужно что-то сделать.... Но в итоге тогда этот алгоритм будет здорого выигравать! Круто - возьму на вооружение! на предыдущей работе я такую штуку проходил. Там надо было параллелить два DC-DC замыкая полевики, причем параллелить можно было только если они имели одинаковое выходное напряжение. Напряжение измерялось АЦП и эти цифры обрабатывались в ПЛИСЕ. Но и кроме этого еще до черта алгоритмов... У меня там были сделаны два софт-микропроцессора, схема сравнения входила в состав микропроцессора и сравнивала состояние двух регистров процессора, а программно анализировались флаги "больше или равно" и "меньше"... Так что такая функция при наличии микропроцессора реализуется "попутно" со всем остальным... и уже заодно, один микроконтроллер 17-бит, он гонял данные, а другой - 1бит, вот он разбирал все логическое управление на примерно 50 шт. реле и обрабатывал все алгоритмы для 17-ти битного, т.е он ему сплавлял состояние автомата... Удачи! Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexZabr 0 6 февраля, 2008 Опубликовано 6 февраля, 2008 · Жалоба То, что Вы описываете - это решение "в лоб", а оно никогда не будет эффективным. Ведь счетчик не может одновременно иметь несколько значений. Следовательно на самом деле всего-то и нужно иметь вычитатель нижнего значения и только два уровня для сравнений. В начале заносим в уровни данные для первого окна - низ и верх. Добежал счетчик до нижнего уровня - производим вычитание этого значения из уровней и из счетчика и запоминает, что находимся в первом окне. Переросли за первое окно - назначаем уровни для второго окна. Ну и так далее. Что-то типа нониуса на штанген-циркуле... Вместо 7 схем сравнения - имеем только две, но загружаемые и один вычитатель. Константы можно хранить в маленьком блоке памяти... Ну и простейший автомат, который будет загружать уровни и заносить в регистр номер ступени. По номеру ступени нужно выбирать уставки. А если в проекте есть контроллер, то такие дела можно ему дать как команду и он легко справится с такой работой. Даже без наращивания схем сравнения. Удачи! Да, спасибо, интересный вариант. Пока сделал "в лоб", попробую по вашему рецепту, сравню после синтеза. А сколько ресурсов занимает вычитание ? По вашему рецепту вроде и схемы сравнения получаются значительно меньшей разрядности чем "в лоб", или я ошибаюсь ? (ибо считают только в пределах наибольшего окна, а "в лоб" у меня счетчик считает "сквозь все окна"..) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
iosifk 3 7 февраля, 2008 Опубликовано 7 февраля, 2008 · Жалоба А сколько ресурсов занимает вычитание ? По вашему рецепту вроде и схемы сравнения получаются значительно меньшей разрядности чем "в лоб", или я ошибаюсь ? (ибо считают только в пределах наибольшего окна, а "в лоб" у меня счетчик считает "сквозь все окна"..) Если 8 окон, то на 3 разрада меньше... Не так сильно много, но все же... По поводу сумматора-вычитателя вариант суммирования константы имеет вдвое меньше ресурсов, по сравнению с суммированием данных от регистра... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
