[des00 25]

Мой последний пост на тему 8b10b кодера написанного на высоком уровне. Давно не писал, т.к. при послойной алгоритмической оптимизации нарыл кое что интересное. Настройки проекта не изменялись.

Итак следующий шаг был объединение таблиц для данных и управления в одну. Итогом стал файл enc8b10b_4.v Который показал следующий результат

Device : EP3C5E144C8
Timing Models : Final
Total logic elements : 176 / 5,136 ( 3 % )
    Total combinational functions : 164 / 5,136 ( 3 % )
    Dedicated logic registers : 38 / 5,136 ( < 1 % )

Info: Fmax Summary
    Info:                Restricted
    Info:         Fmax         Fmax      Clock Note
    Info: ============ ============ ========== =====================
    Info:   183.02 MHz   183.02 MHz        clk

Налицо ухудшение и на первый взгляд кажется что метод описания плохой, но это не так. Ква не может положить таблицы в ROM, по причинам что я указал (хотя данные в ROM на автомате положить можно, кто хочет проверить уберите сигнал сброса с dataout). А для реализации таблицы на LUT, занимаемый ей ресурс растет в ~2^N раз, где N увеличение разрядности адреса. Другими словами для таблиц на LUT лучше шире, чем глубже.

 

Поэтому следующий шаг анализируем таблицы кодирования данных и управления, и уменьшаем их в 2 раза и соответственно этому уменьшению изменяем логику. Итогом стал файл enc8b10b_5.v с результатом

Device : EP3C5E144C8
Timing Models : Final
Total logic elements : 93 / 5,136 ( 2 % )
    Total combinational functions : 79 / 5,136 ( 2 % )
    Dedicated logic registers : 38 / 5,136 ( < 1 % )

Info: Fmax Summary
    Info:                Restricted
    Info:         Fmax         Fmax      Clock Note
    Info: ============ ============ ========== =====================
    Info:   205.68 MHz   205.68 MHz        clk

Уже лучше, но всё же не то. Таймквест показывает проблему в пути от rd до rd, если внимательно проанализировать код модуля enc8b10b_5.v, в котором rd считается на 4-х таблицах, то можно увидеть что однобитный rd лучше формировать на двух, пусть и более толстых таблицах, чем на 4х + стыковая логика. Итогом стал файл enc8b10b_6.v Который дал результат

Device : EP3C5E144C8
Timing Models : Final
Total logic elements : 86 / 5,136 ( 2 % )
    Total combinational functions : 72 / 5,136 ( 1 % )
    Dedicated logic registers : 38 / 5,136 ( < 1 % )

Info: Fmax Summary
    Info:                Restricted
    Info:         Fmax         Fmax      Clock Note
    Info: ============ ============ ========== =====================
    Info:   225.17 MHz   225.17 MHz        clk

Как видите это самый маленький и самый быстрый код кодера, в моей версии, в пределах альтеровского интерфейса. Его можно еще больше соптималить, если изменить интерфейсы. Также видно что "ядро" кодера для всех модулей одинаковое (одни и те же таблицы и функции) что позволило быстро проверить различные варианты. И этот результат будет одинаковым под любую плис на 3/4/5/6/7 входовом LUTe.

При этом это всё была алгоритмическая оптимизация. А вот если посмотреть на оптимизацию под конкретную ПЛИС , то тут можно еще выжать немного мегагерцелей %)

 

 

Точнее не конкурс, а "обмен опытом". Я думаю, многим новичкам (вроде меня), да и не только новичкам это было бы полезно.

 

Естественно, окончательное решение за гуру, которые могут этим самым опытом поделиться, так как именно они будут тратить

свое время на помощь менее опытным, так как, все-таки, маловероятно, что новички смогут чему-то научить гуру.  :)

Можно я тоже встану в очередь, т.к. не отношу себя к HDL гуру %)

 

 

