[maior 0]

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

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

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

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

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

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

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

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

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

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

[o-henry 0]

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

 

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

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

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

[maior 0]

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

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

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

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

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

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

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

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

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

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

Изменено 12 мая, 2006 пользователем maior

[andrew_b 15]

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

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

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

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

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

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

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

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

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

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

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

[Golikov 0]

Гн.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 знака по прежнему отделены запятой:)...

[snedelko 0]

to Golikov A.

 

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

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

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

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

[Golikov 0]

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. меняя битность можно менять и диапазон, и точность чисел.

 

 

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