Я знаю про проектное управление. В вашем случае получается что Иван занимается только руководством проектом. Т.е. берёт ответственность, заполняет планы. На мой взгляд, он получает неоправданно много. Нормальный уровень оплаты — около 20.
Описана классическая схема управления проектом. Сразу возникает вопрос — а в чём отлчие от других?
Проблемы здесь точно такие же.
Во первых представляется крайне сомнительным что можно заранее расписать все задачи и определить из трудоёмкость. Это можно сделать только для очень простых проектов.
Во вторых также крайне сомнительна возможность создать иерархию задач. Обычно иерархия недостаточно точно описывает систему.
Ну и про Ивана — отпуск это святое, конечно он может уйти.
Вот мне совершенно не нравиться «идеологически правильный» код передатчика. Как уже писали выше это потенциальный источник ошибок. На мой взгляд лучше использовать конструкцию always (@postedge clk) и внутри описывать нужную логику.
Синтезатор всё сделает в соответствии со стандартом языка, значение canfetch будет использоваться в том же самом такте. canfetch надо рассматривать как временную переменную и не использовать вне этого блока. Автор так и делает. Всё корректно. В VHDL в таком описании используется variable, её в принципе нельзя использовать за пределами process (который является аналогом always блока). Это снижает вероятность ошибки.
Будет ли работать эта большая комбинационная схема сообщит трассировщик, если частота небольшая, например 1 МГц, то вполне может заработать.
Что такое «потом»? Код на Verilog не императивный, он декларативный. Его обманчивая похожесть на C/Java — его самый большой недостаток. Если внутри always-блока вы напишете несколько if на одном уровне вложенности, они все будут проверяться ПАРАЛЛЕЛЬНО и ОДНОВРЕМЕННО (с поправкой на время распространения фронта тактирующего сигнала).
Вообще то говоря это не совсем так. Verilog, так же как и VHDL содержат как параллельные так и последовательные конструкции. В целом описывается параллельная конструкция, но иногда для удобства описания применяются последовательные конструкции. VHDL имеет для этого более строгие понятия signal и variable, Verilog имеет блокирующие и неблокирующие присваивания.
В примере canfetch используется только внутри always блока причём только для вычисления значений по фронту clk. Это вполне нормальное применение. Синтезатор для этого примера обязан сделать большую комбинационную схему. Недостатком является как раз размер этой комбинационной схемы, но не способ описания.
Задержка after 1 ns вноситься только после сигналов триггера.
Разные частотные домены я всегда рассматриваю как асинхронные и переход между доменами это FIFO, DPRAM или несколько триггеров. Так что after 1 ns в этом случае тоже совершенно не мешает.
из-за особенностей моделирования у присвоения «clk2 <= clk1» нет прямого эквивалента в синтезе, т.к. в моделировании такая конструкция создаёт задержку (пусть и дельта), а в синтезе — нет.
Совершенно верно. «clk2 <= clk1» преобразуется в цепь без задержек в соответствии со стандартом языка. Ссылки на стандарт ниже.
Но вот статья именно об этом — разная интерпретация языковых конструкций синтезатором и симулятором. Заметьте — корректных конструкций.
То, что вы в итоге добавляете задержки в присвоения, по сути имеет ту же заложенную проблему — подобные присвоения не будут эквивалентными результатам синтеза.
Не так. Добавление задержек соответствует результатам синтеза. Конечно при условии что задержка меньше периода тактового сигнала.
Я признателен всем участникам обсуждения, особенно old_bear, Des333, ishevchuk
Ну и некоторые комментарии. Я не претендую на полное описание процесса симуляции. Идея статьи появилась в результате обсуждения вопросов для собеседования. Я придумал два вопроса и дал на них ответы. Но похоже по этим вопросам мало кто сможет пройти собеседование :-)
Синтезатор задержки игнорирует. Это есть в стандарте 1076.6 IEEE Standard for VHDL Register Transfer Level (RTL) Synthesis
Вот выдержка из стандарта:
Это есть в ug901-vivado-synthesis.pdf:
Так что формально вставлять задержки в боевой код можно. В соответствии со стандартом синтезатор их проигнорирует.
Интересный вопрос:
На самом деле вопрос же заключается в том, что если удалить все исходники, уволить всех коллег, оставить только Вас и набрать в FPGA команду студентов, которые ничего не знают, то Вы тоже будете им предлагать писать задержки во всех модулях и во всех проектах или нет? При условии, что Вы их руководитель/учитель/ментор и Вам дают большой бюджет и никто со сроками не торопит.
Да, я будет вставлять задержки и буду обучать учеников. Собственно это я делаю. Правда не все поддаются.
За 18 лет я не смог привыкнуть к виду диаграммы в которой фронт клока и изменение сигнала визуально совпадают. Может надо ещё подождать?
Я написал максимально простой пример, разные варианты я совершенно сознательно поместил под комментарий. Это гораздо проще изучить. Конечно его можно усложнить, сделать отдельные компоненты с разной реализацией. Но это только усложнит понимание.
Но если доводить до аппаратуры то это придётся сделать. Может быть я это сделаю.
Ещё раз про то откуда берётся переприсвоение тактового сигнала. В основном это когда копипастом помещается код из другого компонента. Добавляется кусок кода, добавляются сигналы. Если название не совпадает, то и происходит переприсваивание. Другой вариант, если есть несколько источников а выбирается один. Имеется ввиду не мультиплексор а простое назначение сигнала. Это конечно можно сделать через alias но кто про него помнит?
В основном это происходит на этапах финальной отладки проекта, когда про модель уже забывают.
Поддержание проекта в виде пригодном для моделирования это достаточно сложная проблема. Но это уже тема для отдельной статьи.
Вы конечно можете не отвечать, я не навязываюсь. Но хочу ещё раз отметить, синтезатор задержки ИГНОРИРУЕТ. Причём все, включая дельта задержку.
Поэтому любое присваивание, что через assign/alias, что простое присваивание сигнала в vhdl приведёт к одному результату. Это будет одна цепь, без всяких мифических элементов задержки на величину delta. Это кстати тоже необходимое знание для разработчика FPGA.
На мой взгляд это просто и очевидно. Неужели я так плохо объясняю?
Вы задали вопрос — эквивалентом какого аппаратного элемента FPGA является переприсвоение тактового сигнала.
Я отвечаю, причём уже много раз, это будет одна и та же цепь.
Разве я не понятно ответил?
Или вы не понимаете проблему?
Для определённости — я говорю о Xilinx и синоезаторах из пакетов ISE и Vivado.
Конструкция VHDL: clk1 <= clk2; будет реализована одной цепью. Цепь может получить имя одного из сигналов, но скорее всего будет называться по имени источника.
Я сейчас не могу привести ссылку на кодестайл, не уверен что это вообще есть в описаниях. Но реально это работает.
Эта проблема совершенно не имеет отношения к управлению проектом. Это проблема знания матчасти. А именно знания случая когда моделирование и синтез даст разные результаты.
Переприсваивание клока не является ошибкой, тем более грубой. Синтезатор это корректно обрабатывает, код будет работать. Симулятор также всё обработает, результат будет, но немного другой. Но как говориться — что просили, то и получили.
Я кстати не первый раз публично поднимаю тему с задержками и всегда получаю волну критики. Основной аргумент — лень добавить несколько слов. А то что это позволяет решить реальные проблемы и в итоге сэкономить кучу времени как то упускается из виду. Здесь действует принцип — раз я с этим не сталкивался значит этого нет. Ну а я сталкивался.
Это уже уход в область управления проектами и организацией в целом.
Вне зависимости от тимлида есть только два решения этой проблемы — задержки и правильное присваивание. Вопрос — что выбираем?
P.S. Если тимлид утверждает что в коде совершенно нет «undefined behaviour» то это должно очень сильно насторожить руководство.
Хочу ещё раз отметить. Я занимаюсь реальной работой по проектированию ПЛИС в течении длительного времени. В статье приведён простой пример который демонстрирует РЕАЛЬНУЮ проблему. Я охотно верю, что если один разработчик делает один проект то проект может быть идеальным. У нас не так. У нас много проектов и каждом до 90% чужого кода. Отследить что бы не было переприсваивания клока практически невозможно. Однажды я очень сильно об это обжёгся, я очень много времени потратил на поиск подобной ошибки.
Так что утверждения что это надуманная проблема я считаю ошибочными, это РЕАЛЬНАЯ проблема.
Решения у этой конкретной проблемы может быть только два:
Вставляем задержки
Делаем присваивание клока через alias или assign
Я выбрал первый способ. Второй я считаю ненедёжным. Ну а лучше всего использовать оба.
Он что-то полезное делает?
Или только руководит?
Описана классическая схема управления проектом. Сразу возникает вопрос — а в чём отлчие от других?
Проблемы здесь точно такие же.
Во первых представляется крайне сомнительным что можно заранее расписать все задачи и определить из трудоёмкость. Это можно сделать только для очень простых проектов.
Во вторых также крайне сомнительна возможность создать иерархию задач. Обычно иерархия недостаточно точно описывает систему.
Ну и про Ивана — отпуск это святое, конечно он может уйти.
В VHDL повторное присваивание внутри процесса (аналог always) прекрасно работает. Выполняться будет последнее по тексту.
Будет ли работать эта большая комбинационная схема сообщит трассировщик, если частота небольшая, например 1 МГц, то вполне может заработать.
Вообще то говоря это не совсем так. Verilog, так же как и VHDL содержат как параллельные так и последовательные конструкции. В целом описывается параллельная конструкция, но иногда для удобства описания применяются последовательные конструкции. VHDL имеет для этого более строгие понятия signal и variable, Verilog имеет блокирующие и неблокирующие присваивания.
В примере canfetch используется только внутри always блока причём только для вычисления значений по фронту clk. Это вполне нормальное применение. Синтезатор для этого примера обязан сделать большую комбинационную схему. Недостатком является как раз размер этой комбинационной схемы, но не способ описания.
Разные частотные домены я всегда рассматриваю как асинхронные и переход между доменами это FIFO, DPRAM или несколько триггеров. Так что after 1 ns в этом случае тоже совершенно не мешает.
Совершенно верно. «clk2 <= clk1» преобразуется в цепь без задержек в соответствии со стандартом языка. Ссылки на стандарт ниже.
Но вот статья именно об этом — разная интерпретация языковых конструкций синтезатором и симулятором. Заметьте — корректных конструкций.
Не так. Добавление задержек соответствует результатам синтеза. Конечно при условии что задержка меньше периода тактового сигнала.
Ну и некоторые комментарии. Я не претендую на полное описание процесса симуляции. Идея статьи появилась в результате обсуждения вопросов для собеседования. Я придумал два вопроса и дал на них ответы. Но похоже по этим вопросам мало кто сможет пройти собеседование :-)
Синтезатор задержки игнорирует. Это есть в стандарте
1076.6 IEEE Standard for VHDL Register Transfer Level (RTL) Synthesis
Вот выдержка из стандарта:
Это есть в ug901-vivado-synthesis.pdf:
Так что формально вставлять задержки в боевой код можно. В соответствии со стандартом синтезатор их проигнорирует.
Интересный вопрос:
Да, я будет вставлять задержки и буду обучать учеников. Собственно это я делаю. Правда не все поддаются.
За 18 лет я не смог привыкнуть к виду диаграммы в которой фронт клока и изменение сигнала визуально совпадают. Может надо ещё подождать?
Я написал максимально простой пример, разные варианты я совершенно сознательно поместил под комментарий. Это гораздо проще изучить. Конечно его можно усложнить, сделать отдельные компоненты с разной реализацией. Но это только усложнит понимание.
Но если доводить до аппаратуры то это придётся сделать. Может быть я это сделаю.
Ещё раз про то откуда берётся переприсвоение тактового сигнала. В основном это когда копипастом помещается код из другого компонента. Добавляется кусок кода, добавляются сигналы. Если название не совпадает, то и происходит переприсваивание. Другой вариант, если есть несколько источников а выбирается один. Имеется ввиду не мультиплексор а простое назначение сигнала. Это конечно можно сделать через alias но кто про него помнит?
В основном это происходит на этапах финальной отладки проекта, когда про модель уже забывают.
Поддержание проекта в виде пригодном для моделирования это достаточно сложная проблема. Но это уже тема для отдельной статьи.
Вы конечно можете не отвечать, я не навязываюсь. Но хочу ещё раз отметить, синтезатор задержки ИГНОРИРУЕТ. Причём все, включая дельта задержку.
Поэтому любое присваивание, что через assign/alias, что простое присваивание сигнала в vhdl приведёт к одному результату. Это будет одна цепь, без всяких мифических элементов задержки на величину delta. Это кстати тоже необходимое знание для разработчика FPGA.
На мой взгляд это просто и очевидно. Неужели я так плохо объясняю?
А ничего что я про VHDL пишу?
Вы задали вопрос — эквивалентом какого аппаратного элемента FPGA является переприсвоение тактового сигнала.
Я отвечаю, причём уже много раз, это будет одна и та же цепь.
Разве я не понятно ответил?
Или вы не понимаете проблему?
Для определённости — я говорю о Xilinx и синоезаторах из пакетов ISE и Vivado.
Конструкция VHDL: clk1 <= clk2; будет реализована одной цепью. Цепь может получить имя одного из сигналов, но скорее всего будет называться по имени источника.
Я сейчас не могу привести ссылку на кодестайл, не уверен что это вообще есть в описаниях. Но реально это работает.
Я говорю о присвоении сигнала в VHDL:
clk1 <= clk2;
Это синтезируется.
Эта проблема совершенно не имеет отношения к управлению проектом. Это проблема знания матчасти. А именно знания случая когда моделирование и синтез даст разные результаты.
Переприсваивание клока не является ошибкой, тем более грубой. Синтезатор это корректно обрабатывает, код будет работать. Симулятор также всё обработает, результат будет, но немного другой. Но как говориться — что просили, то и получили.
Я кстати не первый раз публично поднимаю тему с задержками и всегда получаю волну критики. Основной аргумент — лень добавить несколько слов. А то что это позволяет решить реальные проблемы и в итоге сэкономить кучу времени как то упускается из виду. Здесь действует принцип — раз я с этим не сталкивался значит этого нет. Ну а я сталкивался.
Вне зависимости от тимлида есть только два решения этой проблемы — задержки и правильное присваивание. Вопрос — что выбираем?
P.S. Если тимлид утверждает что в коде совершенно нет «undefined behaviour» то это должно очень сильно насторожить руководство.
Так что утверждения что это надуманная проблема я считаю ошибочными, это РЕАЛЬНАЯ проблема.
Решения у этой конкретной проблемы может быть только два:
Я выбрал первый способ. Второй я считаю ненедёжным. Ну а лучше всего использовать оба.