Jump to content

    

FLTI

Свой
  • Content Count

    399
  • Joined

  • Last visited

Everything posted by FLTI


  1. Какого типа переменную возвращает IORD_ALTERA_AVALON_PIO_DATA (PIO_1_BASE) если чтение идёт из 1-битного порта? То есть если PIO_1 сконфигурирован в QSYS как input порт шириной 1 бит. Почему шириной 1 бит? Потому что больше не нужно. Или так лучше не делать и надо задавать стандартную ширину 32 бит и тогда возвращаемый тип будет unsigned int ? Поискал по IORD_ALTERA_AVALON_PIO_DATA по сайту Альтера, но ничего толком не нашёл.
  2. Любые ли действия, которые делаются вручную через GUI в Квартусе можно перенести в скрипт или есть какие-то ограничения? Не появилось ли в последних Квартусах ( а может и раньше было ? ) что-то типа "захватчика" тех действий, которые делаются вручную через GUI и автоматическое формирование из них скрипта?
  3. Зависит ли скорость выполнения такого рода команд NIOS II : IOWR_ALTERA_AVALON_PIO_DATA IOWR_8DIRECT IORD_ALTERA_AVALON_PIO_DATA IORD_8DIRECT от того как он сконфигурирован - в режиме /e, /s или /f ? Если зависит, то насколько существенно? NIOS II тактируется клоком 50 МГц.
  4. Продаю в Москве ПЛИС / FPGA: Actel APA075-PQ208 ( 48 штук ). Date Code 1212 Желательно все 48 штук, но можно и поштучно. 500 рублей/штука. Торг.
  5. Железный контроллер для управления RSU придётся делать с нуля или у Альтеры есть что-то готовое? У меня и так с учётом компрессии и прочих ухищрений ( отдельный клок 40 МГц через CLKUSR вход и ещё кое-что ) это время на пределе ( примерно 80 мс ), но всё работает устойчиво. То есть на что-то ещё дополнительно остаётся 10 -15 мс. В итоге получается, что остаётся только рискованный способ - без RSU напрямую писать по нулевому адресу EPCS? Какие приёмы обычно используют, чтобы надёжно писать в EPCS? Я буду писать со стороны ПК через промежуточную On-chip memory ( dual-clock / dual-port ) размером чуть меньше 1Кбайт ( 1Кбайт минус 16 байт ) . С одной стороны в эту память ПК пишет данные из RPD-файла ( примерно 500Кбайт ), а с другой НИОС читает эти данные и через команду epcs_write_buffer ( из драйвера epcs_commands.h ) записывает их кусками ( 1Кбайт минус 16 байт ) в EPCS. Поскольку память при одновременным доступе на запись и на чтение по одному и тому же адресу ( а это может произойти ) возвращает значение Don't care , то как обычно делают, чтобы избежать этой проблемы? Если использовать биты готовности ( для handshake ) , то в отношении их тоже есть вероятность того, что произойдёт одновременный доступ по адресу, где находится этот бит готовности. Как тут быть? Есть ли тут какое-нибудь стандартное решение?
  6. А есть ли способ избавится от зеркального отображения битов в байте или только самому перелопачивать чтобы вернуть в нормальное состояние? Вопрос относится к семейству Cyclone 4 GX и Q13.1.
  7. Да, всё точно так! В RPD-файле - только полезные данные. Благодарю Вас, doom13 и tvcam. :beer:
  8. Да, .jic файл сразу начинается с 0x4a 0x49 0x43, что соответствует кодам букв JIC , да - до 0x92 байта идёт текстовая информация. Байт 0x92 == это 0x20. Далее в .jic файле идут 10 байт 0x00, а из EPCS по 0x00 читаются 0xFF. То есть даже вырезка 0x92 байт текстовой информации не даёт совпадения между .jic файлом и данными в EPCS с адреса 0x00. Попробую прочитать побольше данных из EPCS ( хотя это муторно маленьким окном в 16 байт ) и тогда наверное будет ясна закономерность. В том числе учту Вашу информацию о том, что "переставлены биты в байтах зеркально".
  9. Мне нужно исходный .jic файл, записанный в EPCS по адресу 0x00 заменить на другой .jic файл командами epcs_write_buffer ( из драйвера epcs_commands.h ). Как это сделать?
  10. В EPCS c 0x00 первые 16 байт - это 0xFF, остальные пока не смотрел. Прочитано командой epcs_read_buffer из драйвера epcs_commands.h.
  11. Мне нужно исходный .jic файл, записанный в EPCS по адресу 0x00 заменить на другой .jic файл командами epcs_write_buffer ( из драйвера epcs_commands.h ). Как использовать смещение, поясните пожалуйста?
  12. Вот это сюрприз! А это где-то документировано у Альтеры? Мне нужно исходный .jic файл, записанный в EPCS по по адресу 0x00 заменить на другой .jic файл. Вырезано 92(+-1) байта с начала - в смысле заменено на 0xff ? Я вижу, что именно так, но поскольку у меня маленькое окошко просмотра - всего 16 байт ( всё под завязку в ПЛИС заполнено ) , то пока не могу всю прошивку прочитать ( для этого надо прогу соответствующую писать - это чуть позже ).
  13. Это Вы знаете на собственном опыте или из теории? Вот здесь я проверил - прочитанные из EPCS данные ( по крайней мере с нулевого смещения ) не совпадают с ранее туда записанным .jic файлом.
  14. По мотивам кодов в данной теме составил такой код: unsigned int i; alt_u8 data[16]; // адрес EPCS контроллера const alt_u32 EPCS_ADDR = EPCS_FLASH_CONTROLLER_0_BASE + EPCS_FLASH_CONTROLLER_0_REGISTER_OFFSET; // смещение параметров модуля в EPCS - 0 байт const alt_u32 EPCS_PARAMS_OFFSET = 0; // режим байтов для EPCS const alt_u32 EPCS_BYTE_MODE = 0; epcs_read_buffer(EPCS_ADDR, EPCS_PARAMS_OFFSET, &data, 16, EPCS_BYTE_MODE); for(i=0;i<16;i++) { IOWR_8DIRECT(ONCHIP_MEMORY2_0_BASE, 16+i, data[i]); } Вроде всё нормально, но компилятор в Eclipse выдаёт предупреждение: warning: passing argument 3 of 'epcs_read_buffer' from incompatible pointer type [enabled by default] Что бы это значило? В EPCS записан .jic с таким .map файлом: BLOCK START ADDRESS END ADDRESS Page_0 0x00000000 0x0006AD41 ПЛИС Cyclone 4 GX с этого файла нормально стартует, правильно грузится прошивка и правильно выполняется программа НИОСа. Судя по всему если я буду читать эту EPCS с нулевого смещения , то первые три байта должны быть 0x4a 0x49 0x43, что соответствует кодам букв JIC ? Потому что эти 3 буквы я вижу с нулевого смещения в .jic файле если посмотреть его в HEX Editor. А чтение EPCS с нулевого смещения вышеприведённым кодом даёт первые 16 байт равные 0xFF. По более старшим адресам ( читаю окнами по 16 байт ) в EPCS лежат уже не 0xFF, но прочитанные значения не находятся в .jic файле если поискать их с помощью HEX Editor. UPD Сделал запись в область со смещением , а потом чтение, всё верно получается - прочитанное совпало с записанным. int i; int j; alt_u8 data_A[16]; alt_u8 data_B[16]; // адрес EPCS контроллера const alt_u32 EPCS_ADDR = EPCS_FLASH_CONTROLLER_0_BASE + EPCS_FLASH_CONTROLLER_0_REGISTER_OFFSET; // нулевое смещение параметров модуля в EPCS const alt_u32 EPCS_PARAMS_OFFSET = 16*65536; // режим байтов для EPCS const alt_u32 EPCS_BYTE_MODE = 0; for(i=0;i<16;i++) { data_A[i]=i; } epcs_write_enable(EPCS_ADDR); epcs_sector_erase(EPCS_ADDR, EPCS_PARAMS_OFFSET, EPCS_BYTE_MODE); epcs_write_buffer(EPCS_ADDR, EPCS_PARAMS_OFFSET, &data_A, 16, EPCS_BYTE_MODE); epcs_read_buffer(EPCS_ADDR, EPCS_PARAMS_OFFSET, &data_B, 16, EPCS_BYTE_MODE); for(j=0;j<16;j++) { IOWR_8DIRECT(ONCHIP_MEMORY2_0_BASE, 16+j, data_B[j]); } Почему же прочитанный из EPCS .jic не совпадает с .jic файлом?
  15. Если использовать драйвер epcs_commands.h, то надо ли делать какую-нибудь инициализацию или сразу можно читать командой epcs_read_buffer ?
  16. Тогда в чём в итоге была проблема? Я сейчас похожую штуку буду применять, поэтому интересно. Не могу даже поиском по сайту Альтеры найти описание на epcs_commands.h чтобы понять - как это функция epcs_write_buffer возвращает тип alt_32 и что это вообще за тип alt_32.
  17. Возможно, что причина в этой строчке? j = epcs_write_buffer(EPCS_FLASH_BASE+EPCS_FLASH_REGISTER_OFFSET, EPCS_ADR , &data, 15); Что Вы хотели с её помощью получить? Как можно переменной j присваивать действие процедуры epcs_write_buffer ? Это корректно? Ведь в следующей строке этой же переменной j присваиватся результат действия процедуры epcs_read_buffer.
  18. Судя по Вашему ответу Вы меня не правильно поняли. Я просил сравнить 2 варианта записи одного и того же .jic файла в EPCS в 2-х вариантах: 1). в Квартусе через JTAG с помощью USB Blaster 2). командами NIOS-а используя соответствующие команды драйвера epcs_commands.h Вопрос: При условии корректной записи в обоих вариантах в EPCS получится один и тот же битстрим или будут отличаться? Другими словами, Квартус через JTAG с помощью USB Blaster-а записывает .jic файл в EPCS один в один или что-то в нём меняет перед записью?
  19. Скажите пожалуйста, если один и тот же .jic файл записывать в EPCS через JTAG в Квартусе с помощью USB Blaster и напрямую командами NIOS-а ( используя соответствующие команды драйвера epcs_commands.h ), то в EPCS получится один и тот же битстрим?
  20. Насколько высока вероятность сбоя в процессе перезаписи EPCS'ки? Это перестраховка или реально частые сбои? Вот какая у меня ситуация. Factory прошивка, которую надо обновлять у клиента, была залита в EPCS16 в виде .jic файла. Схема конфигурации - Active Serial. Вот как выглядит .map файл от .jic файла: BLOCK START ADDRESS END ADDRESS Page_0 0x00000000 0x00068E4A - All the addresses in this file are byte addresses Размер .jic файла примерно 420 Кбайт, т.е примерно 1/4 от размера EPCS16. Я планировал сделать так: 1). Записать с помощью NIOS-а ( используя соответствующие команды драйвера epcs_commands.h ) начиная с адреса 0x00080000 в EPCS16 новую Application прошивку в виде нового .jic файла. 2). Задать ( пока не выяснил - где именно ), чтобы при включении питания загрузка прошивки происходила не с адреса 0x00000000 ( там находится прошивка Factory ), а с адреса 0x00080000 ( там находится прошивка Application ). Поскольку прошивка в виде .jic файла содержит ядро PCIe, то у меня сделано так, что конфигурирование и инициализация Cyclone 4 GX выполняется за время менее 0,1 секунды ( иначе плата с ядром PCIe не будет опознана в ПК ). Я хотел бы понять, смогу ли я использовать Remote System Update, учитывая это ограничение по времени? Дело в том, что имеющаяся в Remote System Update проверка того, загрузилась ли нормально Application прошивка с адреса 0x00080000 или нет, и не надо ли вернуться к прошивке Factory не имеет смысла, т.к при этом время 0,1 с ( за которое должен успеть сконфигурироваться и инициализироваться Cyclone 4 GX ) будет упущено. По этой же причине не имеет смысла вариант когда сначала грузится прошивка Factory, а затем она грузит Application прошивку. Значит остаётся только вариант писать новую Application прошивку в виде нового .jic файла с помощью NIOS-а ( используя соответствующие команды драйвера epcs_commands.h ) начиная с адреса 0x00000000 в EPCS16., т.е затирая при этом Factory прошивку? Какие могут быть при этом сбои? Ведь можно после записи прошивки сделать её чтение и проверить, а если были ошибки, то перезаписать неправильные байты заново. Остаётся только риск того, что отключится питание во время записи или что-то ещё может произойти из-за чего новая прошивкка не перезапишется на место Factory?
  21. У меня нет на плате ДДР, поэтому такой вариант не рассматриваю.
  22. А если выполняемая программа хранилась бы не в OnChip Memory, а в EPCS, то приведённая Вами процедура остаётся такой же, только вектора NIOSа будут направлены не на OnChip Memory, а на EPCS Flash Controller? И ещё вопрос - в чём разница хранения выполняемой программы в OnChip Memory и в EPCS с точки зрения расходования блочной памяти ПЛИС ( M9K )? Ведь даже если выполняемую программу хранить в EPCS, то для непосредственного выполнения она всё равно будет загружаться в OnChip Memory и расход блочной памяти ПЛИС ( M9K ) в обоих случаях будет одинаковым? Если так, то как сделать, чтобы выполняемую программу хранить в EPCS и при этом не выделять OnChip Memory размером с эту программу? Другими словами, можно ли выполняемую программу хранить в EPCS и оттуда же её и запускать?