dxp

Во-первых, надо использовать готовые блоки, где возможно. Во-вторых, не надо путать. У ПЛИС и МК абсолютно разные области применения. Естественно, глупо делать проект на ПЛИС, если его возможно сделать на МК. Однако есть масса вещей, которые на МК сделать в принципе невозможно (по скорости) либо нецелесообразно (например, специализированные вычислители). Попробуйте-ка хотя бы DCT сделайте на МК, поглядим, какая скорость получится. Потом, я сталкивался с тем, что у МК не хватает выводов и/или их нагрузочной способности. А ПЛИС есть любые, сейчас уже за 1500 выводов перевалило. Все зарубежные специалисты, с которыми мне удалось поговорить на форумах, говорят, что будущее как раз за ПЛИС с погруженными функциями. Т.е. МК, а вокруг - поле ПЛИС. В ASIC останутся только топовые процессоры etc. А по поводу тяжелого нудного RTL-проектирования - это Вы, видно, под ASIC ничего не делали. ПЛИС по сравнению с ASIC - рай. <{POST_SNAPBACK}> Осмелюсь предположить, что отквоченая Вами цитата - это легкий стёб, не более. Никто со сказанным Вами не спорит, это была шутка, только и всего... :)

Как это не найти? Открываем "Max II Device Handbook", Table 5–3. MAX II Device Programming/Erasure Specifications, в ней черным по белому написано Erase and reprogram cycles 100 Cycles. Что еще надо? Т.е. 100 раз гарантируется, про остальное ничего не сказано. Хм, так а Альтера этого и не скрывает. Прямо и говорит, что макс2 - это архитектурно фпга Циклон без блоков памяти, без триггеров в элементах ввода-вывода и со встроенной флешью, которая является и хранилищем прошивки для конфигуратора, и пользовательской ПЗУ на 8 Кбайт. Все предельно ясно, ни очем догадываться не нужно. Предполагается, что сбоев при конфигурации не бывает. А если они есть, что девайс нерабочий. Наличие внешних сигналов у фпга обусловлено тем, что, во-первых, внешний загрузчик должен как-то интергироваться с ПЛИС, во-вторых, связи, по которым идет конфигурационный обмен, выполняются внешними по отношению к ПЛИС средствами и фирма-производитель ПЛИС никак не может влиять на их качество - в этой ситуации наличие контрольных сигналов просто необходимо для слежения за ситуацией. В случае внутреннего загручика и всех эти связей такой необходимости нет - их качество достаточно для надежной работы ПЛИС. У Вас ведь не вызывает вопроса, что, например, у флешового МК Вы не можете ослеживать сбои при выборках инструкций из внутренней флеши? Вы тут просто верите "на слово", что данный МК при выборках сбоев не имеет (или имеет их с вероятностью очень малой величины). Так и здесь. А то, что архитектура у него фпгашная - это очень хорошо. Грузится он очень быстро - так, что выходит в режим работы даже быстрее, чем классические аналоги (тот же макс3000), триггеров получается много - раздолье для синхронных дизайнов. Лично мне не нравится в них по большому счету именно то, что убрали триггеры из элементов ввода-вывода. Да и память не помешала бы. Хотя бы один блок оставили на развод. А так девайсы гораздо более продвинутые, нежели классические максы и их аналоги.

Давайте не путать две вещи: 1) данные, приведенные фирмой в документации; 2) объективная реальность, проявляющаяся в случайном распределении параметров в пределах, заданых в доке. То, что фирма пишет в доке - это то, что фирма гарантирует. Если написано, что циклов, к примеру, мининмум 100, типично 1000, то 100 раз ЛЮБАЯ микросхема ОБЯЗАНА перешиться, 1000 - это количество, которое перешивается среднестатистическая микросхема. Т.е. получается как раз, то о чем все говорят - что у нас, де, уже точно больше 100 раз перешилось. Да, так и должно быть. Но могут попадаться микрухи, которые перешьются только 100 (возможно, 100 с небольшим) количество раз. Как и то, что может попасться экземпляр, который и 2, и 3 тысячи раз перешьется. Все это надо иметь в виду. При организации процесса разработки и производства (где, к примеру, предусмотрен этап тестирования с зашивкой разлиных тестовых прошивок). Только и всего. И если написано, что up to 100, т.е. ДО 100 раз, то это означает, что ОДИН раз точно зашьется (а иначе зачем вообще такая микруха), а дальше как повезет - в принципе и до 100 раз может. В реальности, конечно, микруха шьется десятки раз - у меня в прошлом проекте EPC2 была прошита примерно десятка два раз и ничего, живая. Что касается флеши и количества циклов, то это вещи слабо связанные. Флешь - это подкласс EEPROM, характерной особенностью которого явяется то, что архитектура ячейки у него такая, что нельзя стереть произвольную ячейку, а только блок целиком. За счет этого ячейка получается проще и плотность выше. К количеству циклов это прямого отношения не имеет, что и показывает практика. Когда появились первые флеши еще от Интела - i28Fxxxx, там давалось количетсво циклов - 1е6. У Атмела позже шли флеши с количеством циклов 1е3, сейчас, вроде, уже 1е4 и даже 1е5 дают. У ТИ в MSP430 минимальное количество 1000 циклов, типовое 10000. А у TMS320F28xx, тоже ТИшная микруха, минимальное количество 100, типовое 1000. Вот такие отличия. А везде, вроде, флешь.

