[eugen_pcad_ru 0]

Всем доброго времени суток, уважаемые коллеги!

Столкнулся с необходимостью реализации в Хilinх-овском пакете элементов, аналогичных элементам LСЕLL в Аltеr-овском пакете.

Поясню для тех, кто не сталкивался с Аltеr-oй: LСЕLL - это элемент, принудительно добавляющий к сигналу асинхронную задержку длиной в один вентиль (если в настройках пакетах не установлено игнорирование таких примитивов). Что-то типа инвертора, но без инверсии сигнала:)

 

Максимально близкий аналог в VHDL - слово "after", но оно вроде относится только к тест-бенчам? Или я не прав?

В общем вопрос: как это можно организовать (в перспективе параметризируемым)? Можно в схематике, в общем любым способом.

 

Всем спасибо за любую предоставленную информацию!

 

P.S.: VHDL и ISE только начинаю осваивать, сильно не пинайте:)

[iosifk 3]

Столкнулся с необходимостью реализации в Хilinх-овском пакете элементов, аналогичных элементам LСЕLL в Аltеr-овском пакете.

 

Что-то Вы не с тем "столкнулись", ибо делать такие фокусы - это значит быть мазохистом... Никогда так не делайте! Читайте только о синхронных проектах!

 

[Kuzmi4 0]

Как то вот так:

// LUT1: 1-input Look-Up Table with general output
   //       Spartan-3E
   // Xilinx HDL Language Template, version 11.4

   LUT1 #(
      .INIT(2'b00)  // Specify LUT Contents
   ) LUT1_inst (
      .O(O),   // LUT general output
      .I0(I0)  // LUT input
   );

   // End of LUT1_inst instantiation

Там лампочка есть на доске сверху в ISE, жмаете на неё и дальше "Verilog/VHDL-Device Primitive Instantiation-Slice/CLB Primitives-LUTs"

[AJIEKCEu 0]

Я бы поддержал iosifk. Все таки асинхронные проекты, где нужно добирать времянки по уровням логики - это в моем представлении не совсем правильный подход. И осознано это делать должны (а возможно и наоборот) только мега-супер-профессионалы. Если вы себя к ним пока? не относите - лучше поискать другие варианты решения вашей проблемы. И пытаться делать синхронную схему.

 

ЗЫ. Вы бы рассказали первопричины появления вашей необходимости. Возможно вам более правильные варианты решения расскажут.

[LV26 0]

Всем доброго времени суток, уважаемые коллеги!

Столкнулся с необходимостью реализации в Хilinх-овском пакете элементов, аналогичных элементам LСЕLL в Аltеr-овском пакете.

Поясню для тех, кто не сталкивался с Аltеr-oй: LСЕLL - это элемент, принудительно добавляющий к сигналу асинхронную задержку длиной в один вентиль (если в настройках пакетах не установлено игнорирование таких примитивов). Что-то типа инвертора, но без инверсии сигнала:)

 

Максимально близкий аналог в VHDL - слово "after", но оно вроде относится только к тест-бенчам? Или я не прав?

В общем вопрос: как это можно организовать (в перспективе параметризируемым)? Можно в схематике, в общем любым способом.

 

Всем спасибо за любую предоставленную информацию!

 

P.S.: VHDL и ISE только начинаю осваивать, сильно не пинайте:)

 

Он то там есть - но нужен совсем не для задержки, а для того чтобы не оптимизировалась цепь, если это уж по каким-то причинам приспичило.

И использование LCELL не рекомендуется для получения задержек (из книжки MAX+PLUS II AHDL)

[ViKo 1]

Что-то Вы не с тем "столкнулись", ибо делать такие фокусы - это значит быть мазохистом... Никогда так не делайте! Читайте только о синхронных проектах!

Перефразируя ваш ответ, получаем: "Никогда не программируйте ARM на ассемблере! Используйте только готовые библиотеки!" :)

[iosifk 3]

Перефразируя ваш ответ, получаем: "Никогда не программируйте ARM на ассемблере! Используйте только готовые библиотеки!" :)

Видите ли, разница в том, что для микропроцессора выполнение команд гарантируется их архитектурой. И не суть важно, Си это или ассемблер.

А вот для ПЛИС задержка на Гейтах типа LCELL не гарантируется. Не гарантируется сохранение времени этой задержки от одной микросхемы к другой. От партии к партии. Не гарантируется, что через год не появится модификация данной микросхемы и т.д.

Удачи!

 

[AJIEKCEu 0]

Перефразируя ваш ответ, получаем: "Никогда не программируйте ARM на ассемблере! Используйте только готовые библиотеки!" :)

Я бы не сказал, что это действительно аналогичные вещи. Что-то аналогичное тому, что пытается сделать eugen_pcad_ru это реализация приемо-передатчика Ethernet 10BaseT напрямую на ногах логической схемы (без Phy). - теоретически сделать можно, и в некоторых случаях (возможно даже в большинстве) работать будет, но вообще говоря работоспособность и соответствие стандартам никем не гарантируется.

 

