Перейти к содержанию
Поиск
    

=AK=

Свой
 Профиль  Обзор контента

  • Постов

    3 234

  • Зарегистрирован

  • Посещение

  • Победитель дней

    5

 Тип контента 

Сообщения, опубликованные =AK=

  1. Опубликовано · Пожаловаться

    пристроим ее прямо на чип , протянем шины от каждой ячейки по надобности, и вообще добавим к каждой ячейке железа не скупясь. Не RISC же делаем :)

    Это будет уже не SRAM, а регистровая память.

    Что Вы подразумеваете под словами "регистровая память"?

     

    Вот это:

    http://www.whatis.ru/hard/mem11.shtml

    "Регистровая память

    Registered Memory это память с регистрами, которые служат буфером между контроллером памяти и чипами модуля. Регистры уменьшают нагрузку на систему синхронизации и позволяют набирать очень большое количество памяти (16 или 24 гигабайт) не перегружая цепи контроллера.

    Но данная схема имеет недостаток - регистры вносят задержку в 1 такт на каждую операцию, а значит - регистровая память медленнее обычной при прочих равных условиях. То есть - оверклокеру неинтересна (да и стОит она очень дорого)"

     

    или же вот это:

    http://www.intuit.ru/department/hardware/archhard2/5/

    "На нижнем уровне иерархии находится регистровая память - набор регистров, входящих непосредственно в состав микропроцессора (центрального процессора - CPU)."

     

    Если последнее, то почему обычные процики (AVR, PIC, Z8, и т.д) могут использовать такую память (на кристалле, непосредственно в составе проца), а мне в моем "супер-пупер CISC-е" в этом отказано? Если Вы скажете, что тот же AVR не может делать никаких арифметических и т.п. операций с операндами в памяти, я возражу, что он RISC, поэтому и не может. Разработчики пожалели железа, потому и не сделали.

     

    Мне железа не жалко, и я сделаю проц примерно такой же, как ранние ЭВМ 50-х и 60-х годов, которые называть RISC-ами смешно. Возьму за основу, например, трехадресную БЭСМ-4м, снятую с производства в 1963 г., в которой, как я помню, регистров не было вообще, а все операции выполнялись непосредственно на памяти. Главное что изменю - поставлю быструю память и сделаю все операции однотактными. Без конвеера, ессно, т.к. в оригинале конвеера не было. Не придумали еще.

     

    Поскольку регистров в моем CISC-е нет, то при прерываниях сохранять ничего не надо. Померявшись скоростью реакции на прерывания (которых, впрочем, в БЭСМ-4 может и не было, не буду врать, не знаю, но к своему процу я их прикручу, уж будьте покойны) , RISC-и со своими регистрами и конвеерами нервно покурят в сторонке :)

     

    Если Вы и такую реинкарнацию БЭСМ-4 вопреки здравому смыслу и очевидности назовете RISC-ом, то далее убеждать Вас в чем бы то ни было я отказываюсь. :(

  3. Опубликовано · Пожаловаться

    Ок, вносим ясность, память - не регистровая и не ассоциотивная, обычный SRAM или DRAM.

    За что такая немилость? Это нечестно! Разве тот же 51-й или AVR используют DRAM? Я думаю, никто из нас толком не знает, какова встроенная память в любом проце, но уж наверняка не DRAM, и очень может быть что не SRAM в обычном понимании. Какова кэш-память в том же пентюхе?

     

    Ну ладно, пусть будет SRAM. Скажем, для 50МГц проца возьмем SRAM или даже PSRAM с 10 нс циклом, чтобы иллюзий не было. Однако пристроим ее прямо на чип , протянем шины от каждой ячейки по надобности, и вообще добавим к каждой ячейке железа не скупясь. Не RISC же делаем :)

     

    Интересно, только IMHO такой реализацией вы сделали очень крутой RISC процессор.

    Ну никаким боком он не RISC. Потому что сумма целей моих при этом была прямо противоположна целям RISC-а. Я не стремился уменьшить кол-во железа и переложить исполнение сложных команд на компилятор ЯВУ. Наоборот, я стремился выполнить сложные команды в железе, не считаясь с расходом кремния. Типичный CISC подход.

     

    Это была всего лишь иллюстрация утверждения, что сколь угодно сложную команду можно выполнить за 1 такт. Расточительно, неизящно, но роли это не играет, главное - можно

     

    Поэтому ничто не мешает построить CISC, в котором все команды будут выполняться за 1 такт. Что и требовалось доказать.

     

    Кроме того, Вы забываете про выборку команды, т.к. CISC это не спец процессор и его возможности не заканчиваются на одной команде. Этапы, которые проц. должен реализовать: "выборка команды", "декодирование", "загрузка операндов", "выполнение действия АЛУ", "запись результата".

    Где скрижали, на которых написано, что CISC не имеет права делать эти действия (все или часть) за один такт? Чтобы он не имел права выполнять все команды за один такт? Чтобы было прямо сказано, что RISC-у это можно, а CISC-у - ни-ни, ни в коем случае, иначе это и не CISC, а невесть что, то ли (внеклассовый?) "спец-процессор", то ли "крутой RISC".

     

    Почему это спец-процессор не может быть CISC-ом? A RISС-ом он может быть, или тоже "низзя-а-а-а" (с) ?

  5. Опубликовано · Пожаловаться

    Хочу написать программу управления ПК с ПДУ через COM порт, но не знаю с чего начать

    Начинать всегда надо с Гугла :)

     

    http://www.lirc.org/ LIRC is a package that allows you to decode and send infra-red signals of many (but not all) commonly used remote controls.

     

    http://irstudio.chat.ru/ Программа для считывания ИК-пультов бытовой теле/видео/аудиоаппаратуры и их воспроизведения

  6. Опубликовано · Пожаловаться

    Это чем-то отличается от команды умножения с операндами в регистрах? То есть, по-вашему, регистры чем-то принципиально отличаются от памяти?

    Конечно. Хотя бы тем, что операция чтения из памяти как минимум требует одного такта (хотя в действительности может быть больше). В то время как регистры могут быть непосредственно подключены к входам и выходу АЛУ. Для выполнения такой команды потребуется на мой взгляд как минимум 4 цикла обращения к памяти (хотя может быть и больше).

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

     

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

    Каждая 128-битная ячейка памяти имеет ассоциированный с ней умножитель 128х128. Например, старшее 128-битное слово результата с выхода умножителя прописывается назад в саму ячейку, младшее 128-битное слово прописываеется в соседнюю с ней ячейку. Для чего между всеми соседними парами ячеек проложен свой специальный 128-битный пук проводов, и к каждой ячейке добавлен еще мультиплексор. То есть, под эту конкретную команду у меня кусочек АЛУ встроен прямо в каждую ячейку памяти, но при этом память осталась регулярным массивом, как ей дОлжно быть. Расточительно? Конечно. Однако технически реализуемо? Несомненно. За 1 такт. Безо всяких конвейеров.

  7. Опубликовано · Пожаловаться

    За один такт можно выполнять сколь угодно сложные команды, это не вопрос.

    Распишите (хотя бы для себя на листочке) по шагам как должно быть построено железо, чтобы сделать за 1 такт команду: например, чтение (пусть будет 128-битного, хотя здесь неважно пусть разрядность будет равна разрядности шины данных) слова из памяти, умножение на слово в регистре и запись удвоенного по разрядности результата обратно в память. (для CISC такая команда вполне возможна).

    Это чем-то отличается от команды умножения с операндами в регистрах? То есть, по-вашему, регистры чем-то принципиально отличаются от памяти? Так же точно и сделаю за один такт, как делается на регистрах. Гарвардская архитектура, слова в памяти данных 256-разрядные, шина данных тоже, обращение возможно к половине слова (128 разрядов) или к целому слову. Для чистоты мысленного эксперимента при этом регистров как таковых вообще не буду иметь, и при этом пусть любая ячейка памяти может использоваться так же, как в привычных нам процах используется аккумулятор. Чтоб совсем не было сомнений, что это CISC, вместо умножения предлагаю сделать команду извлечения квадратного корня. Для простоты и устрашения, делать буду табличным методом, для 256-разрядных операндов. Раззудись плечо, размахнись рука, ресурсы-то по условию задачи даны немеряные! :)

  8. Опубликовано · Пожаловаться

    CISC не может выполнять команды быстрее RISC'a, т.к. команды сложные,

    Сложные команды нельзя выполнять за один такт? Обоснование не представите?

     

    За один такт можно выполнять сколь угодно сложные команды, это не вопрос. Вопрос состоит только и исключительно в том, что неэкономно тратить железо на то, чтобы воплотить все сложные команды за один такт. Поскольку в средней программе они встречаются относительно редко, а кремния требуют относительно много. Экономнее выполнить их за несколько тактов (что часто делается в CISC, а также в некоторых недо-RISC-ах), или вообще их не иметь в системе команд (что характерно не только для RISC, но и для таких "экономических" CISC-ов, как, например, 51-й) .

     

    если же он выполняет команды за 1 такт, то это значит, что как минимум у него есть конвеер, который при обработке запроса на прерывание придется сбросить.

    Конвеер равно фиолетово относится как к CISC-ам, так и к RISC-ам. То есть, и там и там он может быть или не быть. В RISC-ах конвеер встречается чаще.

     

    Неплохая статья: http://arstechnica.com/cpu/4q99/risc-cisc/rvc-1.html

    1. RISC was not a specific technology as much as it was a design strategy that developed in reaction to a particular school of thought in computer design. It was a rebellion against prevailing norms--norms that no longer prevail in today's world.

    2. "CISC" was invented retroactively as a catch-all term for the type of thinking against which RISC was a reaction.

    3. We now live in a "post-RISC" world, where the terms RISC and CISC have lost their relevance (except to marketing departments and platform advocates). In a post-RISC world, each architecture and implementation must be judged on its own merits, and not in terms of a narrow, bipolar, compartmentalized worldview that tries to cram all designs into one of two "camps."

  9. Опубликовано · Пожаловаться

    Во первых, напомню, что любой процессор первым делом при запросе на прерывание, дожидается завершения выполения текущей команды. У CISC команды могуть быть и 12-ти и 20-ти и более байтовыми, соответсвенно колоcсальные временнЫе затраты уходят не только на их испольнение, но и на выборку. Следовательно как минимум в этой фазе CISC уступает RISCу по скорости реакции на IRQ.

    Неубедительно. CISC не обязан иметь длинные команды в системе команд. Некоторые CISC-и имеют такие команды, другие - нет. CISC, выполняющий любые команды за 1 такт, не станет от этого RISC-ом.

     

    Во вторых, процессор (RISC), имеющий в своем распоряжении много регистров, может вообще ничего не сохранять в стеке (кроме адреса возврата), т.к. регистров предостаточно, и каждая задача может использовать исключительно свой набор регистров. Если компиляторы не используют эту возможность, значит они гнилые.

    Это не решение. Оно годится только для очень простых приложений, где количество задач у уровней вложения прерывания ограничено каким-то смешным минимумом, обязательно статическим. Для динамически создаваемых задач этот довод вообще не в кассу.

     

    В общем случае решение есть только одно - сливать регистры в стек. И здесь RISC-и ковыляют далеко позади многих других.

  10. Опубликовано · Пожаловаться

    вы думаете что у нас задача минимум сбить вас с толку и научить вас делать неправильно?

    Я думаю, что всем людям свойственно ошибаться, а монополией на истину никто не обладает.

     

    вы задавали вопрос. вам наиподробнейшим образом объяснили почему происходит именно так а не иначе.

    На вопрос, котрый я задал (почему в железе "исчез" сигнал, который имелся при симуляции), я получил такой ответ: "Я бы посоветовал иногда заглядывать в сгенеренную по коду схематику...", "(просмотр схематики) помогает разобраться во что будет синтезирован код, обнаружить неточности в описании(появление нежелательных латчей, укорочение сдвиговых регистров". Ваше объяснение "у меня к сожлению нет времени для достаточно полного анализа почему синтезатор убирает сигнал RwWr_done вообще, но предположу что так как shr[2] упрощается сигнал RdWr_done ~ cmd_gate" совершенно неудовлетворительно. Я не вижу причин, почему бы он вообще должен быть сокращен, тем более что симулятор его не сократил.

     

    Зато вместо ответа на поставленный вопрос меня стали ретиво поучать, что я в список чувствительности процесса вставляю "слишком много сигналов". Что, с моей точки зрения, ни к заданному вопросу никакого отношения не имеет (по крайней мере, для квартуса), ни само по себе пользы не приносит.

     

    При этом мне "наиподробнейшим образом" объяснили, почему с процессом и со списком должно происходить "именно так а не иначе". Однако выяснилось, что на самом деле в квартусе происходит совсем не так, как мне объясняли.

     

    вам три человека указывают на ошибку. вам нужно ещё? вы не думали что те кто "ещё" не считают нужным что-то добавлять иначе здесь давно б завязалась горячая дискуссия.

    Неправда. Все три человека не на ошибку указывают, а советуют мне делать нечто, прямо противоположное тому, что рекомендует документация квартуса. Они мне рекомендуют исключить из списка чувствительности "ненужные сигналы", тогда как квартус черным по белому пишет, что я этого делать не должен, что это вредно и может привести к ошибкам. Рекомендация квартуса при этом полностью соответствует моему пониманию хода вещей.

     

    При этом very_hard единственный, кто, помимо собственного мнения по этому вопросу, привел объективную информацию, указав на стандарт, а также запустив симулинк и описав результаты. В результате я стал лучше понимать его резоны, потому как симулинк, как выяснилось, ведет себя иначе, чем симулятор квартуса. А также лучше стал понимать, почему квартус так настоятельно советует держать этот список в порядке, несмотря на то, что сам он пользуется своим собственным списком.

     

    Вы же вместо доводов выплескиваете на меня ваши дурные эмоции, зачем? других аргументов нет? Чрезмерная раздраженность никак не может служить подкреплением мнения, скорее наоборот, дискредитирует его.

     

    в приведённой вами цитате ни слово не сказано о синтезе. почему вы делаете какие-то выводы о синтезаторе?

    "Quartus II Integrated Synthesis", "вы английским хорошо владеете?" (с)

     

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

    Это не фрагмент руководства. Это фрагмент контекстно-чувствительной подсказки, объясняющей предупреждение, возникающее, когда в списке чувствительности процесса отсутствует один из сигналов, влияющий на процесс.

     

    При всей своей "чувствительности к контексту" эта подсказка одна. Она выдается как в случае, когда недостача сигнала в "комбинаторном" процессе превращает его в защелку, так и во всех остальных случаях, в том числе и для тактируемых процессов.

     

    Повторяю еще раз: квартус выдает это предупреждение в любом случае, когда в теле процесса есть сигнал, стоящий в правой части оператора, но этот сигнал отсутствует в списке чувствительности процесса. Подсказка на это предупреждение одна, объяснение одно (на комбинаторном примере), рекомендация одна: ввести в список процесса указанный сигнал.

     

    Не выбросить сигнал из списка "за ненадобностью", как мне тут наперебой советуют, а ввести его в список. "вы не понимаете в чём разница? или это намереная спекуляция?" ©

     

    а если у программы как-нибудь не хватит интеллекта чтобы обнаружить все ошибки пользователя - как случилось например в вашем случае?

    Не надо передергивать, это неприлично. В моем случае "ошибки пользователя" скорее всего не было, это подтверждается тем, что симулятор отработал сигналы правильно, как ожидалось. И это уж точно никак не было связано с кажущимися вам "лишними" сигналами в списке, поскольку в исходном случае использовалась переменная, а не сигнал.

     

    может лучше всё-таки придерживаться правилу установленных и не расчитывать что каждый компилятор будет думать что вы хотели получить не то что вы на самом деле описали

    Я тоже считаю, что лучше всё-таки придерживаться установленных правил. Квартус диктует свои правила и дает свои рекомендации, прямо противоположные вашим советам. И мне хорошо понятно, почему квартус в этом вопросе ведет себя именно так, требуя формально правильного списка. Тогда как польза от вашего совета выбросить "лишние" сигналы мне не видна.

     

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

     

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

    прикиньте так гаишник подходит к водителю ...

    Прикиньте, приходит в бухгалтерию ревизия. Бухгалтер выкладывает на стол две тоненькие папочки и говорит: "Вот это проверяйте, а остальное не надо проверять, у меня там ни ошибок нет, ни мухлежа". И убирает всю остальную документацию в сейф.

  11. Опубликовано · Пожаловаться

    CAN на 40 метрах может работать в полный рост - 1Мбод при родном драйвере, это в _50_ раз быстрее...

    Вопрос был как дешевле реализовать, а не как быстрее. Еще DALI можно помянуть, тоже открытый коллектор. 1200 бод на 300м, зато на любом кабеле и при любой топологии, без терминаторов. C-Bus 5 кбод на 1 км, свободная топология на любой неэкранированной витой паре.

     

    А эти "50 раз быстрее", небось, требуют экранированный кабель с контролируемым волновым сопротивлением, терминаторы с обоих концов и малое кол-во узлов с макс. отводами сантиметров по 10?

  12. Опубликовано · Пожаловаться

    думаю что фронты завалятся в корягу метра через два.

    LIN работает при помощи открытых коллекторов, т.е. по монтажному ИЛИ. При 20 кбод на 40 м работает.

    Далласовский 1-wire тоже использует открытые коллекторы. Даллас пишет - то 700 м.

  13. Опубликовано · Пожаловаться

    Набор инструкций C51 проще чем AVR, AVR - RISC, следовательно C51 этому параметру удовлетворяет.

    В качестве контраргумента: набор команд PIC намного проще и меньше, чем у 51-го, и все равно микрочип называет его "недо-RISC". Если следовать Вашей логике, это дает основания называть 51-й "недо-недо-RISC", или, что короче, "не-RISC". :)

     

    Однако спорить на таком уровне аргументации я могу разве что для смеха. Я уже указывал, что, с моей точки зрения, для RISC-а важной являеется цель, ради которой его система команд "уменьшена", а не само по себе количество команд. И для RISC цель эта одна: переложить заботы "микропрограммирования" сложных команд на компилятор ЯВУ. У 51-го же набор команд оптимизировался совсем не для этого.

     

    Еще пример, процессор Ignite фирмы PTSC. У него код команд вообще 6-битный (или даже 5-битный, запамятовал). И что, кто-нибудь называет его RISC-ом? Ни в коем случае, под определение RISC он не подходит, цели преследовались другие. Этот процессор относится к классу MISC - "компьютер с минимальным набором команд", но никак не RISC.

     

    Цель, поставленная при проектировании, а также совокупность использованных приемов, вот что главное. Приколотил, скажем, Лютер к двери церкви свои 10 (или сколько там) тезисов, каждый сам по себе возражений ни у кого не вызовет, так что - на этом основании всех надо записать лютеранами? :)

     

    Мое мнение таково - практически любой 8 битный MK это RISC, как минимум по двум причинам -

    1. система команд (как даже вы заметили для C51) сокращена

    Название RISC, к сожалению, выбрано неудачно. Оно производит ложное впечатление, что в сокращении набора команд и состоит сущность RISC, что стоит чуть уменьшить число команд - и проц можно записывать в RISC-и. Отсюда и рождаются подобные высказывания. Но это неверно.

     

    2. быстрая реакция на прерывания (основная особенность характерная для всех RISC процессоров).

    Ну никаким боком это к RISC-ам не относится, совершенно ортогональное свойство. Cтоит заметить, что RISC-и вообще говоря как раз медленно реагируют на прерывания, поскольку должны сохранять в стеке свои здоровенные регистровые файлы, а потом восстанавливать их. Лучше всего на прерывания реагируют стековые процессоры определенного вида, т.к. им для сохранения-восстановления контекста вообще ничего делать не надо.

     

    Про регистровые банки, которые способствуют быстрому пререключению задач характерной для RISC вы в своем сравнении почему-то забыли. А ведь по этому параметру C51 гораздо ближе к RISC чем тот же AVR.

    Потому что банки эти - вовсе не прерогатива RISC-ов, а как раз-таки наоборот, вовсю использовались именно в CISC-ах, в том числе в таком типичном CISC-е как 51-й :)

  14. Опубликовано · Пожаловаться

    Не знаю, чем Вы моделировали и как, но у меня в моделсиме получилось то что должно было получиться: не было ни одного срабатывания... Может квартус моделирует уже синтезированную схему, не знаю...

     

    Simulation Mode:

     

    Allows you to specify the type of simulation you want to run. The Quartus II Simulator can perform the following types of simulation:

     

    * Functional—Simulates the behavior of flattened netlists extracted from the design files.

     

     

    Generate Functional Simulation Netlist:

     

    Generates the functional simulation netlist required for functional simulation. The flattened functional simulation netlist extracted from the design files does not contain timing information.

     

    Я это понимаю так, что квартусовский симулятор не компилирует исходники заново, а пользуется готовыми результатами "основного" компилятора. Что очень даже логично, т.к. независимый компилятор симулинка может выдавать существенно другие результаты, чем компилятор того же квартуса. Это довод в пользу полностью интегрированных систем.

  15. Опубликовано · Пожаловаться

    Гляньте вещь под названием yacc, возможно поможет.

    Это и/или bison смотреть обязательно. Вне зависимости будет в конце-концов синтаксис бейсика или нет.

    Это нужно только профессиональным писателям компиляторов, и то в основном для образования, остальным без надобности. Гораздо практичнее использовать не полуфабрикат тридцатилетней давности, а современную готовую систему, например http://www.devincook.com/goldparser/

     

    GOLD is a free parsing system that you can use to develop your own programming languages, scripting languages and interpreters. It strives to be a development tool that can be used with numerous programming languages and on multiple platforms.

  16. Опубликовано · Пожаловаться

    Да, из 6-го класса я вылез не так давно, и ВУЗ окончил совсем таки недавно.

    Это была цитата из Задорнова: "Дайте мне чернила для 6-го класса!" ©, что ассоциируется у меня с "бэйсик для AVR". Не имел намерения ни на что другое намекать.

     

    У Вас компилятор и интерпретатор будут разделены, или же оба должны работать на целевой платформе?

    Пока все ориентированно на AVR, по этому пишется на Асме - соответственно платформа все таки целевая. Хотя, когда выработаются жесткие конструкции в голове, может быть можно будет говорить и о переносимости, хотя таковой цели я не ставлю

    Вопрос был о другом, не о переносимости. Интерпретатор находится а целевой платформе, т.е. на AVR. Вопрос в том где находится компилятор, тоже на AVR (резидентно) или на PC (кросс-компилятор). И тот и другой вариант возможны, но второй несравненно проще реализовать.

     

    Я понимаю, скажем, почему тот же Атари-бэйсик был полностью резидентным - в то время PC не существовало. И почему он был написан на ассемблере - не было C для 6502. Но сейчас-то зачем огонь трением добывать, из спортивного интереса?

  17. Опубликовано · Пожаловаться

    VHDL Process Statement warning at <location>: signal "<name>" is read inside the Process Statement but isn't in the Process Statement's sensivitity list

     

    ...

    During simulation, the Process Statement updates the value of signal o whenever signal a changes value. However, changes to the value of signal b do not trigger the execution of the Process Statement, and thus signal o behaves as a pseudo-latch, that is, it retains its value, whenever signal b alone changes value.

     

    Quartus II Integrated Synthesis ignores the pseudo-latch behavior implied by the incomplete sensitivity list in the example above. It generates logic as if the sensitivity list were complete, and therefore implements purely combinational logic for signal o.

     

    ACTION: To avoid receiving this message in the future, and to avoid potential mismatches between simulation and the synthesized logic, add the specified signal to the sensitivity list.

    ...

     

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

     

    Проверяем, как на самом деле ведет себя симулятор, если ему подсунуть неправильный список чувствительности. Создаем модуль:

    LIBRARY ieee;
