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

С большой вероятностью внутри или FT245, или МК с USB интерфейсом.
JTAG организуется софтово, больших скоростей (и надежности работы) вряд ли удастся достичь (сужу по китайским клонам).
Если покупаете для работы, рекомендую UBR Iso (клон оригинального альтеровского программатора + гальваноразвязка), он на порядок дороже, но на два порядка лучше.

И таки да, "V2" в названии сего изделия может ввести в заблуждение. Это клон обычного USB Blaster'а (а не USB Blaster II).
А хотелось бы иметь именно клон USB Blaster II - это машинка куда как посерьезнее означенного поделия.
Ну, даст Бог - сделаем


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

О разнообразии внутреннего мира китайских USB Blaster'ов можно судить по следующим линкам:
Link 1
Link 2
После того, как немец Коля и японский человек Satoshi сделали свои варианты этого бластера, и алгоритм работы ушел в народ, каких только вариантов не делают!

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

1. Быстрый (USB 2.0 High Speed)
2. Позволяет управлять частотой TCK.
3. Позволяет прошивать в ПЛИС ключи для дешифровки криптованной прошивки (ekp-файлы).
+ для совместной отладки SoC'ов рекомендуют именно его.

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

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

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

Ну, тут все зависит от того, что подданные Поднебесной в этот бластер запихнули
Скорее всего работать будет.
JTAG - он и в Африке в Cyclone IV JTAG.

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

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


Строгость какая-то ... нестрогая Поддержать подобное требование даже в фирменном 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 на малой скорости работать не всегда комильфо. Народный такой демократический вариант.

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

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


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

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

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

и толку от USB3? ограничения на частоту TCK начнутся гораздо раньше чем закончится пропускная способность high speed USB2.
даже для FPP, 30-40МБайт/с не особо-то ограничение

Тут идея состоит в том чтобы аппаратный JTAG использовать только при начальной конфигурации или каких-то аппаратных вещей типа граничного сканирования.
А для отладочных вещей типа SignalTap использовать выделенные линии LVDS.
Снаружи в ПК эмулятор SLD_HUB и внутри ПЛИС такой-же ответный но выведенный не на аппаратный JTAG а на выделенный интерфейс.
Потому-как VirtualJtag подсистема USER0/USER1 очень медленная и не удовлетворяет современным требованиям.

Как вариант можно использовать как логический анализатор или подключать внешние АЦП/ЦАП.
Такая мини система сбора данных. Можно еще подключить открытое ПО типа GTKwave итд.

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


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


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

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

Само собой, для такой масштабной задумки плясать следует от программного интерфейса. Когда я говорил про бег впереди паровоза, именно это я и имел в виду. Что не может быть поддержано в рамках известного API - лучше без особой нужды не мутить.

Выкладывать исходники пока рано, надо причесать в нормальный вид.
Могу выложить примерный драйвер - эмулятор. Пока под Win64.
Скопировать dll в папку bin64.
Нажмите для просмотра прикрепленного файла
Добавить драйвер
jtagconfig --add JTAG-Blaster JDBG9
Удалить
jtagconfig --remove <N>, N индекс устройства

В Quartus открыть окно программатора и выбрать устройство JTAG-Blaster.
В автодетекте должен появиться CycloneIII/IV EP3C6/10. Можно его прошить какой-нибудь прошивкой.
В меню tools выбрать Sources&Probes и запустить. Должны появиться виртуальные кнопки/индикаторы.

Тестировал в QUA 13.0 - 15.1 64bit.

исходники-то ладно,
а вот описание того, что должна вернуть get_supported_hardware() вы где взяли?

Начиная где-то с 11 версии лежит в папке исполняемыми файлами.
Не совсем в открытом виде, но разобраться можно и Альтера этому способствует.
как-то так.
Нажмите для просмотра прикрепленного файла

Да вот нет
Где-то в процессе буфер переполняется/сбивается.

Похоже, я далеко не в танке Под рукой Q13SP1, ничего похожего на файл с таким или подобным именем не нашел во всем поддереве. Видимо, совсем не в открытом виде :-) Или это только в Q11 было?

Этот файл это продукт интерпретации. Я имел ввиду файлы с расширением *.pdb для 32 битной версии. Там информации более чем достаточно.
Надеюсь что не открыл страшной тайны. Вообще я был уверен, что эна инфа уже давно находится Центральном Хранилище Артефактов, раз на марсоходе драйвера с 2011 года лежат.
Я доступа туда не имею пока пэтому не знаю что там и как.

за файлик спасибо.

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

не так давно разбирался с использованием jtag-uarta из своей программы, а не через nios2-terminal (через него как-то всё настолько медленно и печально было).
осталась масса "положительных" эмоций, хотя там оно ещё относительно незакрыто и даже исходники кое-какие найти можно.

Я вобще сначала пытался на TCL что-то делать, но потом плюнул и решил поискать что-то побыстрее.
Надо было найти какой-нибудь универсальный пограмматор для зоопарка для ARM/MIPS/FPGA.
В результате сейчас пользую blaster через Альтеровскую либу jtag_client.
Там есть полный функционал. И можно писать переносимое ПО под Win/Linux.


Была идея JLink с родным драйвером подключить, чтобы разъемы не переставлять каждый раз.
Не знаю насколько имеет смысл выкаладывать в открытый доступ либу и описание работы с ней?

Так и есть - не в танке я :-). Ну, не занимался я пока всерьез программным RE,- потому про *.pdb и не в курсе. Теперь уже поспрашивал у знающих людей и стало ясно, что это такой, можно сказать, эксгибиционизм Altera. Формально вроде документы/исходники не выкладывали, но для понимающих (тех, кто "в танке", уж извините, закончу с этим идиоматическим выражением :-)) они содержат массу информации о внутреннем устройстве программных модулей. Тем не менее, за вашим маленьким файликом стоит большая работа, так что - респект и большое спасибо.


Может, даже и лежит. Но там столько всего, и не всегда оно лежит в очевидном именно для вас месте... Так что аналогия с Хранилищем из "Индианы Джонса" вполне обоснованна :-).


Еще бОльшая уважуха и респект.


В открытый ли доступ - это, конечно, вам решать. Но лично мне это было бы интересно.

Не стал создавать отдельную тему. Но правильней наверное было бы разместить куда-нибудь в раздел САПР. Undocumented Quartus?
Исходный код модуля драйвера под Win32/Win64 и небольшой пример по использованию библиотеки jtag_client.
Компиилируется под MSVS.
Нажмите для просмотра прикрепленного файла

Только сегодня заметил. Большое спасибо! Буду разбираться.