[Rundll 0]

Всех приветствую!

 

Хотел бы поитересоватся у знатоков VHDL возможно ли следующее описание. Дело в том, что я работаю над проектом IP компрессии и декомпрессии данных и столкнулся с такой проблемой, что за один такт устройство должно выполнить следующие действия : сначало происходит распараллеливание данных для различных вычислений, затем результаты этих выч. должны сравниться, а уж только потом процесс примет нужное решение для дальнейших действий над данными, которые войдут в следующем такте. Т.е. конвейеризация вычислений невозможна, в этом и проблема! Суть вопроса такова: могу ли я описать мою систему таким образом, что сначала по восходящему фронту тактового сигнала (clk'event and clk='1') распараллеливаются данные и над ними сразу происходят несложные вычислительные действия, а по нисходящему сигналу т.е. clk'event and clk='0' данные сравниваются, на основании сравнения выбираются дальнейшие действия над след. данными, далее цикл повторяется. Скажите с точки зрения логики это нормально, но как это будет в железе? Вобще возможно ли такое описание и чего можно ожидать от него?

 

С уважением Никита!

[sK0T 0]

Скажите с точки зрения логики это нормально, но как это будет в железе? Вобще возможно ли такое описание и чего можно ожидать от него?

 

С уважением Никита!

 

Если я правильно понял вопрос, то ответ — «да!». Но какой-то уж вопрос больно расплывчатый…

[des00 25]

Да все в этом мире возможно, но боюсь что такт системный у вас будет не столь высокий.

[ChinasFanat 0]

природу не обманешь.

если все вычисления занимают кучу времени, то никуда не денешься.

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

и не заморачиваться с двумя фронтами.

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

[v_mirgorodsky 0]

Задача выглядит очень простой и стандартной :) Для ее решения достаточно "задержать" входные данные на n тактов на регистрах, принять все необходимые решения за эти такты и скорректировать направление движения потока. Если вычисления требуют значительных временных затрат, то можно поставить FIFO, если одного-двух тактов достаточно, то проще поставить пару регистров.

 

Подобного плана задачи возникают с высокоуровневыми протоколами. Как обычно, нужное поле находится десятком байт позже от начала пакета и решение об обработке пакета может быть принято только после инспекции этого поля. n-ти сатдийный конвеер в этом случае является одним из приемлемых решений проблемы. Подобное решение очень хорошо ложится в Xilinx, потому как сдвиговые регистры в этой архитектуре сравнительно дешевы.

[Rundll 0]

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

 

FIFO не получится поставить и с регистрами тоже! Вся то и заморочь в том ,что систему нельзя конвейеризировать, т.е. понатыкать туда задерживающих регистров. Хотя FIFO можно поставить, но он мгновенно переполнится, т.к. каждое данное требует на обработку 2 такта, а данные приходят по каждому такту и необходимо учитывать тот факт, что размер сообщения заранее неизвестен, вобщем я долго думал над этим, неполучается :(

 

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

[sazh 8]

Суть вопроса такова: могу ли я описать мою систему таким образом, что сначала по восходящему фронту тактового сигнала (clk'event and clk='1') распараллеливаются данные и над ними сразу происходят несложные вычислительные действия, а по нисходящему сигналу т.е. clk'event and clk='0'

 

 

Непонятны опасения здесь присутствующих. Если например посмотреть на прием DDR данных в мегафункции Альтера altddio_in, или высокоскоростной lvds прием данных по link порту (мегафункция), всюду используется передний и задний фронт клока по отдельности (в разных процессах). И где тут тормоза. а как иначе. Или задействуют pll, если это присутствует в кристалле.

[vetal 0]

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

т.к. каждое данное требует на обработку 2 такта, а данные приходят по каждому такту

 

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

 

Если делать в лоб и не "тыкать регистров", то схема может и не развестись.

[des00 25]

Суть вопроса такова: могу ли я описать мою систему таким образом, что сначала по восходящему фронту тактового сигнала (clk'event and clk='1') распараллеливаются данные и над ними сразу происходят несложные вычислительные действия, а по нисходящему сигналу т.е. clk'event and clk='0'

 

 

Непонятны опасения здесь присутствующих. Если например посмотреть на прием DDR данных в мегафункции Альтера altddio_in, или высокоскоростной lvds прием данных по link порту (мегафункция), всюду используется передний и задний фронт клока по отдельности (в разных процессах). И где тут тормоза. а как иначе. Или задействуют pll, если это присутствует в кристалле.

 

Очень интересно, а можно подробнее?

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

как я понял ваше утверждение там производиться достаточно сложная обработка(как в данном случае) на двух фронтах ?

[sazh 8]

можно посмотреть у Альтеры an332.pdf Link порт TigerShack приемная часть два регистра по разным фронтам. потом все приводиться к одному. Все так как Вы говорите. Но это особенность данного протокола. А речь в обсуждении касалась можно или нельзя принимать данные на два регистра по разным фронтам. так почему нельзя?

[des00 25]

можно посмотреть у Альтеры an332.pdf Link порт TigerShack приемная часть два регистра по разным фронтам. потом все приводиться к одному. Все так как Вы говорите. Но это особенность данного протокола. А речь в обсуждении касалась можно или нельзя принимать данные на два регистра по разным фронтам. так почему нельзя?

 

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

[MadMakc 0]

to Rundll :

А какая у вас частота тактового сигнала?

[maksya 0]

... т.к. каждое данное требует на обработку 2 такта, а данные приходят по каждому такту и необходимо учитывать тот факт, что размер сообщения заранее неизвестен, вобщем я долго думал над этим, неполучается :(

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

[vladec 10]

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

[Rundll 0]

Алгоритм впринципе очень просто и программно разрешается около 2 часов работы. Аппаратно всё это выглядит тоже просто, но вот есть уязвимые моменты. Выкладываю суть дела:

 

представим, что мы взяли не начальный момент обработки данных, т.е. процесс обработки уже выполняется во-всю. Данные поступают на вход регистра, в моём случае это ASCII код по такту. Далее по следующему такту происходит распараллеливание: на один выход регистра подаётся ASCII код для вычисления эфективной хеш-функции, причём обращаю ваше внимание, что она вычисляется именно на базе предыдущей логики, что играет ключевую роль. Хеширование происходит асинхронно, в итоге хеш-функция определяет эффективный адрес ОЗУ, в этот же такт на компаратор попадает копия ASCII кода всё из того же буферного регистра. Если по адресу ОЗУ действительно находтится такое данное: в кодовый регистр заносим значение счётчика кодов, иначе - записываем по этому адресу данное, в регистр кодов записываем ASCII код из буфферного регистра. Далее цикл повторяется, только хеширование будет выполняться (ОЧЕНЬ ВАЖНО) на базе нового вошедшего в буфферный регистр ASCII кода И определённого в предыдущем такте значения в регистре кодов

 

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