ViKo

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

Я понимаю так, что SM считает, что при разных порогах срабатывания триггеров можно получить уменьшение времени метастабильного состояния. Я пытаюсь сказать, что это не так. А Вы о чем спорите, Oldring?

Вы нарисовали переход из 1 в 0. Экспоненты должны приближаться к 0 с замедлением, а не с ускорением (e^(-t/tau) - как-то так). И вообще, в реальности там не экспоненты. Но вопрос в другом. Вы забыли про переходы из 0 в 1. Т.е. нарисуйте еще один такой же график, и посчитайте общее количество "экспонент".

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

У второго триггера такая же горка, никак не зависящая от первого. "Шарик" от первого триггера может попасть в любое место горки второго триггера, это определяется временем. Тактовой частотой, и моментом выхода первого триггера из метастабильного состояния. Когда я говорил "пологая" горка, имел в виду, насколько она "плоская". Согласен с вашим термином.

Позвольте высказать свои соображения по поводу метастабильности. Приводились картинки, где изображалась горка - порог срабатывания триггера, и шарик - входной сигнал в момент синхроимпульса. Если входной сигнал изменяется между нулем и единицей в момент синхроимпульса - шарик может оказаться на вершине горки, и триггер "не знает", в какую сторону ему кинуться - в ноль или в единицу. Если шарик ближе к какому-то краю, решение принимается достаточно быстро, если же точно на вершине, может пройти мно-о-о-го времени, пока триггер куда-то перекинется. Именно это время и есть метастабильное состояние. В каком состоянии находится выход первого триггера - неизвестно, может быть в одном из логических, может быть, в каком-то среднем. Насколько пологая эта горка, настолько и велико время метастабильного состояния. Определяется технологией производства. И скорость переключения триггера тоже зависит от крутизны горки. А вот от этой скорости уже зависит, словит ли второй триггер состояние, когда сигнал изменяется, или защелкнет стабильное состояние. Чем дальше по времени срабатывает второй триггер - тем меньше вероятность словить нелогический уровень и войти в метастабильное состояние. Чем резче изменяется выход первого триггера - аналогично, тем меньше вероятность для второго войти в метастабильное состояние. Теоретически можно предположить что для получения вероятности метастабильного состояния устройства нужно перемножить вероятности метастабильного состояния для каждой ступени (а они, естественно, намного меньше 1, поэтому произведение будет совсем уж ничтожным). И чем больше триггеров в цепочке, тем меньше эта вероятность. А технологический разброс, фронты и срезы здесь не при чем. Время, и технология.

Наверное, ответ на такой вопрос - очевиден. Конкретизируйте. Если сигнал на входе, предназначенном для тактов ПЛИС будет соответствовать требуемым характеристикам (размах, частота), то такты внутри ПЛИС будут работать. Требуемые характеристики описаны в даташите. Как эти такты будут использованы внутри, зависит от разработчика. P.S. Если ногу какую-нибудь нужную не припаять к питанию или земле - тоже работать не будет.

Если сигнал доберется, то будет. Было бы там чему работать внутри.

В-общем, выводы такие. Verilog-mодули в файлах с несколькими модулями (т.е. именно в таких файлах, которые можно было бы назвать библиотечными) Quartus напрямую через указание каталогов Libraries не обнаруживает. В этих файлах обнаруживается только модуль верхнего уровня. Можно подключить в проект сам такой файл, с помощью `include, или в установке Settings / Files (что по большому счету, одно и то же). Благодаря тому, что в проекте задается модуль верхнего уровня (Settings / General), конфликта между файлами не будет. Все остальные модули в файлах (более низкой иерархии) найдутся, так как они уже будут входить в проект. Ничего лишнего компилироваться не будет. Лучше каждый модуль хранить в отдельном файле. И отлаживать, редактировать проще, и как библиотечный модуль найдется. Но каталог будет забит всякими рабочими-служебными файлами. В таком случае, наверное, лучше отлаживаться в отдельном каталоге (Temporal), а готовые модули хранить в каталоге библиотеки (Library).

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

Я бы не стал так "бесстрашно" вводить конвейер в схему с обратными связями. Автор темы желает в каждом такте 200 MHz сложить входной сигнал с уже накопленным. Если разбить это на несколько тактов, на выходе будет нечто совсем другое. Еще вопросик - как насчет переполнения счетчика - игнорируем (отбрасываем)? И кому нужен такой результат? Скорее всего, нужно пересмотреть само задание - уменьшить частоту, обнулять периодически, и т.д. И еще - я не нашел в Quartus 9.0 установок register retiming и pipelinig вообще. Подскажите конкретно.

Создал экспериментальный проект из двух файлов Test.v и Library.v в одном каталоге D:\Test. Все пути задал. Из Test.v вызывается модуль CountReload, расположенный в Library.v Когда раскомментирую строку `include Library.v, проект компилируется. Если закомментировать - нет! Quartus 9.0, SystemVerilog-2005. Проект прилагаю. Кто-то из нас неправ? Test.zip