USE ieee.std_logic_1164.all;
USE ieee.numeric_std.all;
USE ieee.std_logic_unsigned.all;
------------------------------------------------------------
ENTITY Sim_Test IS
    -- {{ALTERA_IO_BEGIN}} DO NOT REMOVE THIS LINE!
    PORT
    (
        Clk : IN STD_LOGIC;
        Rst : IN STD_LOGIC;
        InData : IN STD_LOGIC;
        Out1 : OUT STD_LOGIC;
        Out2 : OUT STD_LOGIC;
        OutCnt : OUT STD_LOGIC_VECTOR(3 downto 0)
    );
    -- {{ALTERA_IO_END}} DO NOT REMOVE THIS LINE!    
END Sim_Test;
------------------------------------------------------------
ARCHITECTURE Sim_Test_architecture OF Sim_Test IS

signal cnt,shr            : unsigned(3 downto 0);
signal dummy            : std_logic;

BEGIN

process(dummy) -- по-вашему, он вообще запускаться не будет?;)
begin
  if Rst='1' then
    cnt <= (others => '0');
    shr <= (others => '0');
  elsif rising_edge(Clk) then
    cnt <= cnt + X"1";
    shr <= shr(2 downto 0) & InData;
    OutCnt <= std_logic_vector(cnt);
    Out1 <= std_logic(shr(3));
  end if;
  Out2 <= std_logic(shr(1));
