[SM 0]

Есть такая штука, называется переносимость проекта.

Вот в первую очередь поэтому и следует использовать IP памяти, так как когда начнете реально (а не на словах, и не между соседними спартанами) заниматься этой самой переносимостью, на очередном "переносе" выяснится, что синтез не предусматривает генерацию блоков памяти по HDL описанию (а то и вообще, эти самые блоки надо заказывать в сервисе на фабе, и никакой возможности сгенерировать их локально нету). Переносить такие проекты, особенно на gate array или asic выходит очень геморно - выискивать все эти памяти в коде, разбираться, какие там они синхронные или асинхронные, сколько портовые, и т.п., заменять на подключенные модули. В общем, никакой переносимости нет у HDL-описанной памяти, это откровенная профанация, для переносимости надо использовать memoty compiler-ы, которые для FPGA есть в составе всяких там IP-Express-ов/мегавизардов/т.п., а для GA/ASIC поставляются отдельно по запросу, либо конкретные блоки памяти генерируются по требуемым характеристикам по запросу.

 

Но темы это не касается, по теме - другое преимущество использования компиляторов памяти, то, что они не переоптимизируются, и адреса в них не переворачиваются.

 

Чушь. Для обычной rom памяти использую и буду использовать.

Хоть почитайте в чем проблема-то. Дело то не в атрибутах или ядрах.

 

Если бы по-нормальному подключали память, а не при помощи синтеза, то она бы тогда полностью соответствовала описанию и моделировалась аналогично в синтезированном виде и в несинтезированном (c 101%-ной гарантией от производителя мемори-компилера), и не вызвала бы конкретных ваших проблем с ней и поиска костылей по их решению. По крайней мере одним источником "X"-ов было бы меньше. Так как внутри описания, генерируемого мемори-компилером везде, где надо, установлены атрибуты запрета оптимизации, и они (блоки) изобретены в том числе и для того, чтобы синтез соответствовал модели и документации на микросхему. А так - хотите проблем с переносимостью и моделированием, описывайте на HDL, только потом не надо катить бочки на оптимизацию синтеза, что она адреса вам перевернула, она на это имеет полное право при таком описании. Она вообще так описанную память "в бараний рог" скрутить может, что не найдете ее потом в нетлисте как память. Хотя у нас оно так принято, сначала создавать себе проблемы, потом их успешно решать, и этим гордиться, всем рассказав, как ее решили.

 

 

Кстати... Конструкция "if (reset && (reg != 3)) reg <= 3", это не глюк синтезатора, это показатель крутизны оптимизатора, что он настолько умным оказался. Видимо такое подключение что-то там сэкономило, или ускорило. Я так подозреваю, что для симуляции в таком случае надо какие-то опции синтеза подкрутить, чтобы он не делал эквивалентных логических преобразований, или, (может, не уверен на 100%), объявить wire reset1=fsm==RESET_ST /*synthesis syn_keep=1*/; и использовать его для сброса, вроде syn_keep отменяет логические оптимизации при использовании сигналов с этим атрибутом. И вообще, все цепи сброса выделять в отдельные wire и давать атрибут syn_keep, чтобы запретить их оптимизации.

[spooki 0]

нафлудил?
Во-первых Вы кажется упустили, что люди тратят свое время, помогая Вам.

Я ж не спорю. Просто не понял при чем тут асинхронный ресет.

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

 

Во-вторых мне больно смотреть на то, что вы пишите, зная что это пойдет в RTAX и чем может обернуться

 

Что конкретно написано в моем коде некорректно - укажите?

 

 

SM

Вот про запрет оптимизации некоторых конструкций это надо посмотреть.

Изменено 4 марта, 2014 пользователем spooki

[SM 0]

Вот про запрет оптимизации некоторых конструкций это надо посмотреть.

 

Скорее, даже, для линий сброса поставить атрибут "syn_direct_reset" или "syn_direct_set" (смотря сброс это или предустановка) - тогда синтезатор будет обязан эту цепь завести конкретно на сброс. Ну syn_keep не помешает тоже. И в любом случае выделить их в отдельные wire, а не ставить сложные условия сброса. А иначе все сигналы у него равнозначны и спокойно перемешиваемы друг с другом в любой комбинации, обеспечивающей логическую эквивалентность.

