Vadim

Неужели еще непонятно? Баги, отсутствующие в 2005 и кишащие в 2007.

Дело не в багах и глюках, а в их количестве. Количество багов в 2007.x не соответствует устоявшейся репутации ментора, как ведущего игрока на рынке софта для ПП, это скорее уровень open source. А позвольте спросить, чем баг отличается от глюка? :) Вот именно. Можно было спокойно работать.

Да-да, не смотрят, но такого коня можно на переправе и поменять :) :bb-offtopic: Имхо, количество багов с выходом 2007 и его клонов в несколько раз превысило все разумные пределы и продолжает расти. Старые баги, вылеченные в текущем релизе, неожиданно проявляются в следующем. Появляются даже мегабаги в модулях, традиционно отличавшиеся довольно безглючной работой еще со времен Very Best. Риск потерять как минимум несколько часов (дней?) работы, восстанавливая рухнувшую библиотеку или проект, растет. По моим оценкам, максимально допустимый релиз для более-менее комфортной работы - 2005.3. Выхода два - откатиться назад (долго и больно) или надеяться на лучшее (маловероятно). Впрочем, есть еще третий выход. Но про коней не будем :)

Ага. А потом начал понимать, но не все. А потом - все. Последние события наводят на мысль, что пару буквочек в следующем релизе сломают и SR зарегистрируют Не, на самом деле разговор идет о редакторе плат, в DC/DV по поводу букв все пока в порядке (тьфу-тьфу-тьфу).

Ну и хорошо :) ЗЫ А вообще прикольно. Все ведь работало, но выпустили релиз (2005.1 или 2005.3), сломали и ввели в базу DR...

Большое подозрение, что они об этом ничего не знают :)

Надо признать, едитра кривовата. Под линуксом сломали диалог настроек, который прекрасно работал в прошлом релизе. Плюс невозможно в диалоге открытия выбрать скрытый файл или папку. Облом.

И Editra подтянулась :) Уже пару дней как обрелизилась. Убрали баги со сворачиванием/разворачиванием окна и запоминанием последнего положения. И это хорошо, ибо раздражало. Пишут, что в линукс убрали баг с обновлением окна codebrowser. Но пока не проверял. Плохо, что по-прежнему не понимает два монитора - упорно разворачивается только на основном :( ЗЫ Ну а по поводу слика - лучше него может быть только новый релиз слика, что мы и имеем. С нетерпением ждем его появления в известном месте :) ЗЫЫ едитру подружить с линукс удалось, нужно было, оказывается, поставить волшебную галочку в настройках "Отключить отчет об ошибках". А вот со сликом беда - изумительная под винду прога под линуксом превратилась в какое-то чудовище и вообще отказывается работать. Постоянно ругается на какие-то файлы :(

И не мудрено. Где-то вычитал, что emacs имеет два режима работы - в первом он бибикает, а во-втором все портит :) Сам я его увидел вживую впервые совсем недавно, при попытке перехода на линукс. Пробовал даже выполнить туториал. Пальцы ломаются и мозги выворачиваются :) Понимаю, что круто, мощно, старо, религиозно и все такое. Но нафига он юзеру, привыкшему к виндовым редакторам с их дружелюбием к начинающим? Ведь при всей его мощи, как ни крути, недостаток у него имеется - невозможно начать работу, не изучив его. Не знаю, сколько это займет времени. Скорее всего, много :) А в упомянутых в топике редакторах можно начать работать в следующую минуту после установки :) Имхо.

Вид->Просмотр кода

1. Круг замкнулся :) 2. Ну если все настолько серьезно, ищи тогда уж IEEE1076-2008. Новый стандарт, принят недавно :) Как найдешь, не забудь его здесь выложить :) 3. Ни фига себе, для импорта файла со списком цепей в отмороженный ИОД ты собрался учить VHDL??? А примера, что я тебе давал, недостаточно?

1. В любом текстовом редакторе. Вообще-то, по замыслу иописателей, Вы должны получить файл у его разработчика. 2. Этих документиков много. Чтоб не мелочиться. можно почитать, например, IEEE Std 1076-2002. Очень увлекательно :) 3. Для начала чего?

Подружить его с SUSE 11 мне не удалось. Глючит, окна размножаются и кричит о какой-то ошибке. Обидно, блин, под виндой все нормально. Я новичок в мире линукс, может еще и разберусь.

Бесплатный достойный внимания текстовый редактор: http://editra.org/ Приятно удивило, что язык System Verilog в нем имеется по умолчанию и он умеет распознавать функции. Больше ничего не знаю, глубоко не копал.

Я тоже :) Поэтому подобные ноги делаю неэквивалентными. Тут много подходов. Первый Вам озвучили выше. Как вариант, можно не делать ноги шины эквивалентными, уповая на то, что распутывать будем там, куда эта шина приходит (на ПЛИС, например) или плюнуть на это дело, пускай пакет переназначит номера, зато работать будет комфортно. И по завершении проекта символ ОЗУ заменить на "правильный", а цепи, подходящие к пинам шины, переименовать врукопашную на основании имеющейся разводки.

А я по началу думал иначе :)

Я тоже так поступаю. А если не хватает ног и приходится использовать ноги двойного/тройного... назначения, ничего не попишешь, вручную на схеме меняю провода, к ним подходящие. Не использую иод и никому не советую - абсолютно бессмысленная примочка.

Нет, переставятся только пиннумберы. Пиннэймы останутся прежними. Ну не меняет он расположение пинов!!! У конкретного пина меняется только один из ез его атрибутов - пиннумбер. И точка :)

Удобочитаемость схемы - дело рук создающего схему :) После свопа номера пинов поменяются, и всего делов.

Давайте лучше поговорим о разработке печатных плат в моделсиме :)

:) Я попытаюсь запомнить :)

1364-2005??? Ищу, пока не нахожу :crying:

Ой... Я какой-то неправильный стандарт курю, оказывается. IEEE 1800-2007. Там вообще не упоминается generate_loop_statement. Подскажите, пожалуйста, какой стандарт нужно курить? ЗЫ У меня в наличии есть: IEEE Std 1800-2005.pdf; IEEE_1800-2007.pdf; SystemVerilog_3.1a.pdf или еще какой?

Издеваетесь? :) Там ведь или есть: Если module_or_interface_or_generate_item, то никаких бегинэндов даже не упоминается. А вот если { module_or_interface_or_generate_item }, тогда бегинэнды нужны. Разве always_ff @ (posedge clk) sgnl[i+1] <= sgnl не самый натуральный module_or_interface_or_generate_item ?

Понятно, спасибо :) Следующий вопрос. Почему квеста отказывается компилить это: genvar i; generate for (i=0; i<n; i++) always_ff @ (posedge clk) sgnl[i+1] <= sgnl[i]; endgenerate Говорит, мол В результате вынужден применять "слова-паразиты": genvar i; generate for (i=0; i<n; i++) begin always_ff @ (posedge clk) sgnl[i+1] <= sgnl[i]; end endgenerate Я уже догадываюсь, кто неправ :), но почему? Ведь согласно стандарту: , где Спасибо.