AS - Cyclone iV handbook, page 8-12 (aka 176). PS - page 8-37 (201), table 8-12.

Да, согласен , и ещё на рис. 8-2 это обозначено.
Жаль, значит Cyclone IV GX и с EPCQ сможет работать только на 40 МГц


Если на EPC, то тогда остаётся вопрос - почему в Квартусе 12.1 нет EPC4 и других более старших Enhanced Configuration Devices в меню выбора дивайса в конверторе из sof в pof, а есть только старые EPC1 и EPC2?

Это скорее всего баг?

Честно скажу - EP4CGX22 для PCI-Express это очень странный выбор. По емкости слишком малый ИМХО.

Не проблема, есть PCIe платы и на EP4CGX15.
А вот с конфигурацией я пока что завяз
Посмотрим, что выбором дивайсов в Q 13.0 sp1 имеется.
Может компрессия поможет.
Скажите точно - есть ли компрессия в EPC и есть ли в EPCS?
А то я видел противоречивую инфу на эту тему.

в EPCS и EPCQ компрессия есть и работает.

Как тогда относиться к этому в заголовке даташита по EPCS?
On-chip compression support: No



И почему включение компрессии недоступно при выборе EPCS16?



Всё это баги Квартуса?

советую читать документ ровно как он есть, а не выдумывать всё что придёт в голову.

В данном случае здесь написано всего лишь про то, что сама микросхема EPCS производить декомпрессию не умеет. Этим занимается Active Serial загрузчик, в ПЛИС.

галочка "Generate Compressed bitstream" находится в Assignments -> Device -> Device and pin options.

Это я знаю, пробовал, но судя по инфе в *.map файле *.pof получается одинаково заполненным независимо от положения этой галочки.

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

зы. .jic и .pof насколько я понимаю всегда равен полному объему записываемой ROM.

Не уверен, разбираюсь с этим, видел противоречивую инфу.

А ещё посмотрите страницу 8-2 Configuration Handbook.
Там о включении компресии сказано, что оно делается как вариант всё же в Convert Programming File:
In the SOF File Properties dialog box, turn on the Compression option.
Да, нашёл это место , это не там, где я на скришоте обвёл!
И вот здесь компрессия реально сработала!!!
Вообщем я пока с большим запасом помещаюсь в EPCS4 размером 4 Мбита, а это значит на 40 МГц я смогу уложиться в PCIe wake-up time =100 мс.
Уффф!
Всем спасибо за помощь!

P.S. Компрессия реальная оказалась почти втрое!
А галочка "Generate Compressed bitstream" в Assignments -> Device -> Device and pin options реально не работает, по крайней мере в Q 12.1.

вы про это?

Запомните, в аглицких документах применяется 4 термина:
1) may
2) could
3) shall
4) must
в полядке увеличения ответственности.
За использование may можно вообще никакой ответственности не нести.
Если в документе написано must а вы это проигнорировали - эквивалентно расстрелу на месте.

Если переводить на русский - если компрессия по какимто причинам не работает - никого в Альтере это не волнует.
Например, если конвертер quartus_asm, GUI которого - "Generate programming files" - не позволяет перепаковать файлы без компрессии в файлы с компрессией - это тоже мало кого волнует; всех устраивает то, что он их умеет упаковывать при изначальном создании .sof

Сообщение отредактировал krux - Aug 5 2013, 19:46

Нет, смотрите предыдущий пост, я его поправил.
Я во всём разобрался и компрессия реальная оказалась почти втрое!

Не торопитесь радоваться пока. Для полноты картины выясните - а за какое время сжатый втрое файл распаковывается. И даже больше - сколько времени проходит от снятия reset'а до INIT_DONE, и далее до готовности работать на PCIe (или как там завершение wake-up определяется?..). Ведь даже при оптимистической оценке (4 Мбит - 40 МГц) все на краю или даже за пределами находится.

Ну, а если с этим все будет Ок, - очень с большим пиететом отнеситесь к разводке этих 4-х сигналов AS'а (а если подставите туда разъем - не забудьте диоды и конденсаторы). На 40 МГц с signal integrity не шутят, и это подтверждается парой совсем недавних тем на форуме (AS конфигурирование Cyclone iV).

Как это выяснить?
А если результирующий *.pof или *.jic с учётом компрессии по данным в *.map заполнен полезными данными лишь наполовину ( остальное забито 0xff ), то какое будет время загрузки - 100 мс или 50 мс?
Я думаю, что 50 мс, т.е реальное время загрузки EPCS определяется временем загрузки только полезных данных.
Иначе бы не работали реальные схемы на PCIe, в которых используется EPCS16.
Ведь если бы EPCS16 даже заполненная на 10% грузилась бы 16Мбит x 25 нс = 400 мс, то PCIe схема не заработала бы .

А если так, то у меня есть запас, т.к EPCS4 у меня пока заполнена лишь на 70%.
Но как вычислить время декомпрессии я хотел бы узнать, тк возможно заполнение вырастет и до 90% по ходу дополнения проекта.

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

Варианты:
1) глянуть документацию (может, где эта деталь и описана);
2) проверить на практике на идентичном или даже просто близком чипе - надо ведь проверить конкретный принципиальный момент;
3) спросить у StewartLittle

P.S. Завршение конфигурирования, конечно же, происходит по достижению конца действительных конф.данных, а не конца всей конф. памяти. Я имел в виду следующее: 4 Mb (размер уже сжатого вашего файла, как я понял) * 25 ns (40 MHz) = ~100 ms. Даже чуть больше. А ведь в этот момент ваша логика еще даже не проиницилизирована в смысле FPGA конфигурирования, а после оживления ведь тоже какая-то reset sequence возможна. Так что, строго говоря, спецификация PCIe оказывается нарушенной.