des00

простите за стиль, тут были IEEE Std 1076 -> IEEE Standard VHDL Language Reference Manual -> 1.1.1.2 Ports -> If a formal port is associated with an actual port, signal, or expression, then the formal port is said to be connected. If a formal port is instead associated with the reserved word open, then the formal is said to be unconnected. A port of mode in may be unconnected or unassociated (see 4.3.2.2) only if its declaration includes a default expression (see 4.3.2). A port of any mode other than in may be unconnected or unassociated as long as its type is not an unconstrained array type. It is an error if some of the subelements of a composite formal port are connected and others are either unconnected or unassociated. рекомендую такие вещи смотреть сначала в стандарте не факт что он выкидывает, возможно что одновременно модернизируется логика выбора канала мультиплексора. ИМХО нужно внимательно прочитать логи синтезатора и посмотреть логику проекта.

простите что вмешиваюсь, но вот тут вы были ? IEEE Std 1364-2001 -> IEEE Standard Verilog® Hardware Description Language -> 17.2 File input-output system tasks and functions -> 17.2.1 Opening and closing files -> file_open_function ::= integer multi_channel_descriptor = $fopen ( " file_name " ); | integer fd = $fopen ( " file_name ", type ); как будто на си никогда не работали. Удачи !!! ЗЫ. обычно когда у меня такие вопросы возникали я в стандарт первым делом смотрел, а не целый день на форуме терял.

Не хотелось бы разводить флуд, поэтому буду краток я полагал что все увидят в моих словах здоровый, экономически обоснованный, сарказм и пропустят его сквозь сито своего мировоззрения. не думал что кто-то воспримет эти слова напрямую. Вы гуру, вам виднее конечно, вопрос темы был простой "Есть ли какие-то преимущества использования ПЛИС по сравнению с микропроцессорами?" без конкретизации области применения. И мой ответ подразумевал следующее : Если есть задача, которая может быть решена на процессоре и при этом будут получены требуемые по ТЗ характеристики (быстродействие, точность, токо-потребление, размеры) то нет смысла реализовывать ее на плис. т.к. в этом случае будет затрачено больше времени на проектирование и отладку програмного обеспечения. Ну москва отдельное государство и живет по своим законам. По моим наблюдениям в томске и н-ске хорошие программисты на скриптовых языках (1C, python) и С#, Java и т.д. требуются на порядок(десятичный) чаще и зарабатывают на пару порядков больше чем фпга разработчики (тут двоичный порядок). При этом ИМХО стать хорошим фпга разработчиком на порядок сложнее чем программистом на скриптовых языках.

ИМХО самое то на opencores или на форум (не знаю есть ли здесь каталог проектов как на сахаре). Продать скорее всего не удастся, а вот реклама еще ни кому не мешала. Удачи !!!

таки решил добавить свои 5 капель работал 3 года с альдеком, но когда он мне гордо заявил что не знает что такое класс и заставил меня день искать проблему его падения из-за меток(!!!), при работе с абстрактными интерфейсам (сам альдек признал эту проблему и сказал подождите месяца 3 следующего релиза), я переполз на квесту. Правда все руки не доходят переползти на VCS. С точки зрения юзер френдли данный продукт сильно проигрывает альдеку ( а что еще ожидать от оболочки на тикле), но с точки зрения поддержки полноты стандарта на SV он сильно выигрывает. Но он и не позиционируется как IDE, it's just a simulator и без умения пользования скриптами он будет только тормозить работу. ИМХО я возможно вернусь на альдек, но не раньше чем что то вроде вот этого assert (std::randomize(delay) with {delay dist {0 := 1, !0 :/ 2};}) else $error ("random delay generate error"); assert ( std::randomize(read_tr_max_num) with {read_tr_max_num inside {[1:sequental_tr_max_num]};} ); class .... constraint cola_constraint { (burst_random_mode != 0) -> (burst == 1) -> (cola[0] == 0); (burst == 3) -> (cola[1:0] == 0); (burst == 7) -> (cola[2:0] == 0); (burst == 15) -> (cola[3:0] == 0); } constraint burst_order {solve burst before cola; } ..... endclass будет им собрано и смоделировано без падений. еще в альдеке напрягало не понимание unique/priprity и fork/join_none Насчет скорости моделирования ИМХО вы просто не умеете его готовить. грамотное использование техни к оптимизации и настроек запуска проекта в моделсиме позволяет сильно уменьшить время моделирования (увеличить скорость моделирования). Насчет удобности работы : берем слик эдит, пристегиваем к нему моделсим - получаем нормальную рабочую ИДЕ, пишем скрипты запуска или батники синтезатора, мапера и прочего и работаем с консоли без каких либо проблем. Удачи !!!