[Джеймс 3]

Что конкретно написано в моем коде некорректно - укажите?

 

уберите извращения кончайте эксперименты со сбросом, на которые вы потратили больше двух недель(!!)

сделайте асинхронный сброс с синхронизатором (скриншот из AppNote Microsemi я дал выше)

always @(posedge clk or posedge reset)
begin
if (reset)

Reset должен заходить на каждый триггер

[Timmy 1]

always @(posedge clk)
if (STATE==RESET_ST && first_measure!=3)
first_measure<=3;
else ...

 

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

Симуляция естественно не работала ибо регистр не инициализирован в начале (что невозможно в конкретной архитектуре ПЛИС) и вся надежда была на сброс.

Это не ошибка синтезатора. В аппаратуре такая схема будет правильно работать, ведь у реальных логических сигналов не бывает устойчивого состояния 'X', а только '0'/'1'. А проблемы симуляции синтезатор, естественно, не беспокоят:). Согласен с SM, надо вытащить условие сброса STATE==RESET_ST в отдельный сигнал и повесить на него syn_keep.

[o_khavin 0]

Вот в первую очередь поэтому и следует использовать IP памяти, так как когда начнете реально (а не на словах, и не между соседними спартанами) заниматься этой самой переносимостью, на очередном "переносе" выяснится, что синтез не предусматривает генерацию блоков памяти по HDL описанию (а то и вообще, эти самые блоки надо заказывать в сервисе на фабе, и никакой возможности сгенерировать их локально нету). Переносить такие проекты, особенно на gate array или asic выходит очень геморно - выискивать все эти памяти в коде, разбираться, какие там они синхронные или асинхронные, сколько портовые, и т.п., заменять на подключенные модули. В общем, никакой переносимости нет у HDL-описанной памяти, это откровенная профанация, для переносимости надо использовать memoty compiler-ы, которые для FPGA есть в составе всяких там IP-Express-ов/мегавизардов/т.п., а для GA/ASIC поставляются отдельно по запросу, либо конкретные блоки памяти генерируются по требуемым характеристикам по запросу.

 

Но темы это не касается, по теме - другое преимущество использования компиляторов памяти, то, что они не переоптимизируются, и адреса в них не переворачиваются.

 

А мужики то не знают. За прошедшие годы и переносы между Xilinx-ом, Альтерой и, будь он неладен, Латисом никаких проблем не обнаруживалось. Кроме того, тут раздел программируемой логики, не нужно сюда всякие asic-и примешивать.

Что касается всяческих пупер-визардов, то я прямо представил себе картину, как при срочном переезде на другую платформу, я объясняю начальству, что мне нужно потратить недельку-другую на перевставку всех тех десятков разнообразнейших вариантов памяти... Эти пупер-визарды - банальная заплатка на низкой квалификации инженера, который код пишет. По степени замедления разработки хуже только рисование полного схематика вместо написания кода.

 

Джеймс

Это тут не при чем. Начальное значение регистра и метастабильность это из разных опер!

Для случая счётчика результат один и тот-же - неизвестное состояние после старта. Кроме того, его сброс среди прочего решит Вашу проблему с симуляцией.

Я уже столько перевидал на своём веку знатоков, которые убеждали меня в излишестве корректного сброса всех элементов-генераторов (следующее значение которых зависит не только от входящих сигналов но и от собственного предыдущего состояния) и рассказывали как замечательно всё инициализируется при загрузке FPGA, а потом тратили недели на отлов непредсказуемых багов.

[SM 0]

не нужно сюда всякие asic-и примешивать.

Нужно. Например у меня уже несколько случаев было переноса с ПЛИС в кремний. После первого из них я раз и навсегда забыл об описании памяти на HDL, чего и всем желаю. Хотя, пожалуйста, ограничивайте себя узким кругом определенных сред... Ваше личное право. Неотъемлемое. И ваше же право трахаться месяц, когда начальство попросит сделать из Вашей ПЛИС разводку на БМК, вместо пары дней, потраченных на переподключение блоков RAM/ROM, и отмазываться, что, извините, у меня такой был несовместимый код, потому, что я не знал таких элементарных вещей, и что теперь все надо переделывать.

 

