Jump to content
    

Захват ШИМ сигнала...

IEEE может рекомендовать что угодно - они за это зарплату получают.

Но кто сказал, что совместимость проектов и корок - фактор, который

можно игнорировать? Да и старые пакеты тоже были стандартизированы

в свое время и "с производства", как многие микросхемы, их никто не

снимал - пользуйтесь на здоровье!

А переделывать рабочие старые коды только для того чтобы сменить старый

package на новый, прогнуться перед IEEE и поиметь лишние проблемы - по-моему глупо.

Так что дело здесь не в консерватизме, а в целесообразности.

Но с последним Вашим предложением

я конечно же согласен - о чем уже говорил выше.

Share this post


Link to post
Share on other sites

корки от хилых и альтер да используют старые пакеты, но при этом у них есть джентельменское соглашение про то, что в портах ходит ТОЛЬКО std_logic_vector, что позволяет использовать разные пакеты в одном и том же проекте.

 

Весьма интересное и обнадеживающее замечание.

То есть, если в проекте все мои entity используют в качастве портов std_logic_vector, то независимо от того, какие пакеты я использую при описании каждого entity, VHDL код всегда будет переносимым. Я правильно понял?

(естественно, если внутри entity нет vendor specific components)

Share this post


Link to post
Share on other sites

С корками от вендоров оно именно так (более мудрые и прагматичные чем мы позаботились о нас!),

но в других случаях (opencores, etc) бывает очень обидно...

Между прочим, внутри самих корок (моделей) почти не используется

ieee.numeric_std, а вот его подмен (в том числе и расширений - но

опять-таки на базе "старых" пакетов) - сколько угодно. Посмотрите

коды LPM Альтеры (симуляционные) хотя-бы - увидите там ieee.numeric_std

только где математикa. А вообще весь этот спор

не нужен, а нужен совет начинающим: уж если и использовать

ieee.numeric_std - то или неявно, в составе корок со стандартным

"старым" интерфейсом, или очень осмотрительно.

Edited by maior

Share this post


Link to post
Share on other sites

IEEE может рекомендовать что угодно - они за это зарплату получают.

IEEE выпускают стандарт на язык. Стандарт --- это суровая действительность, "истина, данная нам в ощущении". Я думаю, что там сидят неглупые люди...

Но кто сказал, что совместимость проектов и корок - фактор, который можно игнорировать?

Каким образом совместимость ломается?

Да и старые пакеты тоже были стандартизированы в свое время

Когда и кем? Фирма Synopsys выпустила эти пакеты, когда 1076 еще не было. И права на эти пакеты принадлежат ей до сих пор. Если завтра она запретит включение своих пакетов в продукты других фирм, вы ей спасибо скажете?

А переделывать рабочие старые коды только для того чтобы сменить старый

package на новый, прогнуться перед IEEE

Что значит "прогнуться"? Речь идет о соответствии стандарту. Это плохо? По-моему, нет, особенно для начинающих.

Так что дело здесь не в консерватизме, а в целесообразности.

Консерватизм --- это как раз использование нестандартных пакетов. И никакой целесообразности я здесь не вижу. Весь необходимый функционал есть в numeric_std.

Share this post


Link to post
Share on other sites

Гн.Golikov A: первая функция сканирует std_logic_vector "a" от LSB

к MSB и добавляет 2 в степени i к предварительно обнуленному результату "return_int",

если текущий разряд не '0'.

 

спасибо, я просто не очень понял к чему там было умножение, теперь все понятно...

 

На счет того, какого года пакеты, вы правы я не глядел. И если честно я просто выразил свое мнение, и не претендовал на его правильность. Может быть если бы я глубже копал в истории ПЛИС я бы мог авторитетно рассуждать о преимуществах нумерика перед арифмом, но мне деньги не за то платят:) потому делаю как быстрее, и пока получилось со стандартным набором функций что мне предоставил исе 7.1 быстрее:) вот и все.

 

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

 

насчет 1.15 считайте что это 115, но запомните что 2 знака отделены запятой. то есть когда вы захотите 1.15 умножить на 2, умножайте 115 на 2, не забывая про то что 2 знака по прежнему отделены запятой:)...

Share this post


Link to post
Share on other sites

to Golikov A.

 

Пока речь дальше самого понимания этого формата не дошла, то есть умножение-деления.

Объясните вкратце сам формат.

То описание, что я нашел, говорит: ст.бит - знаковый(полагаю, как в дополнительном коде), остальные 15 бит - значение после запятой. Итого диапазон -1:+1.

Ну если 0x7fff (0111 1111 1111 1111) - понятно, что 0.999, то как 0xffff=-0.000031 ???

Share this post


Link to post
Share on other sites

to Golikov A.

 

Пока речь дальше самого понимания этого формата не дошла, то есть умножение-деления.

Объясните вкратце сам формат.

То описание, что я нашел, говорит: ст.бит - знаковый(полагаю, как в дополнительном коде), остальные 15 бит - значение после запятой. Итого диапазон -1:+1.

Ну если 0x7fff (0111 1111 1111 1111) - понятно, что 0.999, то как 0xffff=-0.000031 ???

 

 

что то я не понял про какой из форматов вы говорите.

 

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

 

теперь про число с фиксированной запятой, в другой ветке опять же вам писали, повторю.

 

Берем число разрядности n=16 допустим, считаем что первые 8 бит это целая часть вторые 8 бит это дробная. Это все договоренности и это можно изменить.

теперь берем какое то число, например, 124.01 как оно будет отображаться в нашем формате. Для этого его надо умножить на 2^8 и получим 31746.56, дробную часть убираем, - это погрешность нашего представления и получаем 31746 == 0х7С42. Вот и все, теперь если вам надо разделить это число на 3, просто целочисленно делим 31746/3=10582. и если хотим знать что это за нормальное число, то делим на 256, 10582/256=41.3359375. проверяем 124.01/3=41.336666666666666666666666666667. По моему успех:)...

умножение аналогично.

при сравнениях и суммировании, вычитании, вам придется выравнивать порядки.

Допустим, вы хотите отнять 2, тогда вам 2 надо умножить на 256 получить 512, и это число уже отнимать

31746-512=31234, что в нормальном виде 122.0078125, тут уже меньше успех, но это все от того что на дробную часть мы положили всего 8 бит. Если положить больше будет точнее.

 

отрицательные числа аналогично в обычном дополнительном коде. -15==-3840 == 0xF100.

 

при таком разделении 8/8 мы получили диапазон чисел от -128 до 127.99609375, с точностью 0.00390625. меняя битность можно менять и диапазон, и точность чисел.

 

 

А вообще если честно вы фигней маетесь. Гораздо быстрее было все поправить в ДСП, и реализовать на плисе примеры и проверить как оно все работает, чем обсуждать кучу разных форматов. Для вашей задачи я больше чем у верен арифметика в действительных числах не нужна, и почему в старом проекте от нее не избавились большой большой вопрос...

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...