Спасибо, давно так не смеялся %) Вообще то ЯВУ это аббревиатура от Языки Высокого Уровня и это, как вы понимаете, никакого отношения к языку программирования ЯВА (Java), в контексте моего ответа не имеет. по вашей фразе могу заключить что вы либо начинающий, либо сочувствующий (студент пишущий курсовой например) и если вы думаете что контроллеры до сих пор программируются на асме, то глубоко ошибаетесь. Конечно асм используется, но в большинстве своем все делается на Си, Си++ и т.д. вопросы оптимальности ХДЛ кода и его переносимость под любого производителя фпга, обсуждать с вами я полагаю еще рано, предлагаю вам реализовать несколько проектов, под разные фпга и тогда можно будет говорить конструктивно. Удачи!!! ЗЫ. Если я вас чем то обидел, приношу свои извинения :).

кхм, за парту Андазначна (с) Жириновский других слов в эпоху хороших компиляторов с ЯВУ у меня нет. Удачи !!!

кхм, может быть я чего не догоняю // Description : // generate HEC for payload headers. // G(x) = x16 + x12 + x5 + 1, see ITU-T G.7041 Generic framing procedure (GFP) module gfp_crc16 ( clk , reset , sclr , ena , init , ibyte , crc ); // // // input wire clk ; input wire reset ; input wire sclr ; input wire ena ; input wire init ; input wire [7:0] ibyte; output logic [15:0] crc ; // // // wire [15:0] crc_load_value = init ? 16'h0 : crc; always_ff @(posedge clk or posedge reset) begin : crc_register if (reset) crc <= 16'h0; else if (sclr) crc <= 16'h0; else if (ena) crc <= Crc16(crc_load_value, ibyte); end // // // function bit [15:0] Crc16x1 (input bit [15:0] crc, input bit d); bit msb; bit [15:0] crc_next; begin msb = crc[15]; crc_next = crc << 1; crc_next[0] = d ^ msb; crc_next[5] = d ^ msb ^ crc[4]; crc_next[12] = d ^ msb ^ crc[11]; return crc_next; end endfunction // // // function bit [15:0] Crc16(input bit [15:0] crc, input bit [7:0] data); bit [15:0] crc_next; int i; begin crc_next = crc; for (i = 8; i > 0; i--) begin crc_next = Crc16x1 (crc_next, data[i-1]); end return crc_next; end endfunction // // // endmodule

И все тут же ломанулись в фпга, стали хорошими разработчиками и обрушили рынок труда данной профессии. Простите за сарказм :))) рынок труда фпга разработчиков достаточно специфичен и все же малочисленен, тогда как рынок труда ява архитекторов, веб программеров и т.д. постоянно растет, все это еще и накладывается на современные технологии ( та же ява на всех парусах летит в embedded). Никто не спорит что хороший фпга специалист без работы не останется, но пробиться ему сложнее :)) ЗЫ. Банальный поиск вакансий в том же Новосибирске вываливает запросов 40-80 на ява архитекторов с ".. от 60 тыров" и только одного ФПГА разработчика с ".. по договоренности".

вы забываете одну важну вешь : time-to-market. Если ваши конкуренты сделают продукт, пусть и чуть хуже и дороже, на год раньше вас, и качественно себя пропиарят, то цену разработки даже на хлеб намазать будет сложно :))

Всем своим знакомым и друзьям искренне советую : не ввязывайтесь в такое грязное дело как FPGA/HDL разработчик, лучше займитесь явой, 1с, с#, python и успокойтесь, ну на худой конец идите в ДСП/МК программисты. потом после паузы добавляю "ну а если уж не втерпеж, то плодитесь и размножайтесь (с)". Конечно те или иные преимущества зависят от поставленной задачи, но к сожалению очень часто при оценке стоимости решения задачи упускают очень важный момент : человеко-часы. Задача решенная на готовой базе(готовый проц, с интерфейсами, дма, кешами, памятью) с использованием высокоуровневых(относительно высокоуровневых) средств разработки (читай как компиляторов с языка с, с++, макро ассемблеров) всегда будет дешевле, чем задача которая решается на базе программируемой логики. Естественно под задачей я понимаю задачу решаемую на процессоре и под ценой я понимаю стоимость разработки программного обеспечения. Поэтому задача должна быть обсосана с разных сторон и только после этого может быть сделан вывод о том, что именно : проц, FPGA, MPAA, FPOA, в контексте данной задачи имеет преимущество. ЗЫ. как пример из прошлой жизни : разработка видео кодеков h.264 на фпга. Казалось бы вот она мана небесная. Берем фпгу с дикими возможностями параллелизма и легко и быстро делаем видео кодек и гребем бабло. Но что-то нормальных кодеков ( с хорошим качеством) на фпга не видно, зато есть туча качественных кодеков на платформе х86. При этом кодек х86 может разработать пара программистов, а для фпга кодека нужна намного больше разработчиков. И такое положение объясняется тем, что фпга решения интересны именно для реал-тайм ХД, но когда поднимаются вопросы о качестве сжатия и то какими средствами оно поднимается, выясняется что весь фпга параллелизм летит в трубу, чипов требуется штуки 2,4 да и времени на то что бы все это разработать, отсимулять, синхронизовать требуется туча, то решение задачи на 2 гиговом 2/4 головом процессоре с кешем в 8 мегабайт оказывается более экономически выгодным. ЗЗЫ. А с чего это вы вообще задались таким вопросом ? случайно не курсовую/дипломную работу пишете ? Удачи!!!