тут интересно бы действительно дизайн со сложной логикой, чтобы было сравнение, синтеза с высокоуровневого HDL и вставления готовых модулей в схематик/AHDL (я AHDL не знаю, пользовал в те времена схематик/ABEL :), ну а после смысла узнавать не было)

Только вы тоже участвуйте %)

 

целочисленное деление, 64-х битного на 32-х

можно еще посчитать количество 1 в длинном (1024 битном или больше) регистре

еще можно всяческие LRU и прочие алгоритмы поиска (типа найти в массиве 3 максимума - такая тема даже была тут недавно)

более менее оптимальный верилог код есть на форуме

 

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

за меня это делает моделсим, в котором написано утверждение проверки результата моего модуля с результатами эталонной модели, за которую я взял альтеровский кодер %)

[aprox 0]

за меня это делает моделсим, в котором написано утверждение проверки результата моего модуля с результатами эталонной модели, за которую я взял альтеровский кодер %)

Вы столь доверяете Алтере? Я бы поостерегся. Однажды, когда клепал CRC32 я уже имел счастье наблюдать, как три разных источника дают разные CRC: опенкора от Альтера, кора из opencores.org и реальный Ethernet MAC, который принимал пакеты и проверял CRC. У всех трех были разные CRC при одном и том же пакете данных!!! Естественно, я опирался на реально действующее железо, принял его за эталон правильного поведения и стал выяснять, почему альтеровский и опенкоровский варианты дают другие значения. Выяснил, опенкоровский использует Little Endian, а обычные сетевые карты - Big. Альтеровский того крепче- не только Little Endian, но еще и в дополнительном коде. Вывод- доверять модельсимам нельзя. Настоящая проверка - только на железе. Поэтому я настоятельно советую проверить значение RD через симулятор, подав четыре одинаковых символа на вход, у которых симметрия нулей и единиц после кодирования на грани дозволенного.

 

Надеюсь, вы знакомились с моими результатами разводки при разных настройках синтезатора и фиттера? О каких цифрах вашей оптимизации модуля можно говорить, если эти цифры катастрофически зависят от указанных настроек? Кроме того, быстродействие будет зависеть и от окружения вашего модуля, кто источник данных, кто приемник, и каков процент использования ресурсов. Например, при "забитой" на 70% FPGA ваш соптимизированный модуль будет уложен в кристалл так, что пойдут насмарку все усилия по оптимизации. Не зря ли вы тратите время?

[des00 25]

Однажды, когда клепал CRC32 я уже имел счастье наблюдать, как три разных источника дают разные CRC: опенкора от Альтера, кора из opencores.org и реальный Ethernet MAC, который принимал пакеты и проверял CRC.

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

 

Вы столь доверяете Алтере? Я бы поостерегся.

Вы слишком развращены доступностью сорцов разного, часто крайне низкого качества и с разной целевой функцией. Это достаточно простое IP идет в составе официального пакета IP корок и идет очень давно (как минимум начиная с 6.0 квартуса) если бы в этом IP были такие ламерские ошибки, это давным давно было бы устранено.

 

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

Дык настройки качества критерия синтеза для этого и нужны, не всем же нужны пулеметы %)

 

Кроме того, быстродействие будет зависеть и от окружения вашего модуля, кто источник данных, кто приемник, и каков процент использования ресурсов. Например, при "забитой" на 70% FPGA ваш соптимизированный модуль будет уложен в кристалл так, что пойдут насмарку все усилия по оптимизации.

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

 

Не зря ли вы тратите время?

Вместо поиска и расчленения чужих сорцов, на языках которыми не владеете, вывести "дерево" проекта не потеряв прозрачность алгоритма, с подробным обоснованием почему это дает такой результат т.д. и т.п. Не думаю что это напрасно потерянное время. Кроме того, если бы у меня была система ну положим на 50МГц, я бы остановился на первом варианте, написанном левой задней ногой и меня бы это устроило. Ну потерял я 50 плиток, ну и что?

 

Но это всё лирика, давайте конкретику. Описаниями легко настраиваемых одно/много тактных FIRов будем мерится ?

 