Кстати, если уж нравится описания на HDL - так пожалуйста, описывайте, но все равно в отдельно вынесенном модуле для каждого вида памяти, со стандартным набором сигналов - адреса, данные, rd/wr, и т.п., именно с целью переносимости, чтобы, если что, быстро переподключиться к другим блокам от другой технологии. Но, описания памяти на HDL, на мой взгляд являются как раз признаком низкой квалификации разработчика, говорящим о том, что он знаком только с узким кругом определенных ПЛИС, для которых синтезаторы умеют auto-inferring делать, либо вообще, только с моделированием, для которого такие описания придуманы. Использование memory compiler-ов говорит об обратном - высокой вероятности того, что разработчик готов быстро перейти с ПЛИС на кремний, если его попросят, и заранее пишет грамотные описания с учетом таких возможностей - это уже другой уровень.

 

И, заодно, чтобы заранее избежать всех тех проблем, что были с блоком памяти у автора, тоже полезно использовать нормальные описания памяти, а не глючный и опциональный (для синтезаторов) auto-inferring

[o_khavin 0]

Нужно. Например у меня уже несколько случаев было переноса с ПЛИС в кремний. После первого из них я раз и навсегда забыл об описании памяти на HDL, чего и всем желаю. Хотя, пожалуйста, ограничивайте себя узким кругом определенных сред... Ваше личное право. Неотъемлемое. И ваше же право трахаться месяц, когда начальство попросит сделать из Вашей ПЛИС разводку на БМК, вместо пары дней, потраченных на переподключение блоков RAM/ROM, и отмазываться, что, извините, у меня такой был несовместимый код, потому, что я не знал таких элементарных вещей, и что теперь все надо переделывать.

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

Во вторых, мне интересно каково соотношение между теми "несколькими" случаями и количеством проектов, которые никогда за пределы ниши FPGA не переезжали? Это, извините, как ходить всю жизнь в каске после случайного попадания шишкой по голове. Большинство тех, кто спрашивает здесь совета, никогда в жизни не столкнутся с необходимостью миграции по причине совершенно разных экологических ниш.

 

P.S. У меня тоже был опыт переноса IP на asic. Все эти ужасы, про которые Вы говорите, почему то со мной не приключились и процесс занял меньше недели. Но только одно "но" - всё равно понадобилась специфическая адаптация кода, суть которой определял заказчик и эта адаптация была достаточно нетривиальной, чтобы её предсказать заранее, и затрагивала в том числе и память, которую всё равно пришлось бы переделывать, будь она ранее описана пупер-визардами в FPGA-стиле.

 

P.P.S На остальные добавления мне лень отвечать. Если Вы предпочитаете однократному чтению документации по coding style-у, каждодневное тыкание кнопочек в визардах - дело Ваше. Я в своё время потратил один день на чтение и с тех пор ежедневно экономлю своё рабочее время.

Изменено 4 марта, 2014 пользователем o_khavin

[SM 0]

Это, извините, как ходить всю жизнь в каске после случайного попадания шишкой по голове.

И эта каска очень помогает. Почти все проекты состоят из каких-то отдельных IP-блоков. UART-ы, дециматоры, системы предвыборки из DRAM, USB, PCI, и т.п., и во многих из них применяется память. Так почему сразу их не сделать универсальными, если это ничего не стоит, кроме того, что блоки памяти надо вынести из общего кода в отдельные подключаемые модули, добавив в шапки этих модулей интерфейсы к блокам памяти? Сегодня это блок ставим в ПЛИС, завтра в ASIC - а блок то один и тот же! Обвязка в виде памяти только разная.

 

понадобилась специфическая адаптация кода, суть которой определял заказчик и эта адаптация была достаточно нетривиальной, чтобы её предсказать заранее,

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

 

 