2 maksya с удовольствием ознакомлюсь с вашими статьями, иногда приятного быть рецензором %)) (ломать не строить). что касается статьи Долинского : мне она показалась пустой и не имеющей большого смысла. Всего лишь слова, поверхностно затрагивающие сути проблемы и пути ее решения. Сложилось впечатление что человек сам не работал с данными технологиями, а надергал общих фраз из различных материалов(причем ИМХО не очень хороших). Те же SVA хорошо и более понятно расписаны в самом стандарте на который он ссылается, причем с примерами и рисунками. ИМХО статья для манагеров, а не для разработчиков. Надеюсь что статья уважаемого maksya, будет более полезна именно разработчикам. Не подскажите "Проектирование на ПЛИС. Курс молодого бойца." в электроном виде где можно взять посмотреть ? хотя эта книга мне показалась слишком поверхностной (может быть потому что читал ее уже после "хдл библии" и кучи других материалов), но думаю начинающим коллегам будет полезна (тем более на русском) Насчет источников рассмотрите еще книгу Ben Cohen, Srinivasan Venkataramanan, Ajeetha Kumari, "SystemVerilog Assertions Handbook for Formal and Dynamic Verification", Vhdlcohen Publishing. К сожалению в моей коллекции ее нет, может быть кто нибудь поделиться ? :)

Не поверите, никогда не пользовался никакими визуализаторами, редакторами диаграмм и т.д. Единственное что делаю так это перевожу структурные схемы разного уровня детализации из рабочей тетради в визио (и то если есть желание). RTL, Structure модули и их интерфейсы стараюсь делать самодокументироваными и самодостаточными, с как можно большим использованием стандартных интерфейсов и механизмов (a ля wishbone, AXI, LocalLink, Avalon). Ну и + правила хорошего тона при написании кода(в том числе комментируй то, что не очевидно). Тогда алгоритм работы, структура модуля становиться понятыми при банальном чтении кода и уходит на это дело не более 5-10 минут (это про себя) . Удачи !!!

ИМХО если есть расчитанные коэффициенты вопрос создания многотактового FIRа дело 1-2 часов, с примитивнейшим тестбенчем на автоматическую проверку импульсной характеристики. Удачи!

Чего играться, переходите на System Verilog и точка !!! Удачи !!!

кхм, вот это http://www.altera.com/products/ip/processo...&WT.oss=ARM лежит на альтере уже почти год (если мне память не изменяет). 200МГц на сыклоне и не пахнет. не знаю архитектуры именно ядра кортекс М1, но если опираться на арм7 то ИМХО один в один микроблейз с 3-х стадийным конвейером (версия 4.х если не ошибаюсь, у более нового 5 ти стадийный конвейер как у ниоса). ИМХО думаю чудес производительности, особено с большим количеством переферии и мастеров, слейвов ждать не стоит. и если я правильно понял на ядре стоит AHB (могли бы AXI сделать). По сравнению с ней Avalon Switch Fabric более гибкая архитектура. ЗЫ. Все вышесказанное ИМХО, гуру поправьте если ошибся

dvladim сказал абсолютно правильно. беру корку с открытым кодом и вытаскиваю из нее алгоритм ее работы, по коду, через симулятор и т.д. Особенно нравится расковыривать микропроцессорные ядра с opencores.

