alman

Не поделитесь информацией о процессе получения ключа? Он покупается дополнительно или достаточно приобрести лицензию на Quartus?

Большое спасибо всем ответившим. Решение в виде привязки к конкретной ПЛИС вполне устраивает. Для демонстрации более чем достаточно. Что касается Квартуса, то вот такая "засада": Т.е. для генерации EDIF Нужна лицензия. Об использовании VQM файлов нашёл следующую информацию: http://quartushelp.altera.com/13.0/mergedP...omp_results.htm Похоже, Quartus с лицензией Web Edition не поддерживает опцию " Save a node-level netlist of the entire design into a persistent source file" - у меня она не активна. Аналогичная ситуация с QXP файлами - пр попытке сформировать такой файл, предлагает купить лицензию. NGC - это аналогичный формат от Xilinx? Интересно, как с этим обстоят дела у Xilinx. Ему тоже нужна лицензия? А существует ли возможность сконвертировать .v в .bdf файл? Похоже, для разработки серьёзных IP без лицензии не обойтись, но может быть для простых проектов вместо верилоговских исходников можно предложить Block Diagram / Schematic File ? Какая-никакая, а всё же защита.

Будьте добры, подскажите как можно распространять модули без исходного текста. Есть небольшой проект на Verilog для платы Марсоход2. Проект пока не готов для выкладывания его в исходном коде. Да и вообще - жаба душит. Частично решение - предложить пользователям SOF-файл c образом прошивки. Для демонстрации этого вполне достаточно, но в идеале хотелось бы предложить проект, часть которого идёт в исходном коде в виде примера, но некоторые модули должны поставляться в виде "черного ящика" - т.е. исходный код некоторых модулей должен быть закрыт. Собственно вот такая задача. В качестве среды разработки используется Quartus Web Edition. Если в Квартусе есть возможность "закрывать" модули, позволяет ли это делать Web Edition или для этого нужна коммерческая версия? Заранее благодарен за ответы. Интересует любая информация, не только о Квартусе, но и общие принципы.

Ой, а ведь это очень просто. Действительно, вырождается в конструкцию из нетлиста. Похоже, только опыт поможет избежать таких непониманий. Ошибка была во вложенном модуле. Исправил конфликт и генерация восстановилась. Я сбрасывал регистр "enable_decoder" для проверки. Идея модуля заключается в перехвате некоторых команд для их обработки, чтобы не усложнять субмодуль и не плодить в нём лишние сущности. Этот сброс был просто маленьким шагом перед реализацией сложного алгоритма. Пользуясь случаем хочу задать ещё вопрос. Если в проекте активно используются Мегафункции, например, двухпортовая RAM, то как можно отлаживать в Icarus Verilog модули, которые активно используют эти мегафункции? Отказаться от моделирования, искать/реализовывать аналоги или есть какие-то простые решения? Чувствую, что без моделирования лучше сразу отказаться от проекта.