Если Вы предпочитаете однократному чтению документации по coding style-у, каждодневное тыкание кнопочек в визардах

Я предпочитаю ставить примитивы памяти прямо из библиотек без всяких визардов. Или параметризованные функции, если такие имеются. Визарды, это последнее из вариантов, как получить описание памяти, и правда единственное в случаях ASIC (описать на HDL в слабой надежде на auto-inferring вообще не вариант, это применяется только для моделирования, а помнить все coding style для всех видов синтезаторов и помнить все их взбрыкивания совсем нет желания, заглянуть в доку по мемори компилеру IMHO проще и быстрее).

 

PS

За резкий стиль извините. Про квалификацию, кажется, не я начал. Но задело.

[o_khavin 0]

И эта каска очень помогает. Почти все проекты состоят из каких-то отдельных IP-блоков. UART-ы, дециматоры, системы предвыборки из DRAM, и т.п., и во многих из них применяется память. Так почему сразу их не сделать универсальными, если это ничего не стоит, кроме того, что блоки памяти надо вынести из общего кода в отдельные подключаемые модули, добавив в шапки этих модулей интерфейсы к блокам памяти? Сегодня это блок ставим в ПЛИС, завтра в ASIC - а блок то один и тот же! Обвязка в виде памяти только разная.

Сделать всё универсальным как раз стоит немалых трудозатрат. При этом, не знаю как у Вас, а в моей области большая часть проектов достаточна специфична. По моим прикидкам, вынос всей памяти в отдельные модули увеличит объём кода в моём текущем проекте в несколько раз. Да и не хочется мне заниматься этими побочными задачами в ущерб основным - реализацией целевых алгоритмов.

 

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

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

 

Я предпочитаю ставить примитивы памяти прямо из библиотек без всяких визардов. Или параметризованные функции, если такие имеются. Визарды, это последнее из вариантов, как получить описание памяти (описать на HDL в слабой надежде на auto-inferring вообще не вариант, это применяется только для моделирования, а помнить все coding style для всех видов синтезаторов и помнить все их взбрыкивания совсем нет желания).

Я тоже когда то начинал с примитивов. Мало того, у меня было несколько версий кода - чистый hdl для симуляций и hdl с примитивами разных семейств для синтеза. Но практика показала, что затраты на их использование слишком велики. И вот уже несколько лет успешно использую исключительно языковое описание - всё замечательно синтезируется. Что касается coding style-а, то довольно естественным образом он во многом совпадает у XST и Квартуса, что покрывает 95% моих потребностей (к примеру, за последние 2 года я не сталкивался с дополнительными проблемами при описании памяти). Поэтому Ваши множественные сообщения про ужасы синтеза памяти из языкового описания вызывают у меня как минимум лёгкое недоумение: какое-то "перекручивание адресов" и прочие страхи для неокрепших умов. В результате эти неокрепшие умы будут заняты освоением всяческих визардов вместо того, чтобы понять основные принципы hdl-дизайна.

 

За резкий стиль извините. Про квалификацию, кажется, не я начал. Но задело.

Замнём. :)

Изменено 4 марта, 2014 пользователем o_khavin

[spectr 0]

o_khavin, расскажите же, что такого экзотического (2-, 3-, 10-портовая память?, ассоциативная память?, какое-то уму непостижимое фифо? линия задержки с хитрыми тапами?) потребовало руководство от памяти, что ее прям ну никак-никак нельзя было сделать, сгенерив из мегавизарда и добавив, возможно, простую логику-прокладку для управления? Думаю, это всем интересно.

 

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

[o_khavin 0]

o_khavin, расскажите же, что такого экзотического (2-, 3-, 10-портовая память?, ассоциативная память?, какое-то уму непостижимое фифо? линия задержки с хитрыми тапами?) потребовало руководство от памяти, что ее прям ну никак-никак нельзя было сделать, сгенерив из мегавизарда и добавив, возможно, простую логику-прокладку для управления? Думаю, это всем интересно.

 

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

Конечно же я Вам это не скажу, это конфиденциальная информация.

 

