USB Blaster V2, кто-нибудь юзал? Опции

[rat]

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

[Raven]

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]

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

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

20нм и 14нм архитектура видимо "слишком другая", там похоже все сложно достаточно с безопасностью.
Еще одна причина перехода на низкую частоту это защита от неправильной записи NonVolatile ключа. На сколько я понял протокол записи ключа ключ обратно не вычитывается и если при записи произойдет сбой, то получится кирпич. Можно прочитать только регистр состояния.
По-поводу программной совместимости с кактусом, то протокол условно открытый за исключением авторских прав, сейчас не-понятно кому принадлежащих.
Возможно Интел что-то приоткроет . А если нет, то существует демократический способ. Тут вопрос надо ли это кому-то.
Сейчас есть шаблон драйвера под win64/win32, под linux не проверял еще.

[Raven]

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

Вот поэтому в Альтере и сообразили, что негоже такую чувствительную вещь ставить в зависимость от TCK period'а, генерируемого устройством, зависящим от USB (который далеко не верх надежности). Пользователь, хоть, может, и сам виноват в сбое, и даже сам это понимает, но понесет по жизни негатив об Альтере (если чип стоимостью несколько килобаксов превратился в кирпич). Оно Альтере нужно? Когда можно добавить небольшой контроллер на N килогейт, и решить проблему.

По-поводу программной совместимости с кактусом, то протокол условно открытый за исключением авторских прав, сейчас не-понятно кому принадлежащих.
...
Сейчас есть шаблон драйвера под win64/win32, под linux не проверял еще.

А вот это что-то новенькое. Протокол аппаратной части действительно хорошо известен со времен немца Коли, а вот API DLL'ки, более или менее задокументированного, я пока не встречал. Не поделитесь?

ну на http://marsohod.org вон свой программатор mbftdi как-то в кактус запилили.
и там тупо ft2232h, без дополнительной цплд, ибо преобразовывать USB в последовательный интерфейс сама умеет в отличии от ft245 в оригинальном первом бластере.

Свою DLL-ку написали, предварительно похатчив оригинал. Это, конечно, самый правильный путь, т.к. открывает самые широкие перспективы (потому у меня и возник интерес - см. выше). Вопрос только в точности вскрытия API. Кстати, а они где-нибудь этой информацией с широкой общественностью делились?