[rat 0]

День добрый. На новом месте работы озаботился USB Blaster-ом для работы с Альтеровскими ПЛИС. По цене приемлимо выглядит http://www.waveshare.com/usb-blaster-v2.htm . Кто-нибудь юзал? Можно такой брать?

[DimaG 0]

День добрый. На новом месте работы озаботился USB Blaster-ом для работы с Альтеровскими ПЛИС. По цене приемлимо выглядит http://www.waveshare.com/usb-blaster-v2.htm . Кто-нибудь юзал? Можно такой брать?

 

С большой вероятностью внутри или FT245, или МК с USB интерфейсом.

JTAG организуется софтово, больших скоростей (и надежности работы) вряд ли удастся достичь (сужу по китайским клонам).

Если покупаете для работы, рекомендую UBR Iso (клон оригинального альтеровского программатора + гальваноразвязка), он на порядок дороже, но на два порядка лучше.

[StewartLittle 41]

И таки да, "V2" в названии сего изделия может ввести в заблуждение. Это клон обычного USB Blaster'а (а не USB Blaster II).

А хотелось бы иметь именно клон USB Blaster II - это машинка куда как посерьезнее означенного поделия.

Ну, даст Бог - сделаем :)

 

С большой вероятностью внутри или FT245, или МК с USB интерфейсом.

Если глянуть по указанной ссылке, то там написано "FT245 + CPLD". Т.е. вариант штатный.

 

[Raven 8]

О разнообразии внутреннего мира китайских USB Blaster'ов можно судить по следующим линкам:

Link 1

Link 2

После того, как немец Коля и японский человек Satoshi сделали свои варианты этого бластера, и алгоритм работы ушел в народ, каких только вариантов не делают! :)

[Flood 12]

И таки да, "V2" в названии сего изделия может ввести в заблуждение. Это клон обычного USB Blaster'а (а не USB Blaster II).

А хотелось бы иметь именно клон USB Blaster II - это машинка куда как посерьезнее означенного поделия.

А чем хорош (оригинальный) USB Blaster II по сравнению с (оригинальным) USB Blaster?

[StewartLittle 41]

А чем хорош (оригинальный) USB Blaster II по сравнению с (оригинальным) USB Blaster?

1. Быстрый (USB 2.0 High Speed)

2. Позволяет управлять частотой TCK.

3. Позволяет прошивать в ПЛИС ключи для дешифровки криптованной прошивки (ekp-файлы).

+ для совместной отладки SoC'ов рекомендуют именно его.

[dvladim 0]

3. Позволяет прошивать в ПЛИС ключи для дешифровки криптованной прошивки (ekp-файлы).

Если можно, поясните пожалуйста этот пункт. Просто я всегда считал, что JTAG это DRSCAN и IRSCAN, а всё остальное дело команд и их интерпитации. Т.е. от железа не зависит.

[jks 0]

Если можно, поясните пожалуйста этот пункт. Просто я всегда считал, что JTAG это DRSCAN и IRSCAN, а всё остальное дело команд и их интерпитации. Т.е. от железа не зависит.

 

After issuing the VOL_KEY_LOCK instruction, the controller cycles the JTAG state machine to the RTI state

and waits in this state for 10 μs. After a minimum of 10 μs in RTI, the controller cycles the JTAG state

machine to test logic reset. The device must be reconfigured for the volatile key lock fuse to take effect.

 

After issuing the VOL_KEY_SECURE instruction, the controller cycles the JTAG state machine to the RTI

state and waits in this state for 10 μs. After a minimum of 10 μs in RTI, the controller cycles the JTAG

state machine to test logic reset. You must reconfigure the device for the volatile key secure fuse to take

effect.

 

Для программирования постоянных ключей (NonVolatile) и фьюзов необходимо строго выдерживать тайминги при записи, как в старых ЭСПЗУ.

В новых бластерах есть возможность менять частоту клока TCK при обмене по JTAG. Устанавливается частота 100 кГц.

Подробности в an680.

 

 

 

[rat 0]

UPD. Конкретно интересует возможность работы USB Blaster V2 с Cyclone IV.

[StewartLittle 41]

UPD. Конкретно интересует возможность работы USB Blaster V2 с Cyclone IV.

Ну, тут все зависит от того, что подданные Поднебесной в этот бластер запихнули :)

Скорее всего работать будет.

JTAG - он и в Африке в Cyclone IV JTAG.

[dvladim 0]

У этих китайских клонов есть неприятный глюк (касается клонов на SILABS):

когда подаёшь длинный DRSCAN (именно одним куском), то где-то посередине данные сбиваются. Легко проверяется на BYPASS.

Оригинальный Blaster такой проблемы не имеет.

[Raven 8]

когда подаёшь длинный DRSCAN (именно одним куском), то где-то посередине данные сбиваются. Легко проверяется на BYPASS.