UPD Забыл еще одну вещь, не забывайте что при синтезе на современных ПЛИС помимо логической емкости и тактовой частоты, софт как минимум еще решает проблемы SSN и питания. Есть "быстрые" трассы с широким фанаутом, но многожрущие, есть наоборот. Поэтому и смысла собирать все проекты на максимуме тактовой нет никакого. Задайте требуемые констрейны и настройки и пусть квартус делает свое дело. Да у него бывают баги, но для этого и есть база багов и пытливый ум разработчика который видит что собралось что-то не то %)

 

Еще вопрос по теме

опенкора от Альтера, кора из opencores.org и реальный Ethernet MAC, который принимал пакеты и проверял CRC. У всех трех были разные CRC при одном и том же пакете данных!!! Естественно, я опирался на реально действующее железо, принял его за эталон правильного поведения и стал выяснять, почему альтеровский и опенкоровский варианты дают другие значения. Выяснил, опенкоровский использует Little Endian, а обычные сетевые карты - Big. Альтеровский того крепче- не только Little Endian, но еще и в дополнительном коде.

Вы читали документацию на корки от альтеры и от опенкоресов или вы в лоб сорцы пользовали? У последних кстати есть жесткое требование, на наличие описания на корку, в противном случае проект удаляется. У альтеры такие тонкости как форматы представления данных и способ их подачи в доках тоже хорошо описаны. Сильно сомневаюсь что такая фирма как альтера будет выпускать такое IP с такой миной без ее описания.

[aprox 0]

Вы слишком развращены доступностью сорцов разного, часто крайне низкого качества и с разной целевой функцией. Это достаточно простое IP идет в составе официального пакета IP корок и идет очень давно (как минимум начиная с 6.0 квартуса) если бы в этом IP были такие ламерские ошибки, это давным давно было бы устранено.

Сомневаюсь я. Подобные ошибки обычно специально закладывают в shareware, чтобы деньги получить за правильную кору. А то ведь халявщиков нынче море.

Дык настройки качества критерия синтеза для этого и нужны, не всем же нужны пулеметы %)

Не забывайте, с чего начинался тред- с вопроса, хватит ли быстродействия циклона-3 градации C8 для реализации MAC Ethernet 1000Base-T? "Пулеметы", оказывается, очень нужны тем, кто экономит деньги и время.

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

Значит, вы уже поняли, что дело не в верилогах и не в досужих оптимизациях отдельных модулей, а в управлении синтезом?

Но это всё лирика, давайте конкретику. Описаниями легко настраиваемых одно/много тактных FIRов будем мерится ?

Нет, пустое это- меряться пиписьками.

Вы читали документацию на корки от альтеры и от опенкоресов или вы в лоб сорцы пользовали? У последних кстати есть жесткое требование, на наличие описания на корку, в противном случае проект удаляется. У альтеры такие тонкости как форматы представления данных и способ их подачи в доках тоже хорошо описаны. Сильно сомневаюсь что такая фирма как альтера будет выпускать такое IP с такой миной без ее описания.

Как всякий увважающий себя потребитель готового, я не читаю инструкций по эксплуатации. Вполне достаточно предполагать, что на входе, и что на выходе. Если люди сделали вещь для пакетов Ethernet, то разве не разумно предположить, не читая докуметацию, что авторы придерживаются правил Ethernet. Оказывается нет! Лепят все в обратном порядке, и биты, и байты! Что можно сказать?- Уроды! И вот на таких вы ориентируетесь в моделировании алгоритмов.

[Des333 0]

...

Не забывайте, с чего начинался тред- с вопроса, хватит ли быстродействия циклона-3 градации C8 для реализации MAC Ethernet 1000Base-T?

...

 

Так на это ответ с самого начала был дан - хватит ("даже" если писать на Verilog). Только иногда (редко) придется совсем немного подумать.

[des00 25]

