[okela 0]

11 minutes ago, makc said:

В общем китайской документации верить нельзя ни в чём:

  --fsFile bitstream.fs, --fs bitstream.fs, -f bitstream.fs
                        Define the .fs file path.

С другой стороны непонятно, как он в случае bin проверяет соответствие между тем что и куда шьёт, ведь в заголовке bin эта информация отсутствует.

У них есть еще binx-формат. Это тот же bin-формат только с текстовой шапкой (как в fs-формате) вначале файла.

[sawanderer 2]

1 час назад, makc сказал:

В общем китайской документации верить нельзя ни в чём:

  --fsFile bitstream.fs, --fs bitstream.fs, -f bitstream.fs
                        Define the .fs file path.

С другой стороны непонятно, как он в случае bin проверяет соответствие между тем что и куда шьёт, ведь в заголовке bin эта информация отсутствует.

В принципе в содержимом .bin-файла включена  команда проверки id чипа (по которой при попытке ее загрузки в ПЛИС с id, не совпадающим с id чипа, ПЛИС должен устанавливать соответствующий бит ошибки в регистре статуса и заблокировать дальнейшую загрузку). Формат .bin файла правда насколько я понимаю нигде официально не описан, но сами-то программисты Gowin наверняка его знают и могут для проверки соответствия чипа до загрузки файла разбирать сам .bin файл, найти данную команду и узнать, для какого чипа был сделан данный .bin. Помнится в выкладываемом тут описании формата на основе реверс-инжиниринга такая команда проверки упоминалась.

[makc 192]

Только что, sawanderer сказал:

В принципе в содержимом .bin-файла включена  команда проверки id чипа (по которой при попытке ее загрузки в ПЛИС с id, не совпадающим с id чипа, ПЛИС должен устанавливать соответствующий бит ошибки в регистре статуса и заблокировать дальнейшую загрузку).

Это понятно, но определение корректности прошивки будет выполнено сильно позже, чем хотелось бы.

1 минуту назад, sawanderer сказал:

Формат .bin файла правда насколько я понимаю нигде официально не описан, но сами-то программисты Gowin наверняка его знают и могут для проверки соответствия чипа до загрузки файла разбирать сам .bin файл, найти данную команду и узнать, для какого чипа был сделан данный .bin. Помнится в выкладываемом тут описании формата на основе реверс-инжиниринга такая команда проверки упоминалась.

Теоретически - да, но как оно на практике - непонятно. В общем прошивать bin можно, но с моей точки зрения всё-таки лучше не искать себе приключений и использовать наиболее проверенный маршрут через fs.

[okela 0]

7 minutes ago, makc said:

Это понятно, но определение корректности прошивки будет выполнено сильно позже, чем хотелось бы.

Теоретически - да, но как оно на практике - непонятно. В общем прошивать bin можно, но с моей точки зрения всё-таки лучше не искать себе приключений и использовать наиболее проверенный маршрут через fs.

Если сравнить содержимое fs-файла и binx-файла, то по сути там будет одна и та же информация. Только в fs-формате она представлена в весьма расточительном (с точки зрения ресурсов) развернутом битовом виде.

[StewartLittle 41]

В 18.10.2023 в 12:45, makc сказал:

... но с моей точки зрения всё-таки лучше не искать себе приключений и использовать наиболее проверенный маршрут через fs.

Я так думаю, что тот, кто собирается прошивать ПЛИС микроконтроллером, точно знает, какая именно у него ПЛИСка, и бинарные файлы подготавливает именно для нее.

[okela 0]

В итоге после некоторой доработки напильником исходников OpenFPGALoader-а удалось скормить ему bin-файл и успешно прошить FPGA. Всем спасибо за помощь и советы при обуждении. 👍

[SM 0]

On 10/15/2023 at 10:29 AM, makc said:

Может генераторы SVF отличаются для разных ПЛИС одного семейства? Вы не сравнивали ваш SVF с описанием процесса программирования в документации?

Нет, не сравнивал. Зачем, если работает? Но могу точно сказать, что частота TCK должна соответствовать той, что задана при генерации SVF, и быть постоянной без пауз, равномерной - иначе всё ломается. При этом паузы между SVF-инструкциями, если они заполнены TCK, не маешают. Скорее всего OpenOCD не дает той частоты, что указана в SVF, или делает паузы в ней.

