Перейти к содержанию
    

Yuri124

Участник
  • Постов

    757
  • Зарегистрирован

  • Посещение

Репутация

1 Обычный

Информация о Yuri124

  • Звание
    Знающий
    Знающий

Посетители профиля

2 109 просмотров профиля
  1. на какое время? прописать время задержки в файл sdc...
  2. Извините, но Вы "решили" задачу способом - разбросав по полю грабли. Вам же объяснили, что этих элементов внутри FPGA просто нет... Вам же в самом начале темы предложили применить многовходовой элемент И или ИЛИ (в зависимости от потребности). Нарисует Вам симулятор то, что Вашей душе угодно - а как потом это "в железе" физически реализовать?
  3. а можно подробностей - чем Вас "традиционные алгоритмы" не устраивают? И пару слов про Ваши алгоритмы?
  4. Вы слишком оптимистичны. Не забывайте, что сигналы в Вашей схеме распространяются по таким компонентам, как соединительные линии внутри кристалла, коммутаторы (перебрасывают сигнал с одной линии на другую), логические элементы - все они имеют задержки. Загляните в даташит к-л простого ЛЭ, например, 74АС14 - Вы увидите, что сигналу, чтобы пройти с его входа на выход, потребуется гораздо времени, чем прошел бы свет 1 см расстояния. Вы схему нарисовали? Нарисовали. Теперь описать ее в Верилоге - это не просто, а очень просто. Вопрос времени...
  5. Если может быть Вам ближе микроконтроллеры - чтобы процессорное ядро не тратило свои вычислительные ресурсы для программной реализации к-л блока (интерфейса, таймера, счетчика) - в микроконтроллер добавляется уже готовая, аппаратная реализация нужного функционала. Аналогично и в микросхемы FPGA добавляются уже готовые аппаратные блоки, реализующие часто необходимые функции (блоки DSP, интерфейсы). Зачастую реализовать это просто невозможно из стандартных "кирпичиков", имеющихся в FPGA. Например, интерфейс PCIe должен выдавать/принимать данные на частоте нескольких гигагерц. Поэтому внутри FPGA добавляется такой скоростной блок, который принимает-передает наружу микросхемы на гигагерцах, а внутрь FPGA или из нее данные поступают по более широкой (гораздо более многоразрядной шине) на той частоте, которую уже способна "переварить" эта FPGA. Это делается как раз для того, чтобы необходимый блок работал с заявленными характеристиками.
  6. частота то одинаковая, но может оказаться так, что блоки между собой не зависимы (если нет передачи данных между ними) - т.е. легче их развести в кристалле с макс. частотой (минимальными задержками) при трех различных CLK (с различными названиями). А если все три блока тактируются одним клоком (с одним названием) - они будут зависимы, разложить их в кристалле может оказаться сложнее. На истину в посл. инстанции не претендую, в конкретно этом Вашем проекте может оказаться по-другому. Ну и степень "забитости" кристалла имеет значение. Если наполовину свободен - то синтезатору проще со всем разобраться, если забит под 80% - уже сложнее...
  7. Насколько я понимаю - кроме кол-ва логических блоков на частоту влияют также задержки на элементах коммутации сигналов и длина путей. Ведь , к примеру, 2 блока логики могут находиться рядом или на противоположных сторонах кристалла - соответственно время прохождения сигнала через них при кажущейся одинаковости будет разное. А если CLК идет по выделенным скоростным ресурсам, то этот сигнал будет заметно быстрее доходит до тактируемых элементов, чем данные. Т.е. надо задержать тактируемый фронт = понизить частоту. Ну и когда у Вас 3 разные частоты "питают" 3 разных блока - они , наверное, считаются независимыми? Возможно, синтезатору легче разложить требуемое железо в кристалле с требуемыми частотами...
  8. Возможно, Вы не совсем поняли. В результате работы над тем проектом были опробованы два варианта блоков: 1. комбинационная схема (огромная куча логики без триггеров), и была определена макс. частота ее функционирования. 2. схема с использованием конвейера - со своей частотой работы.
  9. я под асинхронщиной имел в виду такой кусок, который без триггеров. Т.е. при подаче исходных сигналов на вход нужно только ждать результата на выходе. Конкретный пример: у меня был проект, без триггеров внутри. Результат на выходе был гарантирован через 100 нсек. Синхронная (конвеерная) схема при частоте 100МГц выдавала бы результат через 450-500 нсек. Т.е. после подачи на вход асинхронного блока я мог через 110 нсек гарантированно забирать результат обратно в синхронную часть. Но на самом деле надо бы использовать обе реализации - и асинхронную (т.к. периодически нужно было получить только один результат), и синхронную - получать подряд серию (она бы после истечения 500 нсек шла уже со скоростью 10 нсек/результат). К сожалению, для обеих не хватало ресурсов имеющегося кристалла...
  10. А "таблица истинности" - это как? Разве не текстом ее нужно будет как-то описать? Ну и до кучи - когда Вы рисуете схему из элементарных кирпичиков - на выходе все равно получаете последовательность вых. сигналов в зависимости от входных. Только это стороннему взгляду трудно понять. А разработчику - трудно обнаружить и исправить ошибку. Текстом (на к-л языке) можно не только описать эти соединения, но пойти дальше - описывать сразу поведение блока - т.е. сразу описать зависимость выходов от входов. А как оно внутри куска кремния будет физически реализовано (конкретная схема) - это отдать на откуп синтеза тору, который лучше знает особенности построения этого кремния. Иногда асинхронный кусок может оказаться полезным - ранее уже был приведен пример на эту тему. Что же касается готовности - можно посчитать худший случай готовности асинхронного куска (т.е. передали асинхронному блоку на обработку, выждали положенное время - результат готов), При хендшейке также нужно учитывать то, что опрос готовности происходит на другой скорости - на скорости синхронного блока. Например, асинхронный блок способен работать (выдавать готовый результат) через 100 нсек (10МГц), если же синхронный блок работает на 100МГц - то времени потеряется 1-2 такта работы синхронной схемы.
  11. Запускать тактирующий сигнал через такую цепочку ЛЭ - ну, так себе идея, я полагаю. В идеале - тактирующий сигнал приходит одновременно на все тактируемые элементы. в реальности при синтезе в железе получим, например, коммутатор. Т.е. - можно его описать просто одной строкой текста. Читать - может быть и легче, а вот понять ее работу... Ну и - очень часто несколько строк кода позволяют описать функционирование достаточно сложного по схемотехнике узла. вместо того, чтобы конструировать его самому из логических элементов. Т.е. эту рутинную работу, сопряженную с возможностью ошибиться, Вы поручаете синтезатору.
  12. А можно и по-другому CE & A[3:0]& B[1:0] в один LUT, например... Ну и - я не в курсе, как там ресурсы распределены физически в кристалле, синтезатор сам должен оптимизировать исходя из заданных условий оптимизации (скорость или размер, к примеру).
  13. это так светодиод обозначен. как я понимаю - чисто условно (т.е. без резистора и значок обычного диода - было про это у ТС в тексте - правда, про резистор я сам предположил). Конечно, Вы совершенно правы - надо было бы нарисовать правильный значок + резистор, чтобы видящий эту схему не отвлекался на лишние размышления.
  14. Вы должны понимать, что на самом деле весь этот код не описывает программу действий (как программирование микропроцессора), а Вы этими записями описываете конструкцию какого-то устройства. Т.е. Вы должны себе четко представить (нарисовать) схему/структуру/блок-схему того устройства, которое должно быть синтезировано (сконструировано, "спаяно") внутри FPGA из имеющихся там базовых кирпичиков. А только потом - описать эту структуру/эту схему средствами языка синтезирования аппаратуры. Иначе может получиться, что логически Вы устройство описали правильно, но физически оно будет синтезировано компилятором в очень громоздкую монструозную схему с низким быстродействием (большими задержками при формировании к-л сигналов). Правда, компиляторы умеют оптимизировать схему, но как это у каждого конкретного получается - думаю, что по-разному. И лучше все же в первую очередь полагаться на себя, а компилятору отдавать на откуп более простые конструкции - где он сам сможет оптимально размести сигналы по имеющимся ресурсам (расстояние, кол-во входов LUT и кол-во используемых сигналов). Как-то так.
  15. логика в том, что для реализации этого if-а пришлось навернуть логическую схему (которая вполне могла не уложиться в один LUT FPGA, что привело к накручиванию путей прохождения сигналов (к ним добавляются коммутаторы этих сигналов) - в результате возросла задержка во всего одном месте цепочки, тактируемой этими клоком - образовалось бутылочное горлышко, которое и нарушило красивую картинку, рисующую полтора гигагерца. Вам уже рекомендовали: т.е. проследите, откуда эта частота передается (генерируется), как она распространяется (что ею тактируется) - вполне может оказаться, что Вы ее используете еще для чего-то, кроме как подать на RAM, либо неоптимально на нее подается (опять же через какой-нибудь if 😄.
×
×
  • Создать...