Jump to content

    

dxp

Свой
  • Content Count

    3621
  • Joined

  • Last visited

Community Reputation

0 Обычный

1 Follower

About dxp

  • Rank
    Adept

Информация

  • Город
    Novosibirsk

Recent Profile Visitors

8193 profile views
  1. Тёплая ламповая медяшка из бескислородной меди.
  2. Вопрос по #include

    Если совсем точно, то #include "" ищется сперва в директории, где находится исходный файл, содержащий директиву включения, а затем по всем остальным путям, указанным компилятору в качестве поисковых для включаемых файлов (обычно это опция командной строки -I ...). А #include <> ищется разу по поисковым путям, минуя директорию текущего исходного файла. Такое разделение сделано для оптимизации поиска: библиотечные заголовки как правило лежат по своим путям и поэтому нет смысла их искать в директориях проекта, поэтому такие файлы лучше заключать в <>. А заголовки проекта как правило лежат прямо тут же рядом с с/срр файлами, поэтому их надо заключать в "".
  3. Вероятно вы будете удивлены, но биполярные транзисторы тоже управляются напряжением, а ток базы - это [в большинстве случаев] нежелательный побочный эффект.
  4. По ссылке немного не про это, там про то, что есть два способа характеризации времянок, один используется в ISE, второй - в Vivado. В первом случае значения указываются по отношению к границе слайса, т.е. сигнал проходит через LUT и другие цепи, а во втором - по отношению к самому флопу. Из значений в таблице выше следует, что это по всей видимости всё-таки второй способ - уж слишком малое значение 0.09 нс для задержки от границы слайса (там только задержка на LUT больше сотни пс). Кстати, тут (из таблицы) возникает ещё вопрос: вот если взять флоп как таковой, то его окно сэмплирования должно быть всегда одинаковым, т.е. не должно зависеть внешних цепей, а в таблице в первой строке окно получается 0.09 + 0.14 = 0.23 нс, а во второй - 0.07 + 0.21 = 0.28 нс. С чего тут разница-то может возникнуть. Ну, а что они там в третьей строке привели, вообще загадка. Может кто-нибудь объяснить?
  5. Судя по доке, похожее на 0.076 нс значение есть для прямых (AX-DX) входов. 0.033 как-то никак не получается. Правда, там флопы в слайсе тож чуть разные (с функцией защёлки и без), может это как-то влияет. Но в даташите разницы по времянкам для них не вижу.
  6. Это почему это? Компилируется весь проект - и синтезируемая часть, и несинтезируемая. Т.е. не текущий открытый файл в редакторе, а все файлы, включенные в проект.
  7. Запустить компилятор (этих программ) в консоли. Я компилирую проект для симулятора прямо из редактора (нажав хоткей), в котором работаю с исходниками. Компилятор симулятора запускается и отрабатывает очень быстро (в отличие от компиляторов синтезаторов, которые запускаются сами по себе дольше, чем симуляторный компиляет проект), и если есть ошибки, то редактор позволяет быстро (по хоткею) переходить к месту ошибки (это штатная фича любого приличного программерского редатора).
  8. Не препроцессор, но генератор кода: COG.
  9. Доступ к регистрам

    Обращаться как к памяти, преобразовав адреса через mmap, я умею (и из Си, и из Питона получилось). Но речь шла именно о командах in/out, которые из userspace дают возможность добраться до регистров периферии, что вроде как заявляется как предпочтительным способом работы с периферией вместо того, чтобы городить интерфейс через драйвер. И вот не ясно, как в описанном выше случае это сделать. Насколько я понимаю, в моём случае этого сделать нельзя, т.к. in/out - это интерфейс работы через порты ввода-вывода, а они определены для ограниченного перечня устройств (типа стандартных COM/LPT портов), и в общем случае для произвольного периферийного устройства их нет. Поэтому либо через отображение памяти, либо через API драйвера. Так?
  10. Поддержу уважаемого blackfin. Он не имел в виду, что 4 артикса заменяют один вёртекс. В общем случае. Конечно, вёртекс быстрее, и по скорости это как минимум не замена. Но в задаче было озвучено, что скорости там и нет, просто много каналов и нужна логическая ёмкость. И второе замечание про организацию связи между ПЛИС в рамках этой задачи тоже не обосновано - сказано, что просто сотни каналов, связи между каналами не прослеживается, поэтому они все ложатся в разные микросхемы и ничего "не знают" друг о друге. Поэтому по технике и экономике (если нужно экономить) вариант blackfin очень здравый.
  11. Т.е. у вас поток на этой штуке порядка 8-10 Гбит в секунду?
  12. Возможно, HLS решит часть этим проблем.
  13. +1 Точно так - сразу нашёл в процессе знакомства с возможностями окна Device.
  14. Я понял. Возможно, это вопрос предпочтений. Лично я не доверяю этой автоматизации, предпочитаю, чтобы было явно. Ну, и справедливости ради, часто возникают такие задачи? Когда с подобным столкнулся (PCIe корка, где эн экранов список портов), просто написал обёртку вокруг этого модуля, внутри которой замапил нативные порты на сигналы интерфейсов, в итоге на прикладной уровень торчит всего четыре интерфейса (четыре строчки). Жизнь изрядно упростилась.