Да нет там никакой хитрости, собираешь второй байтбластер и вперед :) <{POST_SNAPBACK}> Зачем это еще? Все прекрасненько делается байтбластеромМВ. Им: 1) конфигурируется Циклон; 2) производится отладка (через СигналТап); 3) зашивается конфигуратор. Все это делается через один и тот же разъем, подключенный к JTAG ПЛИС. Как делается 3-й пункт - см an370.pdf.

А как это сделать? В документации этого не нашёл. Есть какая-то хитрость или я не там смотрел? Читал Cyclone Device Handbook, август 2005 <{POST_SNAPBACK}> У Альтеры на сайте есть аппкликуха an370.pdf. Там все подробно и внятно расписано.

ENOB -ENOB'ом, но ведь есть еще oversampling. За счет этого разрешение можно вполне поднять. Кому-то, может, и этот вариант пойдет.

Альтернативы уже озвучили. Это либо кульный раннер, либо второй макс. Добавлю только, что по потреблению есть такой нюанс: в статике раннер кушает несравненно меньше второго макса, который суть FPGA. Но вот с ростом частоты потребление у раннера растет значительно быстрее, чем у макс2. И по эффективности кода макс2 может оказаться предпочтительнее - там и триггеров богаче, и ресурсы разводки обширнее. И по цене на объеме ячеек под полтыщи раннер (как и первые максы) выглядит не очень привлекательно. Т.ч. выбор очень сильно зависит от 1) объема проекта; 2) реальной тактовой. При небольших значениях этих параметров рулит раннер, при увеличении - макс2.

Только надо иметь в виду, что Ривьера - это чистый симулятор. Как Моделсим. Т.е. там нету никаких средств для запуска синтезаторов и прочих тулзов. И даже понятие проекта там совсем другое, более простое. Просто коллекция файлов, которая компиляется в библиотеку. И редактор там победнее будет, нежели в Активе. Т.ч. Вас тут может ожидать разочарование. С другой стороны, есть редакторы не хуже Активовского - тот же SlickEdit. А Синплифай запускать отдельно совсем несложно. И даже вполне удобно у него в версиях 8.х сделано окошко с сообщениями - сортировки, группировки, фильтры, цветовая раскраска. И главное преимущество, имхо, у Ривьеры - это скорость как моделирования, так и отображения waveform'ов - на здоровенных Актив заметно подтормаживает, в то время как Ривьера вообще без тормозов. И более широкая поддержка языков - даже СистемВерилог как-то умеет (а Актив 6.3 нет). В общем, следующий проект буду плотно на Ривьере лабать - мне и в Активе-то только симулятор и был нужен. А Ривьера как раз именно симулятор. Почти полный аналог Моделсима (только интерфейс у нее не такой угрюмый :) ).

Помоделировать-то можно. Только условностей много. Регистров мало, скорости другие. И потом объемы в максах совсем не те, чтобы возникали большие проблемы с моделированием - ПЛИСки-то мелкие. Сам лично с максами почти не работал - не показались. Сразу засел на FPGA (тогда это были FLEX8000).