И кстати да, я про прямое использование примитивов уже написал в ответе SMу, попробуйте прочитать ещё раз. :)

[SM 0]

Ваши множественные сообщения про ужасы синтеза памяти из языкового описания вызывают у меня как минимум лёгкое недоумение:

Я закончил воевать с этими ужасами примерно тогда, когда первый квартус только планировался к выходу, но еще не был рожден, работали в max+plus (ПЛИС) и synopsys DC (БМК), и больше к их изучению не возвращался. Воспоминания именно такие - что автоинферринг памяти это некий глючный процесс, сопровождаемый непременными ритуальными танцами с бубном. Может быть сейчас с этим дела лучше обстоят. Дальнейшая же работа показала, что надо делать именно так, как я писал - память в виде отдельных модулей, для симуляции можно написать модуль на HDL (наверное, и синтезировать с ним же можно, если с этим действительно сейчас все прямо совсем ОК), а для синтеза подключить конкретный блок памяти от конкретной технологии.

 

Однако, несмотря на все "качества" HDL-инферринга памяти, ТС же нарвался на проблему с описанием памяти на HDL! И пришлось ему бубен в руки брать, чтобы результат синтеза моделироваться начал как надо... С использованием примитивов/мегафункций/визардов таких проблем нет априори, и траты времени на них нет. А вот увеличение кода тут да, бесспорно, налицо. Но это же ради удобства и уменьшения проблем в будущем...

[o_khavin 0]

Я закончил воевать с этими ужасами примерно тогда, когда первый квартус только планировался к выходу, но еще не был рожден, работали в max+plus (ПЛИС) и synopsys DC (БМК), и больше к их изучению не возвращался. Воспоминания именно такие - что автоинферринг памяти это некий глючный процесс, сопровождаемый непременными ритуальными танцами с бубном. Может быть сейчас с этим дела лучше обстоят.

А я как раз перешёл от использования примитивов в то время, когда даже родные синтезаторы производителей стали адекватно синтезировать память из языкового описания. :)

 

Дальнейшая же работа показала, что надо делать именно так, как я писал - память в виде отдельных модулей, для симуляции можно написать модуль на HDL (наверное, и синтезировать с ним же можно, если с этим действительно сейчас все прямо совсем ОК), а для синтеза подключить конкретный блок памяти от конкретной технологии.

А я как раз намаялся с поддержкой модификаций одного и того же кода и поэтому то и отказался от такого подхода. Но тут уже каждый сам выбирает. Я просто обращаю внимание, что сейчас детские болезни синтезаторов уже вылечили. Понятное дело, что есть ограничения, но для того и coding style, чтобы их знать.

 

Однако, ТС же нарвался на проблему с описанием памяти на HDL! И пришлось ему бубен в руки брать, чтобы результат синтеза моделироваться начал как надо... С использованием примитивов/мегафункций/визардов таких проблем нет априори, и траты времени на них нет. А вот увеличение кода тут да, бесспорно, налицо. Но это же ради удобства и уменьшения проблем в будущем...

Что касается проблем ТС-а, то видится мне, что они лежат в плоскости нежелания сделать корректный сброс в своей схеме. Мы уже пару-тройку раз перетирали по поводу разных подходов к этому вопросу. :) Но что характерно, с моим вариантом работают любые версии - хоть оригинальный код, хоть post-код с любой стадии. Единственный раз, когда у меня были проблемы, был связан с индусской ошибкой в одном из библиотечных примитивов Xilinx-а - какой-то вариант FF-а уходил в вечный Х от любого Х-а на входе ( не зависимо от последующих корректных данных).

Изменено 4 марта, 2014 пользователем o_khavin

[SM 0]

Что касается проблем ТС-а, то видится мне, что они лежат в плоскости нежелания сделать корректный сброс в своей схеме.

 

Вообще-то, возвращаясь к теме, одной из проблем, кроме резета, было переворачивание адреса кверх ногами при описании блока ROM при помощи HDL, если внимательно читать... Которую ТС успешно устранил (предварительно создав ее себе описанием памяти на HDL), изменив направление следования индексов при описании массива памяти (а это уже танец с бубном).