1.Прекрасно можно тактировать события в синхронных системах по фронту и по спаду тактового импульса, если нужно. Я это делал, почему Атмел не может?
2.В даташите на АТмега8 нет слова PLL. Может не стоит придумывать то, чего нет? Рисунок с тактами слишком схематический, по нему нельзя делать категоричных выводов.
3.В тех АТтини, где есть PLL, и это отражено в даташите (АТтини 25, 45, 85), PLL поставлен из-за необходимости тактирования скоростной периферии (раздел 6 даташита).
че за *уйню вы тут городите??? вы вообще знаете, что такое конвейер?
операция сложения двух регистров и помещение результата в первый происходит в несколько этапов и длится столько же периодов тактового генератора!!!! НО она начинает выполняться раньше, поскольку входит в конвейер! в результате - один такт. Блин, ну вы даете!
А на графике приведено время, как бы затрачиваемое на выполнение кода, с учетом конвеера. А не промежуток времени в котором выполняется соответствующий этап.
Engineer_Keen писал(а):было видно характерное изменение по обоим фронтам такта.
SmarTrunk писал(а):1.Прекрасно можно тактировать события в синхронных системах по фронту и по спаду тактового импульса, если нужно. Я это делал, почему Атмел не может?
IMHO вполне разумный и естественный подход, сплошь и рядом применяющийся на практике. Достаточно лишь инвертировать тактовый сигнал - и получаем внутри МК две фазы для синхронизации. (Правда, для этого нужно понимать, как работает инвертор, ну и вообще быть в курсе азов электроники).
SmarTrunk писал(а):2.В даташите на АТмега8 нет слова PLL. Может не стоит придумывать то, чего нет?
Там, где нет реальных знаний или хотя бы элементарного понимания, буйно расцветают фантазии. Как там у классика? Советы космического масштаба... Лепет про грамотность... Вот кабы еще при этом еще и не закусывать зубным порошком, совсем бы хорошо.
В общем, все как обычно: имеющие мозг пришли к единому мнению (что вполне естественно), обделенный таковым по привычке развлекся, кидаясь какашками со своей пальмы и источая смайлики со чмоками, что тоже не противоречит природе. "Никто не ушел обиженным" (С).
Любой дурак может писать код. Настоящий профессионал - это тот, кто способен постоянно создавать продукт высокого качества, укладываясь при этом в бюджет.
J. Ganssle
HHIMERA. Опять никакого конструктива. Значит, всё-таки, "лапки к верху".
Engineer_Keen, вот и я про то же, что тактирование идёт одним сигналом, без умножения частоты (т.е. без PLL).
SmarTrunk, про PLL - согласен. Вариант с тактированием по двум фронтам возможен. Но касательно ядра AVR это доподлинно неизвестно.
ibiza11, ядро AVR это RISC процессор, это во-первых. Во-вторых, в спецификации написано (и нарисовано), что исполнение последовательно идущих команд состоит из выборки команды из памяти (FLASH) и собственно исполнения команды. Выборка команды из памяти как отдельный этап нужна потому что память требует время на доступ к конкретной ячейке. В отличии от памяти, РОНы связаны с АЛУ напрямую и тут не требуется дополнительного времени на выборку. Выполнение простой команды, IMHO, сводится к коммутации нужных регистров/операндов на блок выполнения операции (сложение, and, or ,xor, ...) и коммутации результата на регистр приёмник. Т.к. операция выполняется сразу (не требует тактирования, реализована без триггеров, регистров и т.п.), то достаточно тактирования по одному из фронтов. И то, это тактирование регистров РОНов и регистров содержащих машинную инструкцию. Вполне возможна фиксация/синхронизация промежуточных стадий по спадающему фронту. Мне видится как-то так.
Когда уже ничего не помогает - прочтите, наконец, инструкцию.
Лучший оптимизатор находится у вас между ушей. (Майкл Абраш, программист Quake и QuakeII)
Избыток информации ведёт к оскудению души - Леонтьев А. (сказано в 1965 г.)
Goldsmith писал(а):Там, где нет реальных знаний или хотя бы элементарного понимания, буйно расцветают фантазии.
Да-да... твои бред фантазии просто шедевр!!!
С каждым твоим постом уровень истерики всё больше, а "показной" уровень знаний всё меньше и меньше...
Одна операция по фронту, другая по спаду... а третья по чём???
"Я не даю готовых решений, я заставляю думать!"(С)
Kavka писал(а):HHIMERA. Опять никакого конструктива. Значит, всё-таки, "лапки к верху".
Щаззз... как же...
Ответ, в общем, давно известен... и уже прозвучал здесь... как не странно...
Тема то... уже неоднократно поднималась на разных ресурсах...
Просто интересно посмотреть, как некоторые "типа крутые..." пальцы гнут до самых колен... и зеленеют от желчи и собственных незнаний...
"Я не даю готовых решений, я заставляю думать!"(С)
HHIMERA писал(а):Ответ, в общем, давно известен... и уже прозвучал здесь... как не странно...
Ну так повтори, сформулируй полностью, напиши подробно. Не флуди хоть одно сообщение. Иначе подтвердишь последний абзац из предыдущего сообщения Goldsmith.
HHIMERA писал(а):Одна операция по фронту, другая по спаду... а третья по чём???
Если ты не знаешь другого способа - это не значит, что его нет. И один из таких способов я описал выше, так как я это вижу.
Когда уже ничего не помогает - прочтите, наконец, инструкцию.
Лучший оптимизатор находится у вас между ушей. (Майкл Абраш, программист Quake и QuakeII)
Избыток информации ведёт к оскудению души - Леонтьев А. (сказано в 1965 г.)
За современные решения не скажу, но когда-то пришлось участвовать в разработке процессора. Там машинный цикл состоял из трёх тактов, которые формировались параллельной записью в регистр (т.е. синхронно), использовались ТОЛЬКО и исключительно положительные фронты этих тактов, никаких инверсий тактовых импульсов не допускалось, потому как был задан цикл работы АЛУ во сколько-то десятков нсек, а инверсия уже укорачивала время следующего рабочего такта. Если запас по времени есть в самодельных системах, то, видимо, это позволяет вольно обращаться с фронтами и называть инверсию заднего фронта 1го такта передним фронтом 2го такта.
Таки да, никакой ФАПЧи не надо, достаточно просто понаставить подряд инверторов, и получим задержанный на разное (в пределах одного такта) время тактовый сигнал, который будет тактировать соответствующие этапы одной операции (области АЛУ).
[ Всё дело не столько в вашей глупости, сколько в моей гениальности ] [ Правильно заданный вопрос содержит в себе половину ответа ]
Kavka писал(а):ibiza11, ядро AVR это RISC процессор, это во-первых.
Да. Я разве утверждаю обратное? Это лишь означает, что команды контроллера разделены на минимально возможные операции по времени исполнения.
Kavka писал(а):Во-вторых, в спецификации написано (и нарисовано), что исполнение последовательно идущих команд состоит из выборки команды из памяти (FLASH) и собственно исполнения команды.
И что же тут расходится с моим сообщением? Заладили "во-первых" да "во-вторых" ахахаха))))
В остальном тоже согласен кроме
Kavka писал(а):Вполне возможна фиксация/синхронизация промежуточных стадий по спадающему фронту.
Все же уже прозвучало. Почитайте про конвейер сначала, прежде чем здесь отвечать.
В самом начале старта контроллера такты идут, а конвейер наполняется, в программе ничего не выполняется несколько тактов, пока первая инструкция не дойдет до конца конвейера. Это время зависит от кол-ва ступеней конвейера, чем больше - тем дольше будет простаивать в начале программа. Но как только конвейер заполнился - операции начинают выполняться подряд, каждая через такт, поскольку они входили в конвейер также - через каждый такт (исключения составляют команды, которые сбрасывают конвейер, поскольку результат выполнения такой команды еще не известен - соответственно неизвестна команда, которая должна попасть в конвейер следующей). Что тут может быть непонятным?
В AVR, как уже выяснили, 2-х ступенчатый конвейер. Это значит, что программа "стоит" в момент старта сами догадайтесь сколько тактов....
Распинался-распинался, а оказалось не на тот вопрос отвечаю))) Прошу прощения за излишний сарказм)
В общем если весь вопрос стоит в устройстве АЛУ, (как именно оно, а не AVR в целом, выполняет команду за один цикл) Соглашусь, что у меня самого не было полного понимания процесса, что я признаю. Был не прав.
Конвейер двухступенчатый, как уже выяснили.
1) выборка кода команды
2) выполнение за один такт операции с РОН.
Тут весь секрет в особом построении AЛУ совместно с файлом РОН. АЛУ имеет прямой доступ (без защелкивания по такту) к требуемым регистрам сразу после того как код команды подали на вход АЛУ. Я подозреваю это сделано с помощью системы мультиплексоров и логических элементов, управляемых кодом команды. Результат АЛУ аналогичным образом получается исходя из кода команды и уже смультиплексированных данных двух регистров из файла РОН. По такту - происходит защелкивание в регистр РОН уже результата операции.
Учитывая мои предыдущие заблуждения - прошу меня поправить, если есть что именно поправить. Просьба по существу, не цепляясь к словам.
Gudd-Head писал(а):Таки да, никакой ФАПЧи не надо, достаточно просто понаставить подряд инверторов, и получим задержанный на разное (в пределах одного такта) время тактовый сигнал, который будет тактировать соответствующие этапы одной операции (области АЛУ).
Так не пойдет. Чуть чуть частоту увеличил и заткнется процессор. Неверный подход.
ibiza11 писал(а):Тут весь секрет в особом построении AЛУ совместно с файлом РОН. АЛУ имеет прямой доступ (без защелкивания по такту) к требуемым регистрам сразу после того как код команды подали на вход АЛУ. Я подозреваю это сделано с помощью системы мультиплексоров и логических элементов, управляемых кодом команды.
Или в регистр запись ведется не по фронту а по уровню и регистр получается прозрачный, что на входе, то и на выходе.
Купи два беляша и собери из них кошку
Labor est etiam ipse voluptas Труд уже сам по себе есть наслаждение (*Формула любви)
Ave novie-nostra ales Если один человек построил - другой завсегда разобрать может....(*Формула Любви).
Gudd-Head писал(а):Таки да, никакой ФАПЧи не надо, достаточно просто понаставить подряд инверторов, и получим задержанный на разное (в пределах одного такта) время тактовый сигнал, который будет тактировать соответствующие этапы одной операции (области АЛУ).
Так не пойдет. Чуть чуть частоту увеличил и заткнется процессор. Неверный подход.
Вполне верный подход. Производитель процессора гарантирует его работоспособность только в определённом диапазоне частот -- и не больше. Если процессор перестаёт работать при разгоне выше разрешённой частоты -- это уже проблемы разгоняющего, а не производителя.
SII, Вы не поняли. При таком подходе можно добиться только меньшей частоты, чем можно при синхронном подходе. Т.е. при том же техпроцессе, использование обоих фронтов сигналов только занижает максимальную частоту, чем при использовании одного фронта. Сразу видно, для ПЛИС Вы не писали проекты.
ibiza11, возможно, что я что-то и не до конца понял, но...
Во-первых, не следует путать производительность системы с тактовой частотой. Вот гипотетический пример. Предположим, что при использовании одного фронта можно разогнать нашу схему до 100 МГц, однако выполнение типичной операции будет требовать двух тактов. В то же время, используя оба фронта, можно получить лишь 80 МГц -- но зато типичная операция будет выполняться за один такт. Легко заметить, что производительность "двухфронтовой" схемы будет существенно выше, чем "однофронтовой", несмотря на меньшую частоту. Так что сама по себе частота не может служить мерилом производительности -- она таковым является лишь при полностью идентичных остальных вещах.
Во-вторых, в реальных процессорах на микросхемах малой и средней степени интеграции, особенно высокопроизводительных (по тогдашним меркам, конечно), нередко использовался не один тактовый сигнал, а несколько, причём они были между собой взаимосвязаны. Скажем, период синхронизации 100 нс, фронт сигнала С1 приходится на момент 0 нс, фронты сигналов С2-С5 -- на 20, 40, 60 и 80 нс. Разные действия в итоге могут выполняться по фронтам разных сигналов. Например, адреса регистров, участвующих в операции, могли фиксироваться по С1; данные, выбранные по этим адресам из блока регистров для выполнения операции в АЛУ, могли приниматься в рабочие регистры по С2, результат АЛУ мог приниматься в выходной регистр по С5. Использование промежуточных регистров для входных и выходных данных в АЛУ в данном случае гарантирует, что информация будет оставаться стабильной на всё время её обработки, не задерживая при этом подготовку выполнения следующей операции (в частности, после того, как данные из блока регистров были зафиксированы по С2, возможно начало выдачи на блок регистров адресов регистров для следующей операции -- к искажению данных, идущих в АЛУ, это уже не приведёт, поскольку они зафиксированы в рабочих регистрах, а значит, состояния выходов блока регистров уже роли не играет).
В общем, всё не так однозначно, если говорить не про конкретную реализацию, а про возможные подходы вообще. И нет гарантии, что подход, хорошо работающий в одном случае, окажется столь же хорошим в другом. Собственно, конструктор может считаться грамотным только тогда, когда он в каждом конкретном случае применяет наиболее подходящий из возможных вариантов, а не слепо следует некоторому "стандартному" подходу.
P.S. ПЛИС не может служить в данном случае "жёстким" критерием, поскольку там разработчик имеет дело с довольно специфическими элементами, которые, понятное дело, "навязывают" определённые правила разработки. Возможно, там действительно выгодней использовать лишь однофронтовую синхронизацию -- но утверждать я б не взялся, пока не убедился б лично, разработав несколько вариантов с разными подходами и сравнив их на практике. Однако, если есть полный простор для творчества (разработка на "рассыпухе" -- неважно, отдельные ли это микросхемы, БМК или вообще проектирование ИС с нуля), наилучших результатов можно добиться при более гибком подходе. Другое дело, что это может оказаться не оправданным с экономической точки зрения (затягивание сроков разработки и т.д.).
Gudd-Head писал(а):Таки да, заточить всё под максимальную частоту. А на меньших будет просто больше свободного времени.
AVRки все таки гонятся (сам пробовал и по опыту других людей иногда весьма не плохо), при таком подходе разогнать выше максимальной частоты из даташита не получилось бы однозначно, кроме того нужно задержки как то нормировать (при изменении скажем температуры задержка будет меняться, что в такой системе будет не допустимо), кроме того думается использовать произвольные задержки в синхронных системах совсем не айс. Не правильный подход ИМХО.
Купи два беляша и собери из них кошку
Labor est etiam ipse voluptas Труд уже сам по себе есть наслаждение (*Формула любви)
Ave novie-nostra ales Если один человек построил - другой завсегда разобрать может....(*Формула Любви).
Panda_Y2K писал(а):при таком подходе разогнать выше максимальной частоты из даташита не получилось бы однозначно
Опять, почему же?
При 16 МГцах период равен 62,5 нс.
Допустим, такт на выполнение операций в АЛУ даётся с задержкой на 20 (10) нс, на запись результата — с задержкой 40 (20) нс. Выборка регистров-операндов делается без задержки.
Тогда во всём диапазоне температур это будет работать. А по диапазону напряжений... может, как раз из-за этого МК не может работать быстро при низком напряжении питания (соотв. картинка в ДШ "напряжение — макс. частота") — потому что задержки уплывают.
[ Всё дело не столько в вашей глупости, сколько в моей гениальности ] [ Правильно заданный вопрос содержит в себе половину ответа ]
SmarTrunk писал(а): Рисунок с тактами слишком схематический, по нему нельзя делать категоричных выводов.
100% !!!
Учитывая имеющиеся ошибки и несоответствия, документацию АТМЭЛ нельзя признать идеальной и полностью достоверной...
Видать некоторые господа никогда в жизни не имели дело с документацией... им неведомы неточности, неоднозначные толкования и пр. ...
ibiza11 писал(а):че за *уйню вы тут городите??? вы вообще знаете, что такое конвейер?
100% !!!
Конвейер есть... и посему"выполнение за один такт" - мнимое... нравится это кому-то или нет...
--------------------------------------------------
Отсюда... Господа писатели, все ваши догадки и измышления по поводу работы АТМЭЛА - голдсмитовский бред... и никак иначе!!!
Не пожелал АТМЭЛ досконально расписать "ху из ху"... и это его право... в отличие того же STM и пр. ...
P.S: По поводу PLL...
"Мопед не мой, я просто разместил объяву!"(С)
Вспомнилась подобная тема на казусе... вспомнилась упомянутая идея PLL... ну и ...
"Я не даю готовых решений, я заставляю думать!"(С)