Дык вот и я думаю, что какая разница для регистра, как получен адрес - путем полной загрузки литералов или путем модификации указателя. Но ведь факт! А к обычным объектам все нормально, никаких проблем. Отслеживает именно обращения в ту область памяти. Можно, конечно, обмануть - сделать функцию в другом файле и передавать туда указатель на структуру и параметры. Тут уж он никак не сообразит. :) Но гложет сомнение, что что-то не понимаю, что какой-то нюанс есть. В доке не нашел инчего, вот и спрашиваю. А то, что на асме у них так и так попадается, так может это и ошибка - люди же писали. А примеры - на то и примеры, что ответсвенности за них никакой нет, поэтому особо никто там не приглядывался, работает как-нибудь, и ладно. Может, думаю, в саппорт написать. Только если он у них там весь индусский (как у Альтеры), то скорее всего будет тухло. То ли дело у IAR'а саппорт... :)

Когда ПЗУха его ("перемычки", типа, которая задает) изнасилуется, верификация проходить не будет. Либо он стираться до конца не будет, либо прошиваться. Кстати, тут может пройти такой вариант - если не стирается до конца, делать несколько стираний - за несколько он может "дотереться". :) Аналогично и с зашивкой. Но это уже посторонний вариант - микруха если сдохла, надо менять.

Обнаружил интересную вещь. К примеру, пишу код, инициализирующий какое-нить периферийное устройство или DMA. Там регистры, относящиеся к устройству, лежат рядышком. Из чего, вроде бы, следует, что компилятор при последовательных обращениях должен оптимизировать код - не загружать при каждом обращении полный адрес. Т.е. однажды загрузил базовый адрес и ко всем остальным переменным (регистрам) обращаться со смещением. Экономия кода (да и по скорости выигрыш), как грицца, кардинальный. На деле выходит не так: допустим, есть пять присваиваний значений в регистры MDMA, и все пять раз при каждом присваивании грузится полный адрес, т.е. дополнительные две команды каждая по 32 бита. И так, и сяк, не дается - все равно генерит этот громздкий код. (Оптимизация включена максимальная по скорости.) Ладно, думаю, обману. Создал тип структуры, соответствующей фрейму памяти, где эти регистры расположены. Далее в коде создаю указатель на такую структуру, присваиваю ему насильно базовый адрес блока регистров. Ну, думаю, теперь никуда не денется - явно код прямо написан с загрузкой адреса в указатель и обращением к членам структуры (со смещением, то есть). Но не тут-то было. Код после компиляции ровно такой же: компилятор "не поленился" вычислить абсолютные адреса в каждом случае и честно их прописывать в укзатель с последующим обращением непосредственно по адресу назначения. Вот, думаю, засада! Что же это за оптимизирующий компилятор такой?! Тупит жестоко... Но чувствую, что что-то здесь не то - в первом случае еще можно списать на тупость, но во втором-то он намеренно делает эту "деоптимизацию". Взял попробовал создать объект этой структуры в обчной памяти - все ништяк, оптимизирует, как положено: базовый адрес и далее вперед по смещениям. А вот когда лезешь в область MMRs, не канает. Ведь просек же и адрес, и код сгенерил соответствующий. Вопрос: я чего-то не понимаю, может где-то сказано, что надо всегда грузить в регистр-указатель полный адрес и только потом обращаться? Не заметил никаких ограничений на способ доступа к MMRs. Вполне понимаю, что там не все так просто, что из-за конвейера там всякие побочные эффекты могут лезть, что надо при этом всякие csync'и и ssync'и юзать. Но про способ адресации ничего не нашел. Объясните непонятку, кто знает.

У нас был случай, когда от множества перепрошивок сдох макс7000. Проявлялось это в том, что он перестал прошиваться - на верификации лажался. Дальше уже не проверяли - кому интересно. :(

Эта схема очень сильно похожа (настолько сильно, что ею и является :) ) на сверхрегенеративный каскад. У этого каскада вся работа идет на пороге генерации. Сделано это специально - такие штуки используют для дешевых радиопримемопередатчиков. Имхо, в качестве ГУН она не слишком хороша. Когда-то делал ГУН на основе схемы генератора Колпитца. Вполне успешно. Схема описана в ХиХ.

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

EPCSx в ST'ном исполнении стОит нынче чуть более четырех баксов. При использовании с Циклоном можно ее шить через Циклон же, т.е. используя его JTAG, что есть очень удобно - один разъем и на загрузку, и на отладку, и на программирование конфигуратора.