Насколько я знаю в библиотечных элементах xilinx LUT-ы не используются в качестве задержки (впрочем, возможно есть одно исключение http://www.xilinx.com/support/documentatio...tes/xapp780.pdf, в котором хитрые задержки используются для генерации рандомного числа, но это _ЯВНО_ нетипичный случай). Между тем, в стандартных С-шных библиотеках то и дело встречаются ассемблерные вставки. И это явно не исключение.

 

В общем и целом, наверное, есть очень ограниченный круг случаев, когда стоит пользоваться задержками логических элементов. Но у нас применение такой логики потребовало бы подписи главного конструктора как минимум и доказательной базы, что в данном конкретном случае нужно делать только так и это действительно имеет смысл. Собственно поэтому я и попросил первопричину.

 

ЗЫ. А ссылки Victor®'а на документ Altera'ы вам недостаточно?

[ViKo 1]

В общем и целом, наверное, есть очень ограниченный круг случаев, когда стоит пользоваться задержками логических элементов.ЗЫ. А ссылки Victor®'а на документ Altera'ы вам недостаточно?

Если последний вопрос ко мне, то я понял, что это не документ Altera, а книжка, например, Антонова. Если так, то мне этого недостаточно :)

Уже говорил когда-то, пока проект можно делать синхронным, нужно делать. Если же потребуется более короткое время, чем такт, никуда не деться, придется использовать и учитывать внутреннее устройство ПЛИС.

[LV26 0]

Если последний вопрос ко мне, то я понял, что это не документ Altera, а книжка, например, Антонова. Если так, то мне этого недостаточно :)

Уже говорил когда-то, пока проект можно делать синхронным, нужно делать. Если же потребуется более короткое время, чем такт, никуда не деться, придется использовать и учитывать внутреннее устройство ПЛИС.

 

Нет - это из "бумажной" книжки Altera, которая шла в комплекте с MAX+PLUS II.

Точное название не скажу, нет ее сейчас по рукой - емнип "Altera MAX+PLUS II AHDL" называется.

 

Да и без книжки - английским по белому

http://quartushelp.altera.com/10.0/master....mp;WT.oss=LCELL

[ViKo 1]

Do not use LCELL primitives to create an intentional delay or asynchronous pulse. The delay of these elements varies with temperature, power supply voltage, and device fabrication process, so race conditions can occur and create an unreliable circuit

 

Нашел это. Ну, что сказать - не используйте... там где не надо :)

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

[SM 0]

А вот для ПЛИС задержка на Гейтах типа LCELL не гарантируется. Не гарантируется сохранение времени этой задержки от одной микросхемы к другой. От партии к партии. Не гарантируется, что через год не появится модификация данной микросхемы и т.д.

 

Вот это истинная неправда. Все гарантируется, иначе бы, как минимум, STA и моделирование в best/worst/typical case было бы пустым делом, а не гарантией работоспособности. И все эти задержки для всех case специфицированы в документации. Но, правда, разброс у них "от и до" очень дайбоже. Но и у обычной, привычной рассыпухи порядки разбросов этих задержек (как и вообще у большинства процессов изготовления ИС) - те же самые.

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

[Shtirlits 0]

Вяло поспорю с последним утверждением.

Предположим, что STA интересует только setup time, так как hold time нарушить проблематично.

Из этого следует, что ограничена задержка только сверху.

Допустим, что STA использует наихуджее из вообще встречающихся в данном speed grade значение.

Можно также предположить, что задержки лежат между speed grade, более быстрые микросхемы не маркируются как медленные невзирая на протесты маркетологов. Мне кажется, что полагаться на это опасно.

Также это предположение не помогает для самого быстрого speed grade.

 

Вывод- все это фигня.

 

Использовать можно, но фактически только для очень ограниченного круга приложений. В голову приходит только пара - динамически калиброванная относительно известного клока цепочка и создание задержки, точность которой вообще ни на что не влияет.

 

У меня был такой случай, когда надо было декодировать NRZ для Ethernet 10BaseT, а частота была всего лишь в 2 раза выше. Даже использование обоих фронтов не позволяло устранить неопределенность. Только внесение ну-хоть-какой-нибудь задержки давало однозначное распознавание 0 и 1.

 

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

 

[des00 25]

Предположим, что STA интересует только setup time, так как hold time нарушить проблематично.

Вот это в корне не правильно

Вывод- все это фигня.

Поэтому и вывод ниочем.

 

ЗЫ. я использую LCELL когда имею патовую ситуацию в интерфейсах, особенно когда шина в готовом устройстве повешена на пины с разными характеристиками.

 

[SM 0]

Предположим, что STA интересует только setup time, так как hold time нарушить проблематично.

...

Допустим, что STA использует наихуджее из вообще встречающихся в данном speed grade значение.

Эти оба "предположим" и "допустим" - неверны. STA интересует все: setup, hold, recovery, removal, и даже propagation, если его обконстрейнили. Если сам себе злобный буратино - можно анализ холдов выключить. Но нарушить холды - это как два байта...

Касаемо второго допущения - STA использует те значения, которые Вы сами ему сказали использовать, задавая "operating conditions".