Комментарии 16
Заголовок вызывает как минимум недоумение.
Всё же программист МК работает на Си с библиотекой, предоставляемой через VPI и по-хорошему для него FPGA-side это BlackBox, с которым он взаимодействует через вызовы $get/&set и проч.
Всё же программист МК работает на Си с библиотекой, предоставляемой через VPI и по-хорошему для него FPGA-side это BlackBox, с которым он взаимодействует через вызовы $get/&set и проч.
Подход интересный для того, чтобы «показать заказчику». Простите, но не более того.
К примеру, Вы не можете учесть того, что происходит в обработчиках прерываний и того, как, к примеру настроены таймеры. В свою очередь, это оказывает влияние на временные параметры. Для насоса, который включается раз в сутки, это не существенно. А вот на более коротких промежутках времени могут возникнуть проблемы.
«как бы несколько мало пересекающихся миров». С этим Вы погорячились. Например, посмотрите в сторону SoC/softprocessors: Xilinx Microblaze тому подтверждение, да и практически у каждого вендора FPGA есть подобные решения. При таком подходе Вы можете разрабатывать high-level части на C/C++, а критичный low-level на VHDL/Verilog.
К примеру, Вы не можете учесть того, что происходит в обработчиках прерываний и того, как, к примеру настроены таймеры. В свою очередь, это оказывает влияние на временные параметры. Для насоса, который включается раз в сутки, это не существенно. А вот на более коротких промежутках времени могут возникнуть проблемы.
«как бы несколько мало пересекающихся миров». С этим Вы погорячились. Например, посмотрите в сторону SoC/softprocessors: Xilinx Microblaze тому подтверждение, да и практически у каждого вендора FPGA есть подобные решения. При таком подходе Вы можете разрабатывать high-level части на C/C++, а критичный low-level на VHDL/Verilog.
Дело в том, что несмотря на заключенный договор о разработке устройства и несмотря на наличие более-менее согласованного ТЗ на устройство так получилось, что каждую неделю заказчик приходил с новыми идеями, требованиями, мыслями и пожеланиями.
…
Причем заказчик сам не был уверен, как оно должно работать и даже не очень понимал, как он будет все это проверять. Точнее будет сказать так. Есть менеджеры которые хотят иметь некий контроллер в свой агрегат. Какие конкретно функции должны быть у контроллера и агрегата сами менеджеры точно не знают и требования должен был сформировать единственный инженер, который и должен был проверить работоспособность устройства. Своей методики проверки работоспособности контроллера у инженера нет, так как нет опыта работы с электронными устройствами.
Иногда ко мне обращаются друзья с просьбой «помочь сделать сайт». Фактические сайт сделать надо. Заказчик не знает с какой стороны к нему подступаться и что хочет получить в конце. ТЗ худо-бедно согласованное. Разработка, дизайна. Куча правок. Верстка. Куча правок. Вообщем сайт как-то рождается. Ну и этот итерационный процесс воспринимается как-то нормально, несмотря на то что в конце получается всегда не так как в первоначальном ТЗ (то то не нравится, то другое, то третье, то озарение, то прояснение, то протрезвление т.д. и т.п. — короче, рабочий процесс).
Но такой же подход к разработке электроники. Жесть! Я сам занимаюсь разработкой на ПЛИС. Это моя основная работа. Тружусь я в неочень частной конторе. С ТЗ у нас нормально в том плане, что оно мне спускается от спецов такого же уровня компетентности что и я или выше. И то, когда через пару месяцев выясняется что в ТЗ что-то подвинули, то начинаются небольшие перебранки. Да даже если в протоколе какие-то изменения — это надо переделывать интерфейсные модули в прошивке, на ответной части приемник корректировать, проверять, тесты менять. А если такое каждую неделю — да я б повесился!!! )))
С другой стороны, такой подход имеет место быть — это техсогласование с целью написания ТЗ. Но у вас уже вроде ТЗ было какое-то… И вот так по нему людей напрягать, а потом оказывается не так, а потом не то… Это потом проще заново сделать, т.к. общий дизайн прошивки поломается и уже не будет так красив как изначально задумывалось, т.к. будет куча костылей. Да и модули отдельные переделывать постоянно тоже не лучшее решение, т.к. все равно когда-то что-то упустишь и будешь потом долго отлаживать)
Кстати, с марсоходом дело имел, но было так себе — от нечего делать) Проект интересный, на его базе хотели даже кружок сделать, но незадалось, к сожалению.
По моему мнению и опыту, который я имею — FPGA это либо для тех у кого не будет продукта(студенты, экспериментаторы), либо для тех кто делает реальный чип и отлаживается на FPGA(для ASIC), либо для тех кто ни те и ни те, и последних я боюсь больше всего, они обычно и используют МК + FPGA.
Да, только если требуется специфичный контроллер, который должен выдерживать строгую времянку, и при этом серия производства конечной аппаратуры мала, то CPU + FPGA очень даже годное решение. Чаще всего можно обойтись только FPGA, используя тот же MicroBlaze внутри ПЛИС. Сейчас же производители FPGA предлагают более вкусный вариант, в котором совмещены CPU и FPGA (например, ZYNQ от Xilinx).
Хех. Да как сказать. Весь космос и добрых 3/4 авиации сидят именно на ПЛИСах.
А куда деваться, если вам нужно изготовить, например, с 10ок плат с кучей периферии и требованием делать быстрые вычисления, да еще и независимые по разным каналам? Большое количесвто I/O, возможность параллелльных операций без ущерба производительности, да еще и возможность переконфигурирования в случае доработок — ПЛИС самое то. Продукт же есть и вполне реален. ASIC просто не нужен, т.к. получится дорого и это экономически просто неоправдано. У американцев вон — марсоходы на Virtex4 по Марсу ездят и ничего )))
Причем в некоторых проектах не обязательно же FPGA использовать, иногда достаточно CPLDшек понаставить.
МК + FPGA — да, я теперь по своему опыту скажу гемора там немеряно. Пока отладишься порой много нового узнаешь))) Но иногда деваться некуда. Ибо лучше сделать часть периферии независимой (да и надежнее — вдруг из-за ошибки ПО это процесссор повиснет?), но скоростной. А в процессоре же своя программа крутится, которую гораздо проще менять (а порой и интуитивнее), чем на более низком уровне перекапывать модули на VHDL/Verilog…
А куда деваться, если вам нужно изготовить, например, с 10ок плат с кучей периферии и требованием делать быстрые вычисления, да еще и независимые по разным каналам? Большое количесвто I/O, возможность параллелльных операций без ущерба производительности, да еще и возможность переконфигурирования в случае доработок — ПЛИС самое то. Продукт же есть и вполне реален. ASIC просто не нужен, т.к. получится дорого и это экономически просто неоправдано. У американцев вон — марсоходы на Virtex4 по Марсу ездят и ничего )))
Причем в некоторых проектах не обязательно же FPGA использовать, иногда достаточно CPLDшек понаставить.
МК + FPGA — да, я теперь по своему опыту скажу гемора там немеряно. Пока отладишься порой много нового узнаешь))) Но иногда деваться некуда. Ибо лучше сделать часть периферии независимой (да и надежнее — вдруг из-за ошибки ПО это процесссор повиснет?), но скоростной. А в процессоре же своя программа крутится, которую гораздо проще менять (а порой и интуитивнее), чем на более низком уровне перекапывать модули на VHDL/Verilog…
Да, в нынешней ситуации с отладкой микроконтроллеров можно желать много лучшего. Но я лучше расскажу о своем опыте отладки программ на МК. Все начиналось еще в конце 90х, и инструментальные средства были не в пример нынешним.
Ну, во-первых, симулятор. Проблем у симуляторов две. Первая — их недоделанность. То есть симулируется МК не полностью, некоторая аппаратура не поддерживается. Вторая проблема — взаимодействие МК с внешним миром. Симулятор не симулирует внешних устройств, с которыми взаимодействует микроконтроллер, а эти устройства (например, другой МК) могут вести себя очень сложно, так что от симулятора в такой ситуации проку очень мало.
Что тут можно сделать? Отлаживать программу по частям. По маленьким частям. Проверяешь каждую функцию, исполняешь пошагово, контролируя все аспекты ее работы. При этом в прошивку добавляется много отладочных функций, веток и тестовых данных — фактически, симуляция взаимодействия с аппаратурой ведется средствами МК в той же прошивке. Используются доступные возможности симулятора по «подкидыванию» прошивке данных через внешние устройства и их съема и сохранения в файлы.
Если какое-то событие происходит редко — искусственно увеличиваешь частоту таких событий, чтобы было легче поймать событие и проверить правильность его отработки.
Когда достигнута безупречная работа в симуляторе — переходим к наладке в железе. Как правило, на этом этапе еще остаются ошибки. Чтобы облегчить себе жизнь, снова все упрощаем, используем генераторы простых данных, уменьшаем или увеличиваем скорость процессов. Процедуры, которые при штатной работе вызываются редко, вызываем в цикле, контролируя работу осциллографом.
На некотором этапе может потребоваться внутрисхемный отладчик. Я много лет обходился без него, и все получалось, но однажды пришлось налаживать алгоритм обработки сигнала (распознавание DTMF на аналоговом входе). На тестовых данных все работало, а на реальном сигнале — нет. Нужно было остановить программу в железе в процессе работы и посмотреть ее состояние. Это может только внутрисхемный отладчик. Но обращаться к отладчику рано, если перед этим не были использованы все возможности симулятора. Отладчик медленнее отзывается на команды пользователя, чем симулятор; иногда остановленную программу нельзя продолжить из-за того, что она «проспала» какой-то физический процесс.
И наконец, после испытаний и тщательного анализа всех, каких только можно, частей программы, можно постепенно выбрасывать из нее заглушки и настраивать все на штатные режимы. В процессе по возможности тоже все контролировать. Если вся разработка прошла в описанном выше режиме — то готовый продукт получается очень надежным.
Ну, во-первых, симулятор. Проблем у симуляторов две. Первая — их недоделанность. То есть симулируется МК не полностью, некоторая аппаратура не поддерживается. Вторая проблема — взаимодействие МК с внешним миром. Симулятор не симулирует внешних устройств, с которыми взаимодействует микроконтроллер, а эти устройства (например, другой МК) могут вести себя очень сложно, так что от симулятора в такой ситуации проку очень мало.
Что тут можно сделать? Отлаживать программу по частям. По маленьким частям. Проверяешь каждую функцию, исполняешь пошагово, контролируя все аспекты ее работы. При этом в прошивку добавляется много отладочных функций, веток и тестовых данных — фактически, симуляция взаимодействия с аппаратурой ведется средствами МК в той же прошивке. Используются доступные возможности симулятора по «подкидыванию» прошивке данных через внешние устройства и их съема и сохранения в файлы.
Если какое-то событие происходит редко — искусственно увеличиваешь частоту таких событий, чтобы было легче поймать событие и проверить правильность его отработки.
Когда достигнута безупречная работа в симуляторе — переходим к наладке в железе. Как правило, на этом этапе еще остаются ошибки. Чтобы облегчить себе жизнь, снова все упрощаем, используем генераторы простых данных, уменьшаем или увеличиваем скорость процессов. Процедуры, которые при штатной работе вызываются редко, вызываем в цикле, контролируя работу осциллографом.
На некотором этапе может потребоваться внутрисхемный отладчик. Я много лет обходился без него, и все получалось, но однажды пришлось налаживать алгоритм обработки сигнала (распознавание DTMF на аналоговом входе). На тестовых данных все работало, а на реальном сигнале — нет. Нужно было остановить программу в железе в процессе работы и посмотреть ее состояние. Это может только внутрисхемный отладчик. Но обращаться к отладчику рано, если перед этим не были использованы все возможности симулятора. Отладчик медленнее отзывается на команды пользователя, чем симулятор; иногда остановленную программу нельзя продолжить из-за того, что она «проспала» какой-то физический процесс.
И наконец, после испытаний и тщательного анализа всех, каких только можно, частей программы, можно постепенно выбрасывать из нее заглушки и настраивать все на штатные режимы. В процессе по возможности тоже все контролировать. Если вся разработка прошла в описанном выше режиме — то готовый продукт получается очень надежным.
Хотел бы похвалить компилятор Icarus Verilog. Как-то нужно было промоделировать небольшой проект с применением VPI, а ставить тяжеловесные коммерческие решения не хотелось, и Икарус показал себя с очень хорошей стороны: простота, удобство, какая-никакая документация. Не имея в тот момент практически никакого опыта с Verilog и VPI, за вечер разобрался. Пример хорошего open-source решения.
Попытка использовать любимый инструмент в непрофильной для него сфере удалась) Все, я думаю, понимают, что для отладки МК недостаточно картины «Вход/Выход».
Несмотря на велосипедность, статья понравилась. Единственный совет в вашем случае, который уже давали выше — это использовать либо ПЛИСы с хардовыми процами либо брать RTL процов (благо RTL того же Microblaze кажется опубликован под свободной лицензией ) и зашивать в ПЛИС. В этом случае вы сможите не только алгоритм работы проца просимулировать но и сам проц непосредственно. Удачи.
Что-то я не понял — какая часть из вот этого:
Main.c
Dma.c
Serial.c
Interrupts.c
….
Algorithm.c
в итоге будет протестирована при помощи тестбенча на Verilog?
Main.c
Dma.c
Serial.c
Interrupts.c
….
Algorithm.c
в итоге будет протестирована при помощи тестбенча на Verilog?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Зачем язык Verilog программисту микроконтроллеров