Спасибо. Кстати, Quatus быстро подсказал эти ошибки. Попробовал добавить сброс в тестовый пример и, похоже, что получилось. А вот "реальном" проекте со сбросом большая беда. Вот пример модуля, который ничего не делает, кроме работы с субмодулем. module Task ( input wire i_clk, // Тактовый сигнал input wire i_rst, // Сигнал сброса output reg o_signal, // Событие output reg [1:0] o_access_type, // Тип запроса output reg [31:0] o_address, // Адрес запроса input i_ack, // Подтверждение запроса input [31:0] i_ida, // Инструкция/данные/адрес output reg [31:0] o_data // Выход данных ); reg enable_decoder; // Вызвать декодер команд reg [31:0] ida; // Инструкция/данные/адрес reg ack; // Подтверждение запроса wire decoder_alarm; // Получен сигнал от декодера wire [1:0] decoder_request; // Тип события декодера wire [31:0] decoder_bus; // Адрес на шине декодера wire [31:0] decoder_data; // Выход данных декодера decoder u_decoder( .i_clk(i_clk), .i_rst(i_rst), .i_ena(enable_decoder), .o_signal(decoder_alarm), .o_access_type(decoder_request), .o_address(decoder_bus), .i_ack(ack), .i_ida(ida), .o_data(decoder_data) ); always @ * begin enable_decoder <= 1; ida <= i_ida; ack <= i_ack; end always@(posedge i_clk ) begin o_signal <= decoder_alarm; o_access_type <= decoder_request; o_address <= decoder_bus; o_data <= decoder_data; end endmodule Весь "лишний" код удалил, чтобы просто проверить. Скомпилилось удачно и получен такой нетлист: После этого пытаюсь добавить обработку сигнала сброса, добавив проверку в первый always : always @ * begin enable_decoder <= 1; ida <= i_ida; ack <= i_ack; if ( i_rst) begin enable_decoder <= 0; end После этого получается что-то нехорошее - enable_decoder правращается в инверсию от сброса. При этом оптимизатор сразу убирает декодер из проекта - логических элементов в проекте становится меньше на ~1000. Вот такой нетлист: Перепробовал различные варианты, но так и не решил проблему. Похоже, по-прежнему чего-то сильно недопонимаю.

Уважаемые SM, Golikov A. и все ответившие в теме. Большое спасибо за исчерпывающую информацию - буду испольлзовать эту тему как справочник. Разрешите уточнить ещё вопрос относительно сигнала сброса. Можно ли все блоки always поместить в ветку else? Т.е. как-то так: if( i_rst ) begin // Код инициализации end else begin always @ * // что-то делаем always @ posedge clk // заканчиваем что-то делать end SM, c Вашего позволения исправлю always в последнем примере, чтобы не сбивать с толку случайных посетителей темы.

Простите за назойливость. Хочется понять раз и навсегда. Сделал отдельный always. Заменил все блокирующие прерывания на неблокирующие. Догадываюсь, что поступил глупо, поэтому вся надежда на указание, где и почему в этом примере понадобятся блокирующие присваивания. module Parent( input wire i_clk, input wire i_rst, input wire [7:0] i_cmd, output reg [7:0] o_result ); reg enable_child; reg sub_cmd; wire o_chd_result; Child child_0( .i_clk( i_clk), .i_rst( i_rst), .i_ena(enable_child), .i_cmd(sub_cmd), .o_result(o_chd_result) ); always @ * begin casex (i_cmd) 8'b01110xxx: begin enable_child <= 0; end 8'b11001100: begin sub_cmd <= 8'b00110011; enable_child <= 1; end default: begin sub_cmd <= i_cmd; enable_child <= 1; end endcase end always @( posedge i_clk ) begin casex (i_cmd) 8'b01110xxx: begin o_result <= 8'b01010101; end 8'b11001100: begin o_result <= o_chd_result + 8'b00000101; end default: begin o_result <= o_chd_result; end endcase end endmodule Будьте добры, скажите что неправильно в последнем примере. Очень хочется понять, как заставить пример работать за один такт. И ещё вопрос - на что повлияет тип присваивания в субмодуле? Как он относится к возможности запустить схему за такт? Спасибо.

Огромное спасибо всем ответившим! Как перехватывать сигнал стало понятно. Да, я хотел отключить клок для экономии энергии, но судя по сложности устранения побочных эффектов, от этого придётся отказаться. А вот как быть если появилась необходимость подсунуть свою "команду" субмодулю? Немного изменил пример. Все команды константы взяты случайно просто для примера. module Parent( input wire i_clk, input wire [7:0] i_cmd, output reg [7:0] o_result ); reg enable_child; reg sub_cmd; wire o_chd_result; Child child_0( .i_clk( i_clk), .i_ena(enable_child), .i_cmd(sub_cmd), // Подстановка команд .o_result(o_chd_result) ); always @( posedge i_clk ) begin casex (i_cmd) 8'b01110xxx: begin enable_child = 0; o_result = 8'b01010101; end 8'b11001100: // Новая команда, требующая подстановки begin sub_cmd = 8'b00110011; enable_child = 1; o_result = o_chd_result + 8'b00000101; end default: begin sub_cmd = i_cmd; enable_child = 1; o_result = o_chd_result; end endcase end endmodule Можно ли так делать? Конечные автоматы это хорошо, но хочется всё поместить в один такт. Могут ли тут быть проблемы?

Будьте добры, объясните как привильно добавлять новые возможности в проект. К примеру есть базовый модуль module Child ( input wire i_clk, input wire [7:0] i_cmd, output reg [7:0] o_result ); // Вместо этого примитивного примера здесь может быть сложный код always @( posedge i_clk ) o_result = (i_cmd >>> 4) + 4; endmodule Нужно перехватить вызов и обработать его на уровне выше. При этом желательно чтобы отключалась синхронизация в случае перехвата команды родительским модулем и включалась обратно, если команда не перехватывается. Получился вот такой код: module Parent( input wire i_clk, input wire i_rst, input wire [7:0] i_cmd, output reg [7:0] o_result ); reg enable_child; wire i_cild_clk; wire o_chd_result; assign i_cild_clk = i_clk & enable_child; Child child_0( .i_clk(i_cild_clk), .i_rst(i_rst), .i_cmd(i_cmd), .o_result(o_chd_result) ); always @( posedge i_clk ) begin casex (i_cmd) 8'b01110xxx: begin enable_child = 0; o_result = 8'b01010101; end default: begin enable_child = 1; o_result = o_chd_result; end endcase end endmodule А как это же самое сделать правильно или лучше?

В случае обработки системных вызовов в одном потоке, вытеснение происходит реже, чем в случае асинхронной борьбы за ресурсы. Спасибо, о сопроцессоре действительно не подумал. В документе слегка описано взаимодействие в многопроцессорной системе, мне кажется на этом базисе можно оформить сопроцессор как устройство на локальной шине. В этом случае ему просто можно передавать сообщения, как и другому процессору. Даже наблюдается некоторый профит - в сообщений можно передавать целую формулу, а в обратном сообщении получить результат(ы). Простите, моё упущение. А ещё механизм "сверхбыстрых" прерываний на ARM имеет нечто общее с идеями L4. Не сочтите за оффтопик, но это случай когда аппаратное решение обогнало программное. Если не ошибаюсь, то ли в Sun OS, то ли в Солярис, то ли в обеих, на каждую пользовательскую задачу создавалась задача в ядре. По моему скромному мнению, именно этот факт превратил преимущество в недостаток. А само микроядро L4 Pistachio в MS Virtual PC, VM Ware Player или в Oracle Virtual Box, не может ли являться достаточным доказательством? 32-х битная версия http://narod.ru/disk/30145508001/floppy.img.html 64-х битная версия для Virtual Box - https://docs.google.com/file/d/0Bzo8HAmNqHg...2hxVEVXdlk/edit Часть информации о таблице страниц можно поместить непосредственно в TCB. В этом случае можно "закешировать" какие-то опорные данные для MMU. Кстати, дать гарантию на кое-какое увеличение быстродействия можно. Самый простой пример, это выборка команд. Например, сегмент кода можно описать меньшим числом страниц - меньше page fault. На выборке кода из универсальных страниц можно значительно разгрузить MMU. Беда в том, что я не могу представить, как работает MMU. Если бы кто-нибудь подтолкнул к подробному низкоуровневому описанию работы MMU, можно было бы сгенерировать идею. Простите, а какая ОС исполнялась на Sparc, а какая на пне? Ядро Windows NT очень хорошо спроектровано. Уверен, что в данном случае выиграла не архитектура процессора, а архитектура операционной системы. Есть ли какие либо возражения об использовании аппаратного L4 в микроконтроллерах без MMU? Ведь обменваться сообщения можно и в одном адресном пространстве.

Выношу на ваш суд спецификацию "Формальное описание аппаратного микроядра L4" - http://l4os.ru/download/L4_Hard_20130119.pdf. Документ описывает расширение системы команд микропроцессоров для реализации аппаратной поддержки микроядра L4 ревизии X2 и совместимых спецификаций. Основная идея в том, чтобы реализовать эти идеи в уже существующих микропроцессорах. Некоторую информацию о том, что такое аппаратное микроядро, можно почерпнуть из следующих обсуждений: http://forum.ixbt.com/post.cgi?id=print:8:...ser=%20xameleon http://www.linux.org.ru/forum/talks/8719518 http://forum.ixbt.com/post.cgi?id=print:8:...ser=%20xameleon http://habrahabr.ru/post/113654/ Микропроцессор, соответствующий формальному описанию :)

Бегло пробежался по обсуждению и не увидел ссылки на документ, описывающий систему команд. Вот этот документ: http://multiclet.com/docs/PO/Manual_Soft.pdf Для распараллеливания используется абстракция "Параграф", границы которого устанавливаются специальным битом в команде. Банальный пример, на котором можно получить выигрыш, например формула из школьного учебника геометрии: X и Y можно считать параллельно. Разработчики утверждают, что их процессор является процессором общего назначения, но у меня сомнения по этому поводу.

Нет нет. Я не имею отношения к "Байкал электроникс ". Месяцы - не проблема. Даже несколько лет - не срок. Нужен необычный MMU - с поддержкой виртуальных страниц различного размера от Minimal Page Size до (Minimal Page Size) * 2 ^ N. Т.е. выравненный регион памяти размером 100 Кб описывается тремя страницам: 64Кб + 32Кб +4Кб. Соответственно, MMU должен понимать такие страницы. Задача нетривиальная, поэтому и интересна стоимость такой разработки.

Позвольте не согласиться в Вами, передача TCB происходит при любом системном вызове. Некоторый overhead при перегрузке ALU с лихвой компенисруется упрощением софтверной части. Первое что можно гарантировать - отстутствие необходимости в реализации объектов синхронизации. Если это не оффтопик, то я бы постарался обосновать эту точку зрения. В любом случае, если аппаратная реализация сократит хотя бы несколько тактов, это будет уже выигрыш в скорости по сравнению с программной реализацией. Дело в том, что операция отображения страниц (когда одна задача отображает свою виртуальную страницу в адресное пространство другой задачи) реализована как сообщение (через команду IPC). Количество страниц, которые можно поместить в сообщении, ограничено размером буфера собщения (64-слова). Одна страница занимает два слова. Поэтому максимальный размер отображаемый памяти в одном сообщении - 32 * 4К = 128Кб. В случае FlexPages - 32 страницы, помещающиеся в сообщении, способны описать любой регион памяти. Спасибо, что даёте шанс отстоять точку зрения.

Прежде всего я хочу извиниться за дикое количество опечаток. От людей хочется, чтобы постепенно стали воспринимать идею аппаратного микроядра как следующий шаг в развитии процессоров и как неизбежность. :) Пока не ищу. Да смысла нет приходить с чужим PDF (L4 X2 Reference manual) и говорить: "Сделайте такое, как тут описано, только в железе". Для начала хотелось бы узнать, что такое "плавающая маска для виртуальных адресов в TLB"? Мне подсказали, что она необходима для реализации MMU с поддержкой FlexPages - виртульных страниц различного размера. Нет нет, я никого ни к чему не принуждаю. Лишь надеюсь, что тема аппаратной реализации синхронных сообщений и расширенного MMU будет интересна кому-либо ещё. Мне кажется тут даже две темы - можно не следовать стандарту и сделать микрокронтроллер без виртуальной памяти, но с поддержкой сообщений. Т.е. тему можно расценивать так же и как обращение к разработчикам оригинальных CPU.

Уважаемые господа и дамы, позвольте проконсультироваться по вопросу аппаратного микроядра. Я слаб в микроэлектронике, поэтому прошу отнестиcь снисходетельно. Итак, существует микроядро L4 спецификации X2. Я довольно давно с ним работаю и приблизительно столько же времени мечтаю увидеть его реализованным на кристалле. Чтобы добавить поддержку микроядра в микропроцесссор, необходимо модифицировать два блока - MMU и декодер команд. К системе команд добавляется несколько команд. Главная команда Inter Process Communication (IPC). Для её реализации необходимо выделить на кристалле блок памяти для описания задач - Task Control Block (TCB). В общем случае TCB одной задачи должен включать следующе элементы - копия всех регистров ALU, буфер для описания соообщения (64-регистра), поля, описывающие задачу (приоритет задачи, текущий квант времени), данные для MMU, обеспечивающие привязку таблицы страниц к задаче, возможно что-то ещё. Адрес TCB в памяти одновременно является глобальным идентификатором задачи (нити исполнения, программного потока). Команда IPC включает две фазы - фазу передачи сообщения и фазу приёма сообщения. Аргументом команды IPC является регистр, содержащий идентификатор задачи (физический адрес TCB), с котором происходит обмен сообщениям. Что происходит, когда декодер команд распознаёт команду IPC? Анализирует фазы команды. Если фазы передачи нет, то процессор устанавливает флаг ожидания в TCB текущей задачи, сохраняет регистры ALU в TCB, затем выбирает TCB с наивысшим приоритетом, не находящимся в фазе ожидания приёма, и загружет ALU из выбранного TCB - в результате происходит переключение задачи. В случае, если команда IPC имеет фазу передачи, то процессор анализирует состояние процесса-приёмника (поле в его TCB) и при условии, что приёмник находится в состоянии ожидания (от передающего или любого процесса), происходит обмен сообщениями - регистры сообщения копируются из TCB передатчика в TCB приёмника. В случае, если сообщение подразумевает передачу блоков памяти, процессор также передаёт их (на основе данных буфера описателя сообщения). В случае, если сообщение подразумевает mapping виртуальной памяти - эта функция также выполняется командой IPC. Важным, на мой взгляд, моментом, является ситуация, когда блокированы все IPC - например, каждая задача находится в ожидании готовности другой или какого либо события. В этом случае процессор должен переходит в состояние низкого потребления энергии. Другим важным моментом являются прерывания. Они так же организованы через IPC. Т.е. обработчик прерывания это задача, которая ждёт сообщение от источника прерываний. Таким образом любое прерывание может вывести процессор из состояния низкого энергопотребления, продолжив выполнение задачи, ожидающей IPC. Ещё одна возможность L4 IPC - аттрибут, указывающий два интервала времени - время передачи сообщения и время приёма сообщения. Время описывается экпонентиальной величиной с двумя граничными состояниями - 0 - не блокироваться, если удалённая сторона не готова и бесконечность - ждать готовности удалённой стороны. Прияём, время передачи и время приёма - независимы. Отдельно хочется сказать о многопоточности и многозадачности. Я использовал термин задача, для общего описания последовательности команд. Задачи разделяются на нити и процессы. Нити - это задачи имеющие общую таблицу страниц - они работают в одном адресном пространстве. Процессы отличаются от нитей тем, что каждый процесс имеет свою собственную таблицу страниц, т.е. задачи работают в выделенных адресных пространствах. Таким образом в случае обмена сообщениями между нитями и между процессами, отличает лишь тем, происходит ли переключение таблицы страниц или нет. И наконец, MMU. Отличе L4 MMU от традиционных MMU является возможность использования страниц разных размером. Т.е. описатель виртуальной страницы содержит аттрибут, описывающий её размер. Таким образом блок памяти, например, 96 Кб, может быть описан двумя выравненными виртуальными страницами - 64Кб и 32Кб. Т.е. MMU должен поддерживать страницы с размерами, minimal_page_size * 2 в степени S. Где S лежит в интервале от 0 до значения, описывающего полное адресное пространство. Надеюсь, я смог достаточно понятно выразить "требования" к процессору с аппаратной поддержкой мироядра L4, хотя. многие моменты сознательно/нечайно упустил. Приглашаю к диалогу о возможности/трудоёмкости реализации данного расширения. С радостью отвечу на вопросы по микроядру L4. Кому и для чего может понадобится такой процессор? Это процессор нужнем мне - я реализовал POSIX совместимую операционную систему на базе примитивов L4X2, которая вполне удачно и оптимально использует идеи этого микроядра. В качестве бонуса прилагаю к теме раритетную спецификацию L4 X2, из которой ещё не убрали поддержку ARM. В свежих версиях спецификации остались только IA32, AMD64, PowerPC, PowerPC64. l4_x2.pdf

Вы ещё не забросили разработку процессора? У меня есть пожелания к реализации MMU и пожелание расширить систему команд.

svrdc, не могли предоставить чуть больше инфорации? А не предлагает ли кто-нибудь оригинальную реализацию "Paged Memory Management Unit"? Какого порядка суммы, если заказывать разработку с нуля?

Опыт есть. Вот здесь: http://l4os.ru.

Просто посмотрите в сторону микроядра L4 - http://l4hq.org/arch/arm/ На его основе можно построить всё что угодно, например, операционную систему - http://www.l4os.ru