Jump to content

    

yes

Свой
  • Content Count

    2731
  • Joined

  • Last visited

Community Reputation

0 Обычный

About yes

  • Rank
    Гуру

Контакты

  • ICQ
    Array

Recent Profile Visitors

11078 profile views
  1. там может #0 где-то внутри макросов? в моих объяснениях следует читать, что это все происходит в _одном_ дельтацикле, то есть следующий не создается если внутри блока нет каких-то временных конструкций.
  2. а почему должно быть зацикливание? это все выполняется в одном кванте времени, поэтому нет изменения, если до этого кванта а=1. соответственно нет срабатывания для других блоков. ну что-то типа var-ов в VHDL - что туда не напиши, оно мгновенно исполняется ------ в нцсиме есть кстати возможность развернуть таймлайн в дельтациклы - там дррррр и такая фигня вылазит - ну то есть время не растет, а последовательность событий показана
  3. может я чего-то недопонял: вопрос в том, что a=0; if (true) a=1; не генерит последовательность 0-1 каждое исполнение? ну это же бубльгум дельта-цикл, то есть результат будет учитываться только после исполнения всего блока. что такое дельта-цикл, если что - раньше на эту тему в верилоговских гайдах много писали, сейчас вроде не пишут, но он никуда не исчез
  4. grmon весьма удобный тул. что делает эклипс - не знаю, разбирайтесь. по-моему он должен запустить тот же самый grmon в режиме gdb сервера и работать с ним. может какой-нибудь антивирус гадит на межпроцесное взаимодействие? у меня вчера пол дня ушло на понимание, что avast убивает отладку в латисовском ревиале у Гейслера также был grmon с gui - попробуйте его запустить ------------------- по поводу хардварных отладочных интерфейсов - какой используете jtag, uart? проверьте, что эклипс правильные ключи использует / выбирает интерфейс правильно мне удавалось запускать отладку и из эклипса, но как-то всегда это вызывало некоторые трудности и особого преимущества перед grmon-ом из командной строки не видел
  5. J1939 - тоже можно по CAN-ID с масками отлавливать. там ID 27 бит (extended или как там), но в ID там адреса приемника и передатчика, поэтому теоретически маска нужна, но на практике обычно у каждого типа сообщений фиксированый источник и приемник также там есть многопакетные сообщения, когда больше 8 байт данных ну а вообще, там главное PGN - то есть некая таблица идентификаторов (той самой части CAN ID, см выше), но протокол разрешает назначать новые PGN-ы для нестандартных сообщений, поэтому какие-то универсальные J1939 парсеры ничего интересного не показывают (ну или нужно добавлять эти пропиентарные PGN-ы) - по крайней мере всегда с таким сталкивался. то есть опять же какую-то часть сообщений принять|передать можно, но полностью J1939 поддержать достаточно трудоемко
  6. наверняка logisim умеет экспортировать в Verilog/VHDL (по крайней мере гугль каких-то видосиков понаходил) там же есть примеры по засовыванию этого верилога в FPGA (возьмите бесплатную версию например от Интела(Альтеры) - там и синтез и симулятор есть - я так понимаю, что это хобби - заодно и развлечетесь в процессе освоения) -------------------- подозреваю что такая архитектура (ISA upd: с учетом метода реализации, конечно) полна глюками более чем полностью. исполнение случайной строки (без 00) не повесит машинку намертво? собственно верилог даст возможность погонять разные тесты и поискать "узкие места"
  7. посмотрите objdump-ом, где fpu используется. тут вообще, без всяких флагов должно быть без FPU скорее всего в старт файлах crt*.o (не тот файл берет gcc) у Гейслера должны быть примеры простого crt* - скорее всего в тестах железа (да и в исходниках libc/gcc они наверняка есть - ассемблер *.S) - слинкуйте с -nostartfiles -nostdlib с понятным crt*) без инициализации (crt) C код не будет работать, но попробуйте добиться понятного вывода objdump-а, что там нет лишнего/непонятного еще раз обращу внимания - посмотрите на тесты железа в grlib - там все было (с makefile и правильными ключами) upd: а пускаете без симуляции, сразу в железке? по-моему, не лучший подход. посмотрите ключи GRMON-a - может что-то типа -ni или про FPU. сейчас у него GRMON2|3 я еще GRMON просто использовал
  8. да, толковая была вещь. но сейчас все пользуют синтезируемое подмножество SV (кто не пользует - советую), в нем смысла в verilog-mode очень мало
  9. если gcc + newlib от Гейслера, то они собраны для разных вариантов soft-float, flat, v8 и т.д. можно посмотреть там где установлен компилер в lib то есть должно выбирать нужные crt файлы и либу в зависимости от ключей (-msoft-float). когда я собирал (давно еще без llvm), то по умолчанию было soft-float почему думаете, что hard-float используется? попробуйте простую (без printf) программу
  10. общего решения нет, но частных полно для большинства контроллеров работающих из внешней памяти есть (как уже отмечалось) механизмы защиты - в NXP. например, называется HAB (high assurance boot) - это декриптор от производителя в ПЗУ чипа, ключ прошивается во внутренней памяти (часто это ОТР - одноразовая ПЗУшка, размером в сотни байт) - после этого грузится криптованная программа, то есть ее не просто трудно разбирать, а вообще ничего не понятно. и так же в контроллер нельзя залить "шпионскую" программу без ключа. также средства отладки JTAG/дебагер отключаются. есть режимы декриптования "на лету" - то есть не надо всю программу копировать во внутреннюю память, а уже готово "ис коропки" исполнение криптованой программы btw: в "больших" АРМ-ах есть режим TRUSTZONE, который вообще позволяет чужие программы грузить и исполнять так, что ничего секретного они не могут считать (это программная модель - то есть в добавку к юзеру, суперюзеру) но я ни разу не видел полного описания имплементаций этого трастзона - видимо только проверенным пользователям под большое NDA дают ----------------------------- с внутренней памятью (флаш) предполагаю, что не так дешево считать программу из внутренней памяти. для каких-то примитивных микроконтроллеров типа ПИК16 были методы дешево сломать биты защиты "на коленке", сейчас это не так просто. есть умельцы (некая лаба при американском институте, где публично ломают контроллеры - на форуме их публикации постили и обсуждали, но так сразу не нашел), но их результаты показывают, что не так просто поломать ----------------------------- для смешаного варианта - когда есть и внутренняя память, и хочется внешнюю и/или прошивки по интернету раздавать - то нет проблемы самому накодить секьюрный загрузчик, и засунуть его в FLASH. по-моему, есть примеры у многих производителей.
  11. они жи фаблесс (?) - тогда не так быстро - на фабрике очереди, минимальные партии и т.п. за 200шт в неделю - тоже странно (но я в продажах кастомеру мало понимаю) - это 50х200=10тыщ/год - то есть очень мало для запуска, по одной пластине никто делать не будет, наделаные пластины хранить дорого - тысячи/пластина*год набегают, что для такого чипа существенно (попиленные, вроде не хранят, а корпусированые опять дорого - хотя китайцы же, может удешевили процесс)
  12. я брал версию из grlib, но когда сверял с опенкоресовской, то видел только отличия в протаскивании памятей на топ уровень (это у Гейслера некая платформозависимость добавляется в VHDL). и хорошего VIP CAN не было - сами писали из своего понимания, а в железе багов не выявили (поднимали на нем какие-то J1939 и opencan - но в протоколах высокого уровня я могу путаться, делал не я и давно уже) не 100% уверен в работоспособности опенкоресовского IP, но исправлений функционала не видел. то есть посмотрите в grlib (diff не сложно сделать жи) - вдруг я путаю, но лучше добыть какое-то VIP и им погонять опенкоресовский CAN линуксный драйвер от SJA1000 по словам программистов тоже работал (говорю про grlib и LEON3/4 и драйвер, по-моему, из его же linux-а)
  13. что задумывал автор схемы? использовать Р-канальный MOSFET как защитный диод от переполюсовки? почему тогда зашунтировано R1 и R2
  14. когда С писали еще не придумали такого. тогда это называлось ABI application binary interface https://en.wikipedia.org/wiki/Application_binary_interface то есть туда входило взаимодействие С с железом (иногда и с операционкой), не только данные, но и стэк фрэйм, процедура вызовов и т.п. (см вики) также много за пределами С - например модель памяти - типа сохраняется ли порядок записи, или вообще хоть что-то https://en.wikipedia.org/wiki/Memory_ordering также всякие обработчики эксепшинов, выравнивание и пр. ---------- нынче все ABI унылы и однообразны, а в те времена было много прикольного - народ с железом экспериментировал. из сохранившегося - SPARC - если есть свободное время рекомендую почитать для прочистки воображения :) начать можно с аппаратного стека и underflow / overflow исключений. (google: sparc abi - есть документ хороший) ---------- а сейчас наверно удобно прикрутить какую-то идею С абстрактной машины к тому, что наделали раньше. я бы смотрел на LLVM - это как бы машина заточеная как раз под С и под С/С++ компиляторы. то есть написать бэкенд для трансляции кода этой машины в любой разумный ассемблер не сложно, и с С/С++ фронтэнд для трансляции в эту машину уже есть (gcc собственно) ====== upd: то есть вопрос с абстрактизацией модели во времена писания С решался в стиле "вам ехать или шашечки?". то есть под каждое железо хотелось иметь язык "среднего уровня", а не ковыряться с ассемблером