А в этих файлах "куча" модулей, или в каждом по одному?

Вопрос к des00, Sefo и др.: Так как все-таки в Quartus запихать в один библиотечный файл кучу модулей? У меня что-то не находятся они. Похоже, видны только модули верхнего уровня (совпадающие с именем файла). Можно подключить файл с библиотечными модулями в файл проекта, например, так: `include "QuartusLibrary.v" Есть ли более приличное решение?

Подскажите такой упаковщик-распаковщик. Я заменял последовательности нулевых байтов на один байт 00 и следующий байт - количество нулевых байтов. Сжималось примерно раза в 2. Зависит от заполнения ПЛИС. Понимаю, алгоритм не оптимальный, зато простой. Архиватор тот же файл сжимал раза в 4.

С CARRY я проморгал - черная полоса посередине элементов и есть переносы. А по поводу "цифр" выдам еще одну картинку. Похоже, изображают, что сигналы используются только внутри LAB. Но в других похожих случаях, однако, не рисуются.

Что за цифры (или не цифры) внутри логических элементов? И где изображение CARRY? (они используются) См. картинку.

"Были демоны, этого мы не отрицаем! Но они... самоликвидировались!" :-) (а проект, однако, запускался, помнил, собака, прежние установки) Спасибо!

Всё, получилось! Дело было в "кривом" проекте. Фиттер помнил прежние установки, поэтому выводил наружу все выходы счетчика. Следующий код работает, как надо: module QuartusLibrary(input CLKIN, input ENABLE, output CLKOUT); wire [7:0] CntTmp; counter Divider(.clk(CLKIN), .ena(ENABLE), .reset(0), .result(CntTmp)); assign CLKOUT = CntTmp[7]; endmodule module counter (clk, reset, result, ena); input clk; input reset; input ena; output [7:0] result; reg [7:0] result; always @(posedge clk or posedge reset) begin if (reset) result = 0; else if (ena) result = result + 1; end endmodule

1. Я обозначаю прописными буквами имена цепей, выходящих наружу ПЛИС, остальные имена начинаю с прописной, дальше строчные. Логичный выбор. То, что написано внутри модуля counter, я оставил, как было у Altera. 2. Что я нарушаю, поясните. Использую экземпляр модуля. Вроде, сигналы названы правильно, поставлены в соответствии. 3. Как "выкрутиться" с подобным желанием - вывести на улицу, например, только старший разряд счетчика (вполне реальная задача - поделить входную частоту...)?

Нет, так не выходит. Один бит вывести хочу. Пробовал "приведение типов" попытаться использовать, как-то так: module Library(input CLKIN, input ENABLE, output CLKOUT); Counter (.clk(CLKIN), .reset(0), .ena(ENABLE), .(bit') result(CLKOUT)); Ни хрена не выходит.

Если позволите, вопрос по теме: В Quartus 9.0 пытаюсь использовать counter.v, скачанный с сайта Altera. Сам по себе работает, естественно. Но когда хочу завернуть в свой модуль, и вывести, например, только несколько выходов счетчика наружу, то или ошибки лезут, или выводятся все выходы. Наверное, я какой-то мелочи не знаю. module Library(input CLKIN, input ENABLE, output[3:0] CLKOUT); wire [7:4] ClkTmp; Counter (.clk(CLKIN), .reset(0), .ena(ENABLE), .result(ClkTmp)); assign CLKOUT = ClkTmp[7:4]; endmodule module counter ( clk, reset, result, ena ); input clk; input reset; input ena; output [7:0] result; reg [7:0] result; always @(posedge clk or posedge reset) begin if (reset) result = 0; else if (ena) result = result + 1; end endmodule

Мое мнение - семейства PIC10/12/16 не блещут производительностью по сравнению с AVR, например. Выбирая сейчас, может быть я выбрал бы микроконтроллеры Atmel. Но, во-первых - привык к PIC, знаю их в совершенстве (и команд мало, легко запомнить, и средства программирования мне кажутся удобными и доступными). Во-вторых, не доверяю фирме Atmel с их глюками в железе и документации (личное субъективное мнение, отстаивать не буду). В мире есть много интересных микроконтроллеров, но там, где можно, я буду применять PIC10/12/16, возможно PIC18. А там где нельзя - STM32, например (опять же, субъективный выбор, не настаиваю на правильности). В-общем, что любить или не любить - личное дело каждого.

Запускаете отладку, внизу, в статусе, ближе к правому краю t1: ... Жмете правой кнопкой мыши... наводите мышь... А время в такты перевести сможете, вы же частоту генератора знаете. Правда, у меня Keil 4.0

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