Основной смысл кооперативной ОС - экономия ресурсов (когда их нет или когда их мало и не хватает для реализации целевой функциональности). Если ресурсов хватает, вытесняющая ОС - самое оно. Какой смысл иметь их обе сразу лично мне не понятно. Объясните, пожалуйста? Не могли бы Вы дать точную ссылку?

EPCSx предполагает Active Serial режим, т.е. тактирование ей надо снаружи. А ACEX, насколько помню, может только Passive - т.е. в тех самых EPCx внутри еще и тактовый генератор есть. Есть вариант на атмеловских AT17C512 и старше - в них есть генератор. Правда, они не особенно дешевые, но может Вас устроит. Еще народ извращался путем применения пассивого конфигуратора с подачей клока снаружи. Вроде работало. P.S. Лучше всего, конечно, переползать на более новые и приятные микрухи - Циклоны, к примеру. Если, конечно, это возможно. :)

Я начал с моделсима. Все бы ничего, да невозможно нормально просматривать сигналы в waveform. При нажатии стрелочек (найти следующее/предыдущее значение сигнала) моделсим "думает" в течение вплоть до десятка секунд (это на моем конкретном проекте - более-менее полной статистики его поведения у меня нет - предполагаю что по мере усложнения моих проектов время будет увеличиваться) И не дай бог нажать стрелочку, если следующего изменения сигнала нет - он просто зависает. Перешел на Aldec. Там в этом плане все пристойно. Сейчас мечусь между алдеком и моделсимом, склоняясь к алдеку. <{POST_SNAPBACK}> Кста, в Ривьере (опять же по сравнению с Активом) зум на здоровенных (длинных) диаграммах происходит вообще без торомозов. Что есть большой плюс.

У меня правда Verilog, а у Вас, видно, VHDL. Может там какие-то нюансы есть с заданием типов и целых, с этим не работал, подсказать ничего не могу.

Это откуда такие сведения? Ваше заявление на фоне заявлений самого Альдека про характеристики данного продукта и его позиционирование выглядят как минимум странно. От себя замечу, что моделирование в Ривьере происходит значительно быстрее, чем в самом Active-HDL'е. Его тоже студенты пишут? Ривьера (в сравнении с Активом) выглядит всяко как более продвинутый продукт - она и быстрее, и организация базы данных с результатами моделирования у нее более продумана, и всякие SystemVerilog'и поддерживает (а Актив, почему-то, нет). Интерфейс у нее более расчитан на скрипты и макросы, т.е. на бОльшую автоматизацию (хотя в Активе тоже это есть, но там многое кликаньем мышкой можно делать, что привлекательно для начинающих). Т.е. меньше рюшечек, больше мощи.

А чего про нее знать. Она вся закрытая из себя, к сорцам добраться крайне трудно. По характеристикам (дему брал) оценивал в сравнении с uC/OS-II - пошустрее она немного (embOS) и футпринт, вроде, чуть поменьше. Уже подробностей не помню, давно было.

А, понял - Вы имеете в виду, что вешается это на отдельный банк адресного пространства? У черного фина немножко другие сигналы и терминология, соответственно, отличается. Насколько понял, идея такая: внешнее устройство происит у проца шину, проц предоставляет, после этого по этой шине рулим флешкой как нужно. В общем, это, имхо, в смысле организации аппаратной части не очень отличается по идеологии от программирования флеши через ейный JTAG. С одной стороны, конечно, гибкости побольше и флешь с JTAG'ом не нужна. С другой стороны все-таки допольнительная микруха и разъем. Хоцца все же без дополнительных аппаратных элементов, только через штатный JTAG проца (девайс малогараритный и есть ограничения по потреблению, поэтому все лишнее тут небесплатно) и штатным эмулятором, который все равно есть... Лана, понятно, бум думать, пробовать дальше. :)

Удобно иногда для буферов сообщений того же Ethernet. Понятно, что можно обойтись, но просто удобно, не приходится очередные велосипеды изобретать. А не будет ли для буферов сообщений удобнее очереди использовать? Многозадачность добровольного типа, не вытесняющая, она же кооператив. <{POST_SNAPBACK}> Как это? Вытесняющия и кооперативная ОС в одном флаконе? Одновременно работают? Что-то не понимаю как это и, самое главное, зачем?

А для каких применений Вам нужны счетные семафоры? Я понял, Вам их не хватает. А зачем она? От нее, имхо, только неоднозначность в работе. В каком кооперативе?