end process;
------------------------------------------------------------
END Sim_Test_architecture;

     

    Запускаем симулятор и видим, что он тоже, как и синтезатор, видал этот мой липовый спиcок в белых тапочках:

    post-2483-1144365580_thumb.jpg

    Что и следовало ожидать :biggrin:

     

    Усложняем задачу. Вводим липовый клок Clk101 частотой 101MHz с начальным смещением 3.33ns, и в списке чувствительности вместо dummy использум Clk101. Запускаем симулятор.

    post-2483-1144367151_thumb.jpg

    Ничего не изменилось :laugh:

     

    "Суха теория, мой друг, а древо жизни зеленеет" © :)

  18. Опубликовано · Пожаловаться

    То что Вы хотите увидеть "на самом деле", Вы видите при моделировании "после-трассировки", т.е. при моделировании синтезированной по коду схемы. В этом моделировании уже нет места списку чувствительности процесса: результат зависит от входного сигнала и временных характеристик элементов синтезированной схемы(см. сообщ. vetal).

    Это не аргумент. Чем раньше вылавливаются ошибки, тем лучше. Лучше выловить их на стадии функционального моделирования.

     

    А если моделирующий софт будет игнорировать Ваш список при моделировании до синтеза, то этим нарушит стандарт VHDL, который гласит, что процесс запускается при изменении любого из сигналов, присутствующих в списке чувствительности(если таковой есть).

    Интересно. Ссылочку можете привести?

     

    Насколько я понимаяю, ни один компилятор достаточного сложного языка реально не соответствует стандарту. Возьмите С++, полного соответствия нет ни у мелкософта, ни у GCC, не говоря уж о прочих. Квартус о своем неполном соответствии пишет черным по белому.

     

    А главное - в чем все-таки преимущество такого запуска процесса строго по моему списку? Милливатт-часы? Вот это точно бред.

  19. Опубликовано · Пожаловаться

    лишние сигналы зря запускают процесс.

    Значит, чтобы сэкономить машинное время, я должен уметь безошибочно определять, какие сигналы в списке лишние, а какие нет? Что будет если я в список клок по ошибке не включу? Я предпочитаю чтобы компьютер экономил мое время :)

     

    При условии, конечно, что Квартус и правда запускает процесс по указанному мной списку
    Запускает. Иначе - беспредел. :)

    Наоборот, беспредел - это если он будет запускать по моему списку. Тогда я увижу не то, что произойдет на самом деле, а то, что я хочу увидеть. Весь смысл симуляции теряется.

  20. Опубликовано · Пожаловаться

    Все выше сказанное, конечно, очень интересно. Но, я, с вашего позволения, продолжу тему BASIC INTERPRETER FOR AVR :-)

    "Чернила для 6-го класса?" :) Разве что пустой причуды ради хотите написать его на ассемблере. Ресурсы по Бэйсику, http://www.nicholson.com/rhn/basic/

     

    Сам интерпретатор может быть достаточно произвольным. Например, Атари Бэйсик компилировал бэйсик исходник в байт-код, который затем исполнялся виртуальной Форт-машиной. Все было написано на ассемблере 6502, но это когда ж было...

     

    У Вас компилятор и интерпретатор будут разделены, или же оба должны работать на целевой платформе?

  21. Опубликовано · Пожаловаться

    При анализе функциональной модели не происходит "нарушения времянок" т.к. все элементы идеальные! Пустая трата времени.

    Я не пишу отдельно VHDL код для функциональной симуляции, пишу один код для всего проекта. Который используется и для функциональной симуляции (при отладке), и для живого кристалла, когда Квартус проверяет все времянки. Если Вы пишете другой код, поделитись, зачем это нужно, что при этом реально выигрывается, и как Вы потом разные коды сводите воедино? Неужели несколько долей секунды машинного времени, выигранные при функциональной симуляции, стоят траблов?

  22. Опубликовано · Пожаловаться

    Andy Mozzhevilov @ Apr 6 2006, 11:10)

    Ну какой же это RISС. Длина команд может быть 1 2 или 3 байта.

    Работа напрямую с внутренней памятью, когда для RISC характерна load-store

    архитектура и работа с данными через регистровый файл.

    Тот же AVR для достижения своей RISС-овости имеет 16-битную длину команды,

    чтобы эффективно паковать в нее инструкции.

    Обычный RISC.

    Тут дело не в длине команды. load/store и работа с памятью напрямую - это одно и тоже.

    Не могу согласиться. Архитектура 51-го никаким боком не подходит под RISC. Даже Мелкочип свои PIC-и осторожно называл RISC-like. Вот не самое плохое определение RISC:

     

    (Reduced Instruction Set Computer) A computer architecture that reduces chip complexity by using simpler instructions. RISC compilers have to generate software routines to perform complex instructions that were previously done in hardware by CISC computers. In RISC, the microcode layer and associated overhead is eliminated.

     

    RISC keeps instruction size constant, bans the indirect addressing mode and retains only those instructions that can be overlapped and made to execute in one machine cycle or less. The RISC chip is faster than its CISC counterpart and is designed and built more economically.

     

    Проверяем 51-й:

     

    -- Проще набор инструкций. Соглашаться или нет - дело вкуса, однако по здравому размышлению я бы соглашаться не стал. Инструкций в 51-м много, и они сильно разномастные, неструктурированные. Просто из "большого набора" возможных CISC-инструкций выбраны те, которые наиболее употребительны в embedded-приложениях, чтобы общее количество не превышало 256 (один байт кода команд). Что явно не RISC. Про AJMP размусоливать не буду, на мой взгляд, это явный ляп разработчиков, ненужная по жизни команда, которая зазря съедает множество кодов.

    Здесь я бы добавил такой характерный признак: из набора RISC команд выброшены те, которые удобны для программирования на ассемблере, но неудобны при написании компиляторов ЯВУ. При таком уточнении 51-й - совершенно точно не RISC, его система команд явно создавалась с заботой об ассеблерщиках. Для настоящего RISC-а писать программы на ассемблере должно быть мучением и мазохизмом. В идеале - брэйнфак с одной командой. :) Для 51-го это условие не выполняется, для него вполне приятно на ассемблере писать.

     

    -- Отсутствует микрокодирование команд. Насколько мне известно, в оригинальном 51-м оно имело место быть. По крайней мере, когда я пытался заказать в МЭП-е советский клон i8044 (это 51-й с SDLC), разработчики сразу же сказали что будут делать с микрокодом, да еще хотели растактовку сделать не на 12 клоков, а на 16 :)

     

    -- Постоянный размер команд. В 51-м этот наиболее характерный признак RISC отсутствует, размер команд переменный.

     

    -- Нет косвенной адресации. На мой взгляд, не самый важный признак, но все же: в 51-м она есть, однако...

     

    -- В определении об этом забыли, но вообще-то RISC должен любую команду выполнять за 1 такт, что неверно для 51-го. Имхо, поэтому PIC и не называли настоящим RISC-ом, хотя по другим признакам он подходит. Еще у старых PIC-ов система команд тоже оптимизировалась для ассемблерного написания программ, а не для ЯВУ.

  23. Опубликовано · Пожаловаться

    Если нет события "rising_edge", то изменения сигналов cmd_gate и bit_cnt, присутствующих в списке чувствительности, только впустую запустят процесс, который ничего не выполнит. Так что все же лучше будет (для скорости моделирования) их туда не включать.

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

     

    Например, если сигналы cmd_gate и bit_cnt изменятся незадолго до или же сразу вслед за событием "rising_edge", то это будет нарушением оговоренных спецификаций железа (времена сетап и холд). "Лишний" запуск процесса в принципе позволяет это обнаружить, тогда как при настоятельно мне советуемом "избегании ненужных запусков" обнаружить этого будет нельзя.

     

    При условии, конечно, что Квартус и правда запускает процесс по указанному мной списку, в чем я лично сомневаюсь. Я подозреваю, что он достаточно умен, чтобы самому определить, когда запускать процесс, безотносительно к моему списку. А мой список использует только и исключительно для того, чтобы сравнить его с собственным списком (по которому процесс и будет запускаться на самом деле), и выдать ворнинг, мол, "что ж ты, блин, мне подсовываешь?" :)

  24. Опубликовано · Пожаловаться

    Интересно, сколько занимает эта самая фиртуальная forth машина скажем, для ARM, AVR или 68000?

     

    Примерно 2 кило на сях, см. http://sourceforge.net/projects/c-fvm

    Но это не полный Форт, а именно виртуальная Форт-машина, где компилятор кроссовый.

  25. Опубликовано · Пожаловаться

    регистр действительно будет на бит (старший) короче чтобы понять такие ситуации читайте код дослово с учётом дельтациклов, где для переменной используйте выражение "в текущем цикле", а для сигнала - "в следующем цикле".

    Мне это вообще говря не важно. Сдвиговый регистр вводился для того, чтобы привести сигнал в другое временное пространство и прибить (возможную) метастабильность. Одного каскада достаточно, а будет два или три - все равно, не играет большой рояли.

     

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

    хорошо бы подумать зачем в язык параллельный вводятся последовательные операторы - наверное чтобы упростить человеку восприятие сложных единомоментных вычислений (потому как человек в принципе привык думать последовательно)

    Используя переменные, я как раз пытаюсь исправить стиль. Раньше все делал сигналами, и это сильно раздражало. С позиций "обычного программирования", сигнал - это переменная с областью видимости для всего модуля, а переменная - соответствует локальной переменной функции (т.е. процесса).

     

    В программировании считается дурным стилем использовать переменные с большей чем необходимо областью видимости (как минимум, им приходится придумывать разные имена, а потом держать их в голове). Поэтому переменная предпочтительней сигнала во всех случаях, когда область ее видимости не должна выходить за пределы процесса. Читал, что есть и другое преимущество, а именно - на переменную тратится намного меньше PC-шных ресурсов при компиляции и симуляции.

     

    Однако крайне неприятно что переменная по поведению отличается от сигнала, это по сути просто дрова какие-то. Не понимаю причин, нафиг именно так сделано.

     

    Если можете подсказать как в VHDL сделать "локальный сигнал" без переменных, буду благодарен, я этого не умею.

     

    дополнительную путаницу может произвести тактирование одного процесса несколькими клоками - это в принципе непрактично - связано опять же с тем же восприятием, когда человек читает код он видит последовательность строк сверху вниз - у вас же получается логика описаная на дне никак не связана с логикой наверху за исключением связи по данным - но данные - жто объекты над которыми совершается действие, а процессы - сами действия обвешанные аттрибутами (главным образом времени исполнения) получается что разные по сути и моменту исполнения действия (даже над одними объектами) у вас сгруппированы в одном процессе - что не гуд

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

     

    и еще раз о списке чувствительности:

    из этого списка process(Reset, CSn,SCLKin,CLK48,bit_cnt,cmd_gate) процесс не чувствителен к bit_cnt,cmd_gate

    Ну как же так? К bit_cnt чувствителен вот этот оператор

       bit_cnt <= bit_cnt + "001"; -- count SCLK pulses

    А к cmd_gate чувствителен вот этот

     
    RdWr_done <= shr(2) and (not cmd_gate);

    В обоих случаях указанные сигналы находятся в правой части выражений, так что процесс обязан быть пересчитан заново, как только они изменились. Вот если бы я сделал bit_cnt переменной, то указывать его в списке чувствительности не надо было бы.

     

    Но главный вопрос остался открытым: симулятор показал одно (именно так, как я и представлял себе поведение этого кода), а на самом деле FPGA вела себя по-другому, а почему по-другому - я не понимаю.

×
×
  • Создать...