Вполне может также быть проявлением плохого Signal Integrity. Сбивается всегда одинаково (в одном и том же месте, искажения всегда одни и те же?)

 

Для программирования постоянных ключей (NonVolatile) и фьюзов необходимо строго выдерживать тайминги при записи, как в старых ЭСПЗУ.

After a minimum of 10 μs in RTI, the controller cycles the JTAG state

machine to test logic reset.

Строгость какая-то ... нестрогая :) Поддержать подобное требование даже в фирменном USB Blaster (I) и его клонах на FT245+CPLD, где fTCK фиксированная - вопрос скорее желания [программистов и маркетинговых людей], чем физической возможности.

А за наводку на AN - спасибо (не попадало как-то в поле зрения).

[jks 0]

Строгость какая-то ... нестрогая :) Поддержать подобное требование даже в фирменном USB Blaster (I) и его клонах на FT245+CPLD, где fTCK фиксированная - вопрос скорее желания [программистов и маркетинговых людей], чем физической возможности.

А за наводку на AN - спасибо (не попадало как-то в поле зрения).

 

из AN556 - p9.

 

Сложно сказать насколько это жесткие требования.

Но если частоту фиксировать на 100кГц, то трудно будет работать с СигналТапом и прошивать долго.

Можно конечно выделить для прошивания ключей отдельный программатор.

В штатном варианте квартус меняет частоту клока динамически при конфигурации бластера.

Это надо подшаманить драйвер бластера чтобы он менял частоту.

 

Наводка:

jtagconfig --setparam JtagClock 1 100000 // установить

jtagconfig --getparam JtagClock 1 // получить значение параметра

 

У марсоходовского драйвера похоже нет такой функциональности. Но если есть желание, то можно подсобить.

 

ПС:

А вообще думаю, что пора уже замахнуться на USBlaster III на USB3.0.

Концептуально многопортовый JTAG до 100МГц, с возможностью прошивать FPPx8/x16.

Ну и параллельные порты или LVDS туда/сюда для подключения к плисине для закачивания/выкачивания данных.

А то по JTAG на малой скорости работать не всегда комильфо. Народный такой демократический вариант.

[Raven 8]

AN-556, p.5 содержит краткое, но емкое описание как причин текущего положения дел, так и перспектив:

(9) USB-Blaster support only volatile key programming except in 20-nm FPGAs, where it supports both

volatile and non-volatile key programming.

(10) For non-volatile key programming, you must regulate the JTAG TCK pulse width (period) for proper

polyfuse programming.

Т.е., первые варианты исполнения (до-20nm) имеют жесткую зависимость процесса программирования от продолжительности периода TCK, а последние и, думается, все последующие (20nm FPGA - это, как я понял, Arria 10) - от этой жесткой зависимости освобождены. Внутренний контроллер, видимо, сам генерирует импульс правильной продолжительности и не рассчитывает на такую ненадежную субстанцию, как TCK period. И он прав.

 

А вообще думаю, что пора уже замахнуться на USBlaster III на USB3.0.

Э-э-х, батенька, это как раз тот случай, когда не надо бежать впереди паровоза (то бишь, Alter'ы). Программную совместимость с Кактусом как вы думаете всему этому добру обеспечивать? Вот если бы Altera выпустила бы что-нибудь наподобие XVCD protocol specification, как у Хилых, тогда.... Мечты, мечты... :-)

[jks 0]

AN-556, p.5 содержит краткое, но емкое описание как причин текущего положения дел, так и перспектив:

Т.е., первые варианты исполнения (до-20nm) имеют жесткую зависимость процесса программирования от продолжительности периода TCK, а последние и, думается, все последующие (20nm FPGA - это, как я понял, Arria 10) - от этой жесткой зависимости освобождены. Внутренний контроллер, видимо, сам генерирует импульс правильной продолжительности и не рассчитывает на такую ненадежную субстанцию, как TCK period. И он прав.

 

Э-э-х, батенька, это как раз тот случай, когда не надо бежать впереди паровоза (то бишь, Alter'ы). Программную совместимость с Кактусом как вы думаете всему этому добру обеспечивать? Вот если бы Altera выпустила бы что-нибудь наподобие XVCD protocol specification, как у Хилых, тогда.... Мечты, мечты... :-)

20нм и 14нм архитектура видимо "слишком другая", там похоже все сложно достаточно с безопасностью.

Еще одна причина перехода на низкую частоту это защита от неправильной записи NonVolatile ключа. На сколько я понял протокол записи ключа ключ обратно не вычитывается и если при записи произойдет сбой, то получится кирпич. Можно прочитать только регистр состояния.

По-поводу программной совместимости с кактусом, то протокол условно открытый за исключением авторских прав, сейчас не-понятно кому принадлежащих.

Возможно Интел что-то приоткроет :laughing:. А если нет, то существует демократический способ. Тут вопрос надо ли это кому-то.

Сейчас есть шаблон драйвера под win64/win32, под linux не проверял еще.