Сомневаюсь я. Подобные ошибки обычно специально закладывают в shareware, чтобы деньги получить за правильную кору. А то ведь халявщиков нынче море.

вот это уже паранойя

Не забывайте, с чего начинался тред- с вопроса, хватит ли быстродействия циклона-3 градации C8 для реализации MAC Ethernet 1000Base-T? "Пулеметы", оказывается, очень нужны тем, кто экономит деньги и время.

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

Значит, вы уже поняли, что дело не в верилогах и не в досужих оптимизациях отдельных модулей, а в управлении синтезом?

И это мне говорите вы, человек который владеет только AHDL, а остальные "не читал но осуждаю"? Вы себе опять льстите и пытаетесь сменить тему.

Нет, пустое это- меряться пиписьками.

Без комментариев, думаю что все члены сообщества уже вынесли свое решение

Как всякий увважающий себя потребитель готового, я не читаю инструкций по эксплуатации.

После этой фразы строить с вами конструктивный диалог не вижу никакого разумного смысла, для меня это пустая трата времени. Приношу извинения всем кто надеялся на продолжение батла %)

[aprox 0]

Извините за молчание, был в отпуске.

Что мешает тактировать триггер отрицательным фронтом?

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

 

 

Так на это ответ с самого начала был дан - хватит ("даже" если писать на Verilog). Только иногда (редко) придется совсем немного подумать.

Сомневаюсь, что думать придется "совсем немного". Признания des00 про кучу констрейнов, которыми он добивается эффективной укладки проекта кодера в прошивку сиклона-3, наводит как раз на противоположные мысли. Думать с Verilog придется очень много, в то время как работа в AHDL, а значит автоматически с мегафункциями, дает гарантированно наилучший вариант разводки. Про "констрейны" можно забыть в том проекте, с которого начинался тред про MAC для гигабитного Ethernet на кристалле градации С8. Собственно, я только это и хотел сказать, когда упомянул про лишние трудности с Verilog в сравнении с AHDL.

[dvladim 0]

Сомневаюсь, что думать придется "совсем немного". Признания des00 про кучу констрейнов, которыми он добивается эффективной укладки проекта кодера в прошивку сиклона-3, наводит как раз на противоположные мысли. Думать с Verilog придется очень много, в то время как работа в AHDL, а значит автоматически с мегафункциями, дает гарантированно наилучший вариант разводки. Про "констрейны" можно забыть в том проекте, с которого начинался тред про MAC для гигабитного Ethernet на кристалле градации С8. Собственно, я только это и хотел сказать, когда упомянул про лишние трудности с Verilog в сравнении с AHDL.

Ну какая куча? Вне зависимости от языка, Verilog или AHDL, нужно же указать требования к времянкам (клоки, задержки до выходов и т.д.). И все. Этого достаточно.

[aprox 0]

Ну какая куча? Вне зависимости от языка, Verilog или AHDL, нужно же указать требования к времянкам (клоки, задержки до выходов и т.д.). И все. Этого достаточно.

Работая в AHDL, я этим занимаюсь крайне редко. Потому, что этот язык автоматически распознает в исходниках и использует готовые мегафункции, в которых уже проведена вся оптимизация по-умолчанию. И такой оптимизации по-умолчанию в подавляющем большинстве случаев хватает с избытком. Про Verilog не знаю. Но судя по признаниям des00, повозиться с констрейнами приходиться немало, причем весьма квалифицированно. Правда, и в Verilog наверняка можно использовать готовые мегафункции, но это уже опять констрейнизм.

[des00 25]

Но судя по признаниям des00, повозиться с констрейнами приходиться немало, причем весьма квалифицированно.

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

Работая в AHDL, я этим занимаюсь крайне редко. Потому, что этот язык автоматически распознает в исходниках и использует готовые мегафункции, в которых уже проведена вся оптимизация по-умолчанию. И такой оптимизации по-умолчанию в подавляющем большинстве случаев хватает с избытком. Про Verilog не знаю.

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

 

ЗЫ. И да простит меня модератор за такие слова, готов понести заслуженное наказание в виде бана.

[ViKo 1]

готов понести заслуженное наказание в виде бана.

В качестве "наказания" и просто по щедрости душевной ответьте на вопрос :)

http://electronix.ru/forum/index.php?showt...st&p=760249

И мы все вместе сделаем шаг в нужном направлении.

[Builder 0]

Работая в AHDL, я этим занимаюсь крайне редко. Потому, что этот язык автоматически распознает в исходниках и использует готовые мегафункции, в которых уже проведена вся оптимизация по-умолчанию. И такой оптимизации по-умолчанию в подавляющем большинстве случаев хватает с избытком. Про Verilog не знаю. Но судя по признаниям des00, повозиться с констрейнами приходиться немало, причем весьма квалифицированно. Правда, и в Verilog наверняка можно использовать готовые мегафункции, но это уже опять констрейнизм.

А что, способ ввода проекта и временные требования проекта это уже одно и то-же? Поясните, как ввод проекта на AHDL может избавить от необходимости описать требования к времянке.

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

[aprox 0]

А что, способ ввода проекта и временные требования проекта это уже одно и то-же? Поясните, как ввод проекта на AHDL может избавить от необходимости описать требования к времянке.

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

Обычно поступаю по-ламерски - при создании нового проекта просто полагаюсь на установки в Quartus по-умолчанию. После разводки проверяю Classic Analyzer регистровую скорость для наихудшего path. Если годиться, то никуда больше не лезу. Если максимальной частоты недостаточно, залезаю в раздел Settings и меняю режим оптимизации с Balanced (по-умолчанию) на Speed. Ни разу еще этот прием по увеличению частоты до нужных значений меня не подвел.

 

 

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

Лень шерстить весь тред, но я помню, например, как вы неоднократно упоминали констрейны для увеличения производительности вашего варианта кодера на Verilog. Да и укладку таблицы в ROM также намеревались указать Quartus через констрейны.

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

Квартусом я владею ровно в той степени, которая необходима для практических задач. И мой "бред"- это опыт практической работы над реальными девайсами."К стенке" приставлен не я, а скорей вы сами, поскольку так и не смогли победить по быстродействию вариант кодера на VHDL из опенкоров.

[des00 25]

Лень шерстить весь тред, но я помню, например, как вы неоднократно упоминали констрейны для увеличения производительности вашего варианта кодера на Verilog. Да и укладку таблицы в ROM также намеревались указать Quartus через констрейны.

Понятно, как всегда слили тему.

 

Во первых констрейны и настройки вещи сильно разные, если вы не видите разницы, мне вас жаль.

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

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

 

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

 

"К стенке" приставлен не я, а скорей вы сами, поскольку так и не смогли победить по быстродействию вариант кодера на VHDL из опенкоров.

 

UPD. В четвертых я намерено делал реализацию в лоб, что бы показать развитие проекта и степень понимая квартусом SV/V, тогда как опенкоресоский вариант использует IBM ную статью где все функции уже минимизированы(совсем забыл что доки вы в принципе не читаете и цель авторов с опенкоресов вам неведома). Если вы не видите разницы в целях которые ставили авторы с опенкоресов и я смотрите пункт первый.

 

ЗЫ. Ушел из темы

[ViKo 1]

2 Aprox

Не хочу подливать масла в огонь, но еще со времен "луддитов" (так, кажется?) люди цеплялись за старое и отвергали новое. Вы попробуйте SV, и уверяю Вас, Вам понравится. Примерно так же обстоит вопрос перехода с ассемблера на C для микроконтроллеров. Не всегда же нам нужно предельное быстродействие (кстати, с помощью тех же самых примитивов и мегафункций мы можем сделать в SV всё, что могли сделать в AHDL). А удобство работы - очевидно. Еще никто не соскочил назад на AHDL после SystemVerilog. Также, как никто не возьмется писать на ассемблере то, что умеет написать на C. Мой Вам совет - попробуйте SV!