Тема уже обсуждалась но форуме. Все зависит от того, что именно вы понимаете под обработкой изображения. Поясню : если вы отлаживаете код модуля, особенно замороченого (энтропийный кодер например), то тут ИМХО лучше всего либо встроить вызовы к нему в DPI/PLI обертку окружения модуля + логи его работы. Если не получиться то можно озадачиться вопросами построения дампов на входе/выходе софтового модуля и кормления ими аппаратного модуля. Т.е. тут подход тестирования gray-box с golen model в чистом виде. Если же вы отлаживаете систему в целом (например проверяете нет ли артефактов на изображении) то тут имеет смысл просто записать выходной файл и посмотреть его глазами. Как вариант возможна замена DPI/PLI на SystemC. Удачи!!!

таки нашел более менее красивое решение проблемы interface sc #(parameter int iw = 8, ow = 8); function automatic logic [ow-1:0] scale (input logic [iw-1:0] i); if (iw < ow) scale = {i, {ow-iw{1'b0}}}; else // if (iw >= ow) scale = i[iw-1:iw-ow]; endfunction endinterface module pipa(a, b); parameter integer aw = 20; parameter integer bw = 10; input wire [aw-1:0] a; output wire [bw-1:0] b; sc #($size(a), $size(b)) sc (); assign b = sc.scale(a); endmodule PS. Но такое работает только в прецижене. Ква юзерс, даже не смотря на то что в хелпе указано Quartus II Support for SystemVerilog 2005 -> Section 20—Interfaces -> 20.6 Tasks and functions in interfaces : Supported могут не обольщаться %(

кхм, я для таких случаев обертку делал на верилоге, которая в консоль кидала что пришло по уарту и через getc в диалоговом окне отправляла данные. но для верилога на DPI + PLI думаю что можно сделать кольцо на компорт, а на него заглушку. (как делать программные петли на уарт не знаю %() Удачи!!!

либы для альтеры нужно сбилдить. В частности вам нужна либа ovi_altera_mf. для этого я использую скрипты http://electronix.ru/forum/index.php?act=A...st&id=18460 только пути до моделсима введите новые. ЗЫ. запускать моделирование vsim -L ovi_altera_mf work.<tb_name> ЗЗЫ. прочитайте readme.txt из пакета скриптов перед запуском Удачи!!!

ИМХО маетесь дурью. 1. Где то вы брали модель памяти. Сомневаюсь что кипарисы не вложили к этой памяти простой тестик для понимания транзакций к памяти (у микрона например всегда такие тесты идут). 2. SRAM настолько простая память что сделать для нее простейший контроллер дело не более часа, двух. И смысл тестировать есть уже контроллер, а не память. 3. В сети много реализаций контроллеров, возьмите готовый и модифицируйте тестбенч для него. Удачи !!!

Вопрос не приветствия, а смысла. Кстати при некорректно реализованном интерфейсе тестбенча и модели возможно потребуется немного изменить тестбенч. А насчет логов теперь вообще не понятно. Чем файл логов для поведенческой модели отличается от него же во временной ? и чем вас не устраивает transcript файл в котором моделсим хранит историю консоли ? И последнее вы собираетесь сразу топ-левел для фпга моделировать ? или внутренний блок ? если второе, то не знаю как у ксайла, но у альтеры EDA Netlist Writer пихает в post-fit модель еще и ячейки входа-выхода(даже если пинты виртуальные) ? Если кто знает как его от этого отучить буду благодарен. PS. Не забудьте про оптимизацию симуляции и компиляции в моделсиме и про то что при синхронизаторы клок-доменов могут некорректно симулятся в нем.

кхм, месье сторонник извращений ? может лучше формальную верификацию сделать ? сохранить в wlf то можно, но вот что это вам даст ? :) ЗЫ. post-route делал пару раз, но только что бы явные баги найти. Всегда хватало функциональной симуляции. При этом длительные тестбенчи лучше отслеживать по логам, а не вейвформам. ЗЫ. ну можно еще с vcd что нить намудрить. Удачи!!!

ИМХО от времени и условий все у вас зависит. отлаживать логику протоколов класса TCP-IP на проце намного легче чем на фпга. Если время ограничено и нет человека который вариться в кухне EDK/SOPC то поставте внешний арм(например LPC2478 + бесплатный ничи стек). Если запас есть то освоите EDK, пригодиться (да и чип у вас толстый). На форуме кстати темы про TCP/IP на микроблейзе были. Можно конечно использовать опенсорсный проц класса AVR, MSP430, но думаю что по затратам времени это эквивалентно освоению микроблейза ( правда совесть будет более чистой %) ) TCP/IP stack VHDL кстати синтезируемый но проверен авторами на 10 мегабит эзернете. ЗЫ. Сам использую частично переписанную корку от Igor Mohor. Удачи!!!