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

FLTI

Свой
  • Постов

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

  • Посещение

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


  1. существуют ли в природе относительно недорогие (до 1300 USD) платы с DRII+ SRAM?

    На http://www.altera.com/products/devkits/alt...lone-iv-gx.html есть

    128-megabytes (MB) DDR2 SDRAMs with a 32-bit data bus

    64-MB sync flash and 4-MB SSRAM

     

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

     

  2. Ну тогда используйте несколько конфигураторов помельче, и джамперами подключайте нужный.

    Тогда можно ли к Cyclone IV параллельно подключить 4 штуки EPCS4 ( точнее её аналог M25P40 ) и джампером ( или через DIP SWITCH ) подключать соответствующий конфигурационный пин Циклона NCSO к Chip select той флешки, с которой должен грузиться Cyclone IV?

    Как Cyclone IV к такой учетверённой нагрузке по остальным конфигурационным пинам отнесётся?

  3. Попробуйте такой прием - во флэшку заливается несколько прошивок, первая из которых занимается опросом тех самых DIP-свичей. Назовем ее фабричной прошивкой, а все остальные прошивки - приложениями.

    В зависимости от состояния переключателей фабричная прошивка выбирает одно из приложений и загружает его через Remote Sуstem Upgrade.

    Спасибо за совет, но в моём случае такой вариант скорее всего не подойдёт т.к выбранная прошивка-приложение должна грузиться за время < 0,1с после подачи питания т.к. в её составе ядро PCIe.

    Remote Sуstem Upgrade вряд ли так быстро сработает.

     

    P.S. Каждая отдельная прошивка у меня грузится за время < 0,1с и с этим проблем нет.

  4. любой малоногий проц + флешка

    Какой, например, процессор?

    Если это какое-то типовое решение, то дайте на него пожалуйста ссылку.

  5. Подобного рода фича есть у Xilinx. Они выпускают свои собственные ПЗУшки под названием PlatformFlash. Так вот у этих пзушек есть возможность записать несколько прошивок и

    потом выбирать через уровень на отдельных пинах какую ревизию грузить.

    Да, нужно именно такое решение, но для Альтеры и подешевле.

     

  6. Здравствуйте!

    Подскажите пожалуйста, как организовать, чтобы ПЛИС Cyclone IV в режиме Active Serial грузилась бы из разных областей EPCS в зависимости от положения DIP SWITCH.

    Наверняка для этого есть стандартные решения.

  7. Поясните ещё пожалуйста, почему для упаковки используется конструкция

    if (clk_video_input'event and clk_video_input = '1') then

    ,а для распаковки

     if (rising_edge(clk_video_output)) then

    Это просто погрешности написания или выдирания из какого-то источника или есть принципиальная разница?

     

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

    if (clk_video_input'event and clk_video_input = '1') then

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

  8. Всем спасибо!

    Меня эта ошибка в коде с толку сбивала.

    Завтра на железе опробую в Квартусе на СигналТепе оба варианта кода, надеюсь всё получится.

    По крайней мере я теперь понимаю как это работает.

     

  9. Спасибо!

     

    А почему вместо простого и понятного

    if (pack_cnt = "10") then
                pack_cnt <=  '0';

    сделано так:

    if (pack_cnt = "10") then
                pack_cnt <= (others => '0');

    Почему вместо '0' использовано others => '0' ?

  10. Понял, спасибо.

    Но всё-таки остаётся непонятным, почему при упаковке сигнал готовности данных "s_64bit_ready" выставляется уже при pack_cnt = "01"?

     if (pack_cnt = "01") then
    s_64bit_ready <= '1';

    Ведь при pack_cnt = "01" ещё не всё 64-битное слово сформировано?

  11. Спасибо, начинаю разбираться, , но остаётся непонятным, почему при упаковке сигнал готовности данных "s_64bit_ready" выставляется уже при pack_cnt = "01"?

     if (pack_cnt = "01") then
    s_64bit_ready <= '1';

    Ведь при pack_cnt = "01" ещё не всё 64-битное слово сформировано?

     

    Распаковка сделана в другом стиле. Видимо скопирована из другого места.

    Но в принципе же нет проблем сделать в таком же стиле как и упаковка?

    Ну или наоборот, упаковку сделать в том стиле, в котором сделана распаковка ( case unpack_cnt is ).

    Вообще какой стиль более правильный?

  12. В обоих процедурах есть похожие куски:

     

              if (pack_cnt = "10") then
                pack_cnt <= (others => '0');
    
            if (unpack_cnt = "10") then
              unpack_cnt <= (others => '0');

     

    Что они означают и почему они именно для значения счётчика "10" ?

    "10" - это в смысле 10b ?

    Как задаётся новая тактовая частота полученных при упаковке и распаковке потоков?

  13. В чипах Xilinx (не у всех) есть возможность после загрузку выключить JTAG вообще,

    что сделает невозможным чтение конфигурации\сканирование или вмешатетьство в работу через JTAG.

    А у Альтеры есть нечто похожее? Если да, то в каких семействах?

     

  14. Правильно ли я понимаю, что в Вашем квартусовском проекте есть система с ниосом, и кроме нее еще какие-то другие цифровые блоки?

    И Вас интересует, можн ли использовать имеющийся hex для ниосовской системы при внесении изменений в эти другие блоки?

    Да, именно так.

    Если я правильно протелепатировал, то таки да - имеющийся hex использовать можно, т.к. ни состав, ни распределение адресного пространстав в ниосовской системе не изменилось.

    Большое спасибо!

     

     

    для корректной работы вашего hex он должен быть собран с соответствующим вашей системе BSP., полученным из sopcinfo.

    т.е. если вы пересобрали sof с добавлением каких-то ещё блоков, но при этом не переделывали qsys-компонент, то следовательно sopcinfo и BSP будут те же. И, соответственно, уже собранный до этого hex "сломаться" не может.

    Это если код программы в On-chip Memory.

    Да, код программы в On-chip Memory.

    Спасибо, я понял!

     

     

  15. Что-то я не постиг глубину мысли.

    Если у Вас не изменяется ни программная, ни аппаратная части, то о каком "любом проекте" тут может идти речь???

    Судя по названию .sopcinfo описывает только QSYS (SOPC) часть проекта где и находится NIOS, для программы которого получен .hex файл.

    Если программная часть не меняется, QSYS (SOPC) часть проекта тоже не меняется, а меняется только та часть проекта, которая не затрагивает QSYS (SOPC), то значит ли это что я могу использовать полученный .hex файл не меняя его, хотя сам проект в целом поменялся?

  16. Мне в этой теме непонятно - насколько данный HEX-файл, описывающий программную часть проекта, является зависимым или независимым от аппаратной части всего проекта, ведь он получен в Эклипсе с использованием .sof конкретного проекта. Но при этом из этого проекта в BSP используется только .sopcinfo.

    Значит ли это, что я без проблем могу пользоваться данным HEX-файлом для любого проекта, в котором имеется та же самая программная часть при условии, что если я не буду менять QSYS-часть проекта ( в которой и находится On-chip Memory )?

  17. Это делается на совсем так.

    В NiosII EDS, в Project Expolrer'е выделяйте Ваш софтовый проект и щелкайте по нему правой кнопкой. В меню выбирайте пункт Make Targets - Build.

    Там выбираете mem_init_generate и жамкаете кнопку "Build".

    Hex-файл создается в папке с вашим софтовым проектом, в поддиректории ..\mem_init

    Добавьте файло meminit.qip из этой же папки в квартусовский проект и перекомпилируйте проект в квартусе.

    После заливки вновь полученного sof'а проект должен сразу завестись.

    Предыдущие свои вопросы удалил, наверное дальше сам разберусь.

    P.S. Да разобрался.

     

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