Могу сказать еще то, что SVF плеер от моих SAU510USB тоже всё шьет, если тактовая верная, а она в этом эмуляторе также непрерывная.

 

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

[SM 0]

On 10/15/2023 at 10:29 AM, makc said:

Вы не сравнивали ваш SVF с описанием процесса программирования в документации?

Теперь сравнил ради интереса.

100% соответствие с описанием программирования.

Сначала Flash Erase - в полном соответствии с "Figure 6-17 The Embedded Flash Erasing process of T Technology", включая "серые" блоки алгоритма. Только первая пауза не 500 мкс, а целая секунда.

Потом программирование - в полном соответствии с "Figure 6-19 Process of Programming Internal Flash View", только перед инструкцией 0x3A в самом конце прошивки добавлена пауза на 999 TCK.

 

1) Config Erase

 

2) Flash erase + Reprogram

 

3. Шьем страницы

 

4. ЗАкончили, config disable, reprogram, проверили статус.

[makc 192]

7 часов назад, SM сказал:

2) Flash erase + Reprogram

Генерирую SVF для GW1N-9C и на основании UG290-2.7.1E, 07/24/2023 процесс стирания должен выглядеть следующим образом:

Выделенный красным блок применим только для GW1N-4 и должен быть пропущен для всех остальных ПЛИС, если я ещё по-прежнему правильно понимаю английский язык. 😉
Однако в получаемом SVF и у меня, и у вас есть команда передачи 32 бит:

SIR 8 TDI (41);
SDR 32 TDI (00000000) TDO (00019020) SMASK (FFFFFFFF) MASK (0001FFFF);
SIR 8 TDI (15);
RUNTEST 5 TCK;
SIR 8 TDI (75);
RUNTEST 5 TCK;
SDR 32 TDI (00000000);
RUNTEST 10 TCK;
RUNTEST 225225 TCK;

Где здесь полное соответствие документации?

Далее, по документации после отправки команды следует ждать 120 мс (в тексте и на блок-схеме одного и то же значение), однако в получаемом SVF пауза 150 мс (на частоте 1,5 МГц). Это ещё одно несовпадение.

Следуя вышеприведённому тексту после команды 0x3A должна отправляться команда 0x02:

9. Send the "0x3A" instruction of Config Disable.
10. Send the "0x02” instruction of Noop to end the erasure process.
11. Send the "0x03” instruction of Reprogram to reconfigure the device
and check if it erases successfully.

Однако на блок-схеме ничего такого нет:

А в сгенерированном SVF всё ещё интереснее:

SIR 8 TDI (3A);
RUNTEST 5 TCK;
SIR 8 TDI (02);
RUNTEST 5 TCK;
SIR 8 TDI (11);
RUNTEST 5 TCK;
SIR 8 TDI (3A);
RUNTEST 5 TCK;
SIR 8 TDI (02);
RUNTEST 5 TCK;
SIR 8 TDI (3C);
RUNTEST 5 TCK;
SIR 8 TDI (02);

Т.е. команда 0x3A отправляется два раза, а не один, при этом в первый раз после неё добавляются команды 0x02 и 0x11, а во второй только 0x02. Где такой двойной проход описан в документации? Там сказано выполнить это один раз.

7 часов назад, SM сказал:

100% соответствие с описанием программирования.

Поэтому, к сожалению, мне видится что никакого 100% совпадения описания и фактического процесса программирования нет. Кроме того, мои эксперименты с захватом последовательности программирования ПЛИС через JTAG показали, что генерируемый SVF не совпадает с выполняемыми программатором действиями. Но, к сожалению, сейчас я это подтвердить не могу, да и нет в этом большого смысла в виду вышеописанных расхождений.

[SM 0]

On 10/28/2023 at 8:17 PM, makc said:

только для GW1N-4 и должен быть пропущен для всех остальных ПЛИС

Так у меня же GW1NSR-4C, там IDCODE виден, она относится GW1N-4 и этот шаг ей нужен.

В тексте есть ошибка - "Send the "0x03” instruction of Reprogram" - инструкция "Reprogram" имеет код 0x3C

А вот да, "лишнюю пару" инструкций 0x3A и 0x02 после 0x11 я не заметил, действительно, имеется небольшое расхождение. Тут можно их удалить, и поглядеть, сохранится ли работоспособность. Проверю.

 

On 10/28/2023 at 8:17 PM, makc said:

и фактического процесса программирования нет.

Как это нет??? Целый скриншот, где 0x15, 0x02, 0x71, и потом толпа SDR с данными, и таких кусков там 2.5 мегабайт

[makc 192]

1 минуту назад, SM сказал:

Так у меня же GW1NSR-4C, там IDCODE виден, она относится GW1N-4 и этот шаг ей нужен.

Но у меня не она и изначально я говорил про 9C. Для нее описание некорректно? Или некорректен SVF? 🤔

3 минуты назад, SM сказал:

В тексте есть ошибка - "Send the "0x03” instruction of Reprogram" - инструкция "Reprogram" имеет код 0x3C

Да, это явная опечатка. Такое я даже не рассматриваю.

4 минуты назад, SM сказал:

Как это нет??? Целый скриншот, где 0x15, 0x02, 0x71, и потом толпа SDR с данными, и таких кусков там 2.5 мегабайт

Я имел в виду, что нет 100% совпадения описания и реализации. Это не про скриншоты. И этого совпадения действительно нет, т.к. вы сами уже признали наличие лишних команд.

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

[SM 0]

On 10/28/2023 at 8:44 PM, makc said:

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

без них тоже шьет. То есть "как на блок-схеме" тоже работает. Прям сейчас попробовал стереть их из свф и прогнать его.

То есть, это косяк генерации SVF, ни на что не влияющий. Теперь именно на 100% соответствует документации, за исключением задержек.

 

Про 9С я не знаю, где косяк... У меня нет на ней ничего, проверить не могу.

 

On 10/28/2023 at 8:44 PM, makc said:

лишних команд.

И еще - Noop между 0x3A и 0x11 - тоже ни на что не влияет, без него работает. Это уже видимо унификация с "H" технологией, где этот Noop нужен.

 

А задержки с запасом - так это так и должно быть. У тактовой все таки разброс есть, TCK все таки не на OCXO генерируют.

[SM 0]

On 10/28/2023 at 8:44 PM, makc said:

я говорил про 9C. Для нее описание некорректно? Или некорректен SVF?

Для нее, согласно документации, вообще некорректно создавать SVF.

[makc 192]

1 час назад, SM сказал:

Для нее, согласно документации, вообще некорректно создавать SVF.

Вот это для меня немного неожиданно... Почему тогда среда его генерирует, если не поддерживает такую возможность? Вопрос риторический. 🤦‍♂️

15 часов назад, SM сказал:

А задержки с запасом - так это так и должно быть. У тактовой все таки разброс есть, TCK все таки не на OCXO генерируют.

Видимо самое главное это стабильность подачи TCK, т.к. это единственное глобальное отличие моего и вашего решений. Ваш таймер это гарантирует, а у меня стабильная генерация TCK идёт с помощью ШИМ только во время непосредственно выполнения стирания/программирования. И ещё более эту проблему усугубляет кэш команд моего МК, который иногда даёт непредсказуемые задержки. 😔

PS: Я правильно понимаю, что ваш таймер всегда генерирует TCK, а выдача на TDO и TMS идёт когда есть что выдавать?

[SM 0]

On 10/29/2023 at 11:11 AM, makc said:

PS: Я правильно понимаю, что ваш таймер всегда генерирует TCK, а выдача на TDO и TMS идёт когда есть что выдавать?

Таймер всегда генерирует TCK, а прерывание от его фронта умеет: "ничего не делать" N раз, если загружен счетчик. Иначе, если есть в большом буфере данное, то достает его оттуда, и согласно битам этого данного, если битом разрешено, то принимает бит с TDO со сдвигом в переменную, затем выдает TMS/TDO из других бит этого данного, и потом, если разрешено четвертым битом, грузит счетчик неактивности из того же буфера. Ну и совсем иначе - прерывание вообще ничего не делает.

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

вот как-то так. Лишние такты в RUN-TEST/IDLE ничему не мешают, да и не должны по спецификации жтага.