Comments 28
Я его ещё не описывал на языке программирования, поэтому не знаю во что он компилируется, тем более он мной описываться будет по готовой схеме и в структурном виде, поэтому скомпилируется в то, что вы видите на схеме в анимированной симуляции. Да , модуль выполняющий функцию сумматора есть, но он не такой как этот. Сумматор протестирован на работоспособность в симуляторе. По части размытого определения , одинакового быстродействия и всего остального скажу, что тест бенчи выложу на выходных и многословным не буду. Скажу только что знаю наверняка - я делаю схемы в структурном виде описания. Преимущественно это так.
Маленькая победа над багом Gowin EDA...
А в чём состоит баг? Вы подключили отладчик (analyzer oscilloscope), из-за которого вашу схему не сносит синтезатор. К нему же подключен и ваш осциллятор, поэтому его тоже не сносит и он там отдельным квадратиком стоит, тактируя отладчик. А analyzer oscilloscope на схематике не отображается. Схема верна.
А скорости различаются, потому что как и написано в цитате с вики:
строго-самосинхронные схемы предъявляют очень жесткие требования к внутренней структуре ПЛИС
физически на плисине ваши два эксперимента раскладываются на разные LUT-ы, длины путей между которыми отличаются и вносят существенную разницу в скорость осцилляции вашей штуки.
Чтобы немножко контролировать процесс, прибейте констрейнтами ваши триггеры к конкретным LUT-ам внутри ПЛИС.
Выход LUT, конечно, можно подключить к триггеру в другом CLB, но зачем тянуть провод, если есть "местный" триггер? Может быть оптимизатор иногда так делает. Если цель - поизучать что вытворяет оптимизатор - это одно, а если цель - настроить всё вручную, то для этого служит instantiation.
Да, действительно, пардон, не посмотрел, что там у человека Latch, а не LUTы используются. Но сути замечания сильно не меняет: для хоть сколько-нибудь контролируемого тайминга в подобных экспериментах ресурсы лучше прибить констрейнтами, иначе результаты будут очень существенно отличаться в зависимости от того, как P&R всё разложило в этот конкретный раз на кристалле.
Кстати, про P&R, может быть Вы знаете, кто-то сравнивал open-source разводчики? В частности тот, который внутри Verilog to Routing с тем, который внутри Yosys?
Посчитаем - тактовая частота платы 27 МГц, она увеличивается осцилятором в 100 раз, получается 2700 МГц или 2.7ГГц
Откуда вы такое взяли?
Вы используете компонент Gowin_osc? Так это встроенный в FPGA генератор. Во-первых, он никак не связан с тактовой частотой платы. У него фиксированная частота (около 210 или 250МГц зависит от типа микросхемы) и умножать он не может. Может только делить. Например, на 100.
Это написано в документации на микросхемы Gowin https://cdn.gowinsemi.com.cn/UG286E.pdf
На странице 104.
хотя согласно визуализации вообще работать не должно как асинхронный счётчик, так как все провода замкнуты
Они не замкнуты, а объединены в шину. Рассматривайте их как пучок проводов.
По части отладки, или я пропустил или это как то было отмечено? На сколько мне известно, не настаиваю, это лишь личные наблюдения, стандартные инструменты FPGA больше ориентированы на синхронные системы. Отладка асинхронных схем это непредсказуемые грабли из-за отсутствия центрального тактового сигнала, нужно детализировать тайминги, когда сигналы достигают различных элементов схемы в непредсказуемое время, что влечет полный рассинхрон.
Счётчик - это, конечно, хорошо, но что говорит Gowin о режимах работы триггера? Почему это важно? Потому что вход сброса у этого триггера есть, а входа установки, наверняка, нет. А жаль, на двух RS-триггерах можно было бы собрать С-элемент (схема Murphy)
У триггеров есть вход и есть сброс, иначе никаких полных циклов-бы не было. Меня больше интересует теперь тайминг сброса. Что касается мнений про баг - я всё сказал, строка номер 19 всё меняет, компилятору не хватает абстрактного "взгляда" на синтезируемую схему, привязка массива проводов к выходу (даже если он не нужен )позволяет исправить проблему. Если кто-то знает причину более точно - попробуйте, я сделал как считал нужным согласно своей логике и это решило проблему. На эксперименты и проверки рекомендуемые со стороны - у меня к сожалению нет времени. Но тем не менее - всем спасибо.
Могу сказать только, что с АЛУ я выложу тестбенчи сброса цепи таких триггеров, только это не простая задача, так как в отличии от установки значения единицы - прийдётся задействовать цепи логических элементов, высчитывать их скорость, и только потом вычислять скорость сброса триггера. Проблема в том, что прийдётся лепить пары элементов NOT , или одиночными XOR (в общем тут подумать надо, скорее вообще эхлемент AND или жлектпонный ключ bufif), между триггерами, высчитать их скорость (наверное всё-же отдельной цепью), и потом сделать новую цепь для вычисления скорости сброса, или попробовать одной новой цепью всё.
Ну, хоть на instantiation найдите время. Можно начать с кольцевого осциллятора, а можно с того, что (с точностью до константы) приведено ниже. Потом уже можно координаты зафиксировать, чтобы расставлятель не договорился с разводчиком :)
module cross_C_element (y, x1, x2, x3);
input x1, x2, x3; output y; wire w0; wire w1; wire w2;
LUT4 #(.INIT(16'h1FFF)) set_chain (.I0(w2), .I1(x1), .I2(x2), .I3(x3), .F(w0));
LUT4 #(.INIT(16'h1FFF)) rst_chain (.I0(w2), .I1(x1), .I2(x2), .I3(x3), .F(w1));
MUX2 mux_out (.I0(w0), .I1(w1), .S0(w2), .O(y));
endmodule
Ещё вчера дполнил публикацию. Всё будет сделано точно так-же как и до этого, потому что это проверано было и ранее, пол-года назад, на совсем другом коде и без осцилятора - баг был, просто как его обойти придумал только недавно, так как и времени-то особо не было тоже. Ничего сложного, спасибо за рекомндации, может кому-то помогут. Ваша помощь наверняка кому-то нужна.
Доделал сегодня сумматор https://www.cyberforum.ru/blogs/223907/blog8715.html .
На следующей неделе будет готова публикация по тестбенчам всех логических элементов и асинхронных триггеров на сброс.
И собственно, сумматора.
Во что компилируются условные обозначения элементов этой схемы, в LUT или в элемент XOR с мультиплексором 2:1? Это готовый сумматор, который есть в составе каждого логического блока. Что же касается триггеров (памяти), а также довольно размытого определения "асинхронная схема", то триггеры нужны для carry-save adder (von Neuman circuit). По быстродействию он не отличается от последовательного соединения одноразрядных сумматоров. А схемы, которые Вы делаете, - это части bounded data.
Я его ещё не описывал на языке программирования, поэтому не знаю во что он компилируется, тем более он мной описываться будет по готовой схеме и в структурном виде, поэтому скомпилируется в то, что вы видите на схеме в анимированной симуляции. Да , модуль выполняющий функцию сумматора есть, но он не такой как этот. Сумматор протестирован на работоспособность в симуляторе. По части размытого определения , одинакового быстродействия и всего остального скажу, что тест бенчи выложу на выходных и многословным не буду. Скажу только что знаю наверняка - я делаю схемы в структурном виде описания. Преимущественно это так.
У Вас есть способ проверить, что нарисованные логические элементы соответствуют таким же внутри FPGA? Наверное нет. По двум причинам. 1) Gowin EDA показывает только границы логического блока, но не показывает его внутреннюю схему. Возможно, он пишет названия использованных ресурсов. 2) Логические элементы с числом входов больше двух (например 3И-НЕ) всегда реализуются на LUT. Другой возможности нет. Асинхронные схемы исторически начинались с многоразрядного сумматора. Почему? Потому что в нём есть переносы и можно определить возникнет следующий перенос или нет. Если нет - результат готов и можно присылать следующие данные.
Уточнение. Асинхронные сумматоры "по готовности переноса" называются carry completion и carry storage. По быстродействию они одинаковые. По сложности на FPGA - судить Вам. Я как-то моделировал carry storage adder с равномерным распределением слагаемых в Mathematica. Принцип работы этого сумматора хорошо описан в двух источниках:
K. Hwang, Computer Arithmetic: Principles, Architecture, and Design, Wiley, 1979.
G. Schay, "How to Add Fast - on Average," The American Mathematical Monthly, vol. 102, no. 8, pp. 725-730, 1995.
Ещё раз по поводу вашего "бага", так изображаются шины. Щёлкните уже правой кнопкой по шине и выберите пункт dissolve, тогда среда нарисует вам отдельные провода, щёлкните combine и получите обратно шину. В мануале по Schematic Viewer SUG755E это есть.
Мнимые провода в шине - это баг. Ну, или китайцы решили запутать врага :) А обратная подстановка у них есть? Это когда после трассировки показывается через сколько коммутаторов проходит сигнал. Пишут эквивалентную задержку провода? Нет? Правильно делают, что не пишут, для синхронных схем - это лишняя информация. Длина такта выбирается так, чтобы все переходные процессы завершились. Среди этих процессов могут быть и те, которые приводят к ошибкам. Виновниками ошибок очень даже могут быть задержки. Именно поэтому я уже n (n>1) раз спросил про то, как Verilog ложится в логический блок. Рифма. Что доминирует, задержка проводов или задержка гейтов? Вторая рифма. Можно ли сделать задержку одинаковой по каждому входу LUT с помощью проводов, которые туда идут? Третья рифма.
Автор проявляет нордическую стойкость на безрыбъе традиционных инструментов проектирования FPGA, которые заточены на синхронные проекты. Разработка асинхронной логики требует ручного создания специфических компонентов и схем с учетом таймингов и задержек между элементами, причем в ситуации отсутствия глобального тактового сигнала, а понимание того что нужно, после его построения упирается в проблемы с верификацией и отладкой, дефакто отсутствие отладочных симуляторов, которые надо так же строить.
Спасибо за подсказку, но поблема в том, что баг есть, и представлений схемы при его возникновении не два, а три (с уточнением того, что нормальное представление возникает только если создать ненужный выход с модуля и кинуть на него провод, который всё портит), и если сделать тестбенч баганутого компиляцией кода, то он работает, но со скоростью в два раза меньшей чем при нормальной компиляции. Я это всегда упоминал. Сделал как вы советуете - да, это работает, но баг - остаётся, если не поступить как я описывал. Прошу прощения, но могу отвечать только раз в сутки, и к тому-же сильно занят.
Причём баг этот наблюдается что в Windows, что в Linux, и побеждается одним и тем‑же способом, надеемся, что разработчики победят его тоже.
Обычно, когда думаешь, что где-то в компиляторе баг, то скорее всего это не баг, а собственное непонимание происходящего.
У Вас в проекте какой модуль является модулем самого верхнего уровня?
Например, это pprobe1
Если вы к выходу этого модуля из модуля подключаете какой-то сигнал, то какой-то конкретный вывод микросхемы FPGA станет выходом этого сигнала. Вы можете либо сами назначить номер вывода микросхемы, либо компилятор выберет вывод произвольным образом (посмотрите отчет фиттера, какие выводы используются). А если вы не делаете присвоения выходу модуля, то вообще-то компилятор вправе вообще выбросить всю эту логику. У вас от выбрасывания этой логики спасает только GAO - внутрисхемный отладчик (который вы почему-то называете тестбенчем). Отключите отладчик и ваш проект станет занимать ноль ресурсов, абсолютно всё будет выброшено компилятором.
И еще замечание по поводу GAO. Вы захватываете сигналы на частоте oscout, правильно? Вы понимаете, что таким способом можно увидеть только процессы, которые как минимум в 2 раза ниже по частоте, чем oscout?
Прошу прощения, мой сумматор тут https://www.cyberforum.ru/blogs/223907/blog8718.html
. В воскресенье выложу тестбенчи базовых логических элементов и сумматоров.
Названия "summator" и "transfer" вместо "adder" и "carry" говорят о том, Вы либо не спрашивали Google про стандартные реализации "full adder", либо не доверяете Google. И то и другое - зря. Это простой вопрос и реализаций на логических элементах не так много. Более того, можно найти их сравнение по быстродействию, площади и энергопотреблению. А если постараться, то можно найти и какую-то оптимизацию для FPGA. Не думаю, что у кого-то получилось намного лучше, чем сумматор, имеющийся в логическом блоке. У Вас тоже не получилось. Уже только потому, что для инвертора нужно использовать LUT целиком. Не слишком ли расточительно?
Например, в свободном доступе есть вот эти полезные статьи
Accelerating computations on FPGA carry chains by operand compaction
Mapping Arbitrary Logic Functions onto Carry Chains in FPGAs
С стандартными реализациями я знаком, и если вы переходили по ссылке что давал я, и даже по той, что дали мне вы - вы должны были увидеть схему (она есть тут - выглядит как паравоз), которую я тоже сравнивал на быстродействие с своей (вообще я две версии с своей сравнивал), и там где нет инвертора тоже, и это в семь раз медленнее моего (как минимум схема без инвертора, с инвертором схема ещё медленнее, а у меня задача разбита на две параллельных). А знаете почему? Потому что схема не последовательная. Вы сами пишите комментарии не читая чужих материалов. Что касается меня, то с гуглом я дружу вполне, схему по вашей же ссылке не читали только вы сами, я читал. О расточительности я сужу по быстродействию. К тому-же у меня всего два логических элемента кроме двух инверторов, и они - параллельно подключены, образуя две линии.
И у меня - всё получилось. Мнения вашего круга мне зорошо известны, его члены сами в сети и в радиожурналах часто отмечались, высказывая их. То что я не дулаю публикации - не значит что у меня ничего не получилось, просто на базе части своего сумматора я пытаюсь создать RS триггер асинхронный. Если создание триггера окажется слишком тяжёлым - то вероятно я выложу сумматор отдельной публикацией, если не завтра, то послезавтра, с тестбенчами (без инвертора в семь раз медленнее, а стнадартный - он же по вашей ссылке, но с инверторами - и того больше). Так что вы можете сильно не стараться с уничижениями, я просто пытаюсь потратить свои вечера на новый триггер, который будет ещё быстрее, ну или должен быть, так как не факт что он у меня получится.
То что у меня не получилось - я слушу со времени создания своего генератора карт, который почти в квадрат числа (где числом описывается объём работы при расчётоах карты) превосходит по быстродействию традиционный алгоритм, который мне предлагали, заявляя что мой никогда не заработает. Но увы - он заработал, и тогда заявлявшие заявили следующее - "это ТЗ тупое - карты не эффективны", ну разумеется, для котого-то и книги - ерунда, и учебники, тут убеждать бесполезно в обратном ваш круг. Так что я знаком не только с мнениями вашего круга, но и с его деятельностью в обществе. Очень хорошо знаком.
Сколько слов и всё мимо. Одноразрядный полный сумматор - это две булевы функции, сумма=XOR3 и перенос=MAJ3. Вы это понимаете? Я не уверен. А то, что LUT4 может реализовать любую функцию четырёх и менее переменых Вы понимаете? Я совсем не уверен. Сумматор с минимальной задержкой получится, если реализовать сумму и перенос на двух отдельных LUT4. Зачем Вы используете двухвходовые элементы? Я даже не буду произносить слово декомпозиция. У Вас (среди элементов физически присутствующих в FPGA) есть двухвходовые элементы? Поищите. В лучшем случае найдёте один XOR2 и несколько MUX 2:1. Вы можете подключиться к любому выводу любого элемента? Нет. Всё это делает Вашу схему избыточной, а правильнее сказать, бессмысленной.
Всё это делает Вашу схему избыточной, а правильнее сказать, бессмысленной.
я сделал рабочую схему.
Сумматор с минимальной задержкой получится, если ...
Я нисколько не мешаю сделать это другим. Извините, у меня не так много времени, чтобы проверять чужие работы, которыми, к тому же, я даже не планирую воспользоваться.
Асинхронная логика — насколько же это может быть быстро… (+ небольшая победа над багом в Gowin EDA)