Beby

Использовать RAM Disk надо уметь, а, к моему глубокому сожалению, подавляющее большинство людей не хотят понимать, как его можно удобно использовать. Поэтому, в большинстве случаев, проще сказать использование RAM Disk’ка - это "знатное извращение", чем долго и нудно доказывать, его преимущества - кому надо, и так всё услышит и призадумается... Однако отмечу, что мне весьма отрадно слышать, что есть ещё люди, активно пользующие такие «технологии».

Можно хранить рабочие проекты и на SSD, и на HDD, естественно файлы будут быстрее читаться с SSD. Вопрос надёжности любого носителя необходимо решать регулярным резервным копированием, желательно ещё и частым - чтобы в случае проблем можно было недалеко откатиться. Проблемы могут быть обусловлены, как надёжностью носителя, так и какими-либо ошибками разработчика, а также и кривизной сред разработки. Конечно, можно хранить большие рабочие проекты и на HDD, но в случае использования NTFS, для достижения хорошего уровня быстродействия, потребуется, как следует посношаться с различного рода оптимизационными процедурами. Что, в свою очередь, не избавляет от необходимости проводить регулярное резервное копирование. Поэтому проще сразу использовать хороший SDD для хранения как операционной системы со средами разработки, так и для рабочих файлов проектов. Если на машине «много» ОЗУ, можно заняться знатным извращением: начать использовать RAM Disk, но одно неловкое телодвижение или зависание системы - и данные с RAM Disk’а безвозвратно пропадают. В своё время ASUS предлагал Gamer’ам использовать ASUS ROG RAMDisk для увеличения ресурса жизни SSD: образ игры, находящийся на SDD, при старте системы быстро загружается в ОЗУ машины, и далее работа идёт только с ОЗУ, при остановке операционной системы изменения записываются на SDD. Необходимо отметить, что записываются только изменённые фрагменты образа, что значительно экономит время и количество циклов записи на SSD.

Нет, не могу сказать, т.к. это очень сильно зависит от реализованной на CLB схеме. Для нашей типовой тестовой задачи количество потребляемых ампер можно грубо оценить как индекс Virtex-5/6/7 делённый на 10. Например, для XC7VX485T это будет 48.5 А. Очень тяжело оно живёт без радиаторов, только разработчикам можно выполнять базовые короткие и маложрущие тесты (памяти и связей) и при очень сильном воздушном потоке. Обычно такой режим используется при ремонте платы после замены одной из ПЛИС. Естественно, это было фото платы со снятым радиатором, ибо с радиатором ничего не было бы видно: Обычно у MMCM Jitter и Wander значительно больше, чем у внешних специализированных PLL. Степень чреватости, в свою очередь, определяется конкретными значениями Jitter, Wander и параметрами потока передаваемых данных.

Точные параметры назвать не могу, но основное потребление в XC7VX485T происходит в CLB (LUT+FF), более 90% коих работает на частоте более 300 МГц. Ну вот напримет на этой плате: :rolleyes: "Покупайте наших слонов." :rolleyes:

Это больше вопрос к Xilinx, что и как именно у них так потребляет. Может, конечно, в MGT и можно чего-нибудь подкрутить, чтобы чутка меньше ело и грелось,.. но на фоне потребления по VCCint: в пол сотни (и более) ампер, нам показалось, что эти цифры весьма адекватны и, при необходимости, нами реализуемы. На всякий случай поясню цифры, т.к. при вечернем просмотре своего же сообщения показалось, что мысль выражена неоднозначно: MGTAVcc (1.0В): 250мА/Lane; MGTAVtt (1.2В): 275мА/Lane; Итого при полностью использованном Quad (4 Lane): MGTAVcc (1.0В): 1.0А/Quad. MGTAVtt (1.2В): 1.1А/Quad.

GTX Transceiver K-7/V-7 с параметрами: - 8 Гбит/с; - Eye Scanner включен; - Output Swing 1,018V (1100); - TX Pre-Cursor 1,67dB; - TX Post-Cursor 0,68dB; - Data Pattern PRBS-7; - RAW Data 40bit. Поочерёдно загружались прошивки для 1, 2, 3, 4 Lanes: MGTAVccaux (1.8В) - 50мА/Quad. MGTAVcc (1В) - 250мВт(250мА)/Lane; - 1А/Quad. MGTAVtt (1.2В) - 330мВт(275мА)/Lane; - 1,1А/Quad.

Будьте осторожны - так можно и ПЛИС сжечь... у Kintex-7 относительно мало ножек VCCint, и Вы можете легко преодолеть лимит предельного потребления тока. Для большой прожорливости проекта можно сделать длинную вереницу инверторов с триггерами и уложить это всё колбасой внутри ПЛИС: Toggle Rate будет 100%. А при большом желании можно достичь и 100% использования CLB LUF+FF (по 4+8 на CLB). Как при этом использовать BRAM и DSP - отдельный вопрос, но, думаю, тоже можно что-либо сделать, если на входы данных (адреса) BRAM и DSP подавать какую-то бредятину с инверторов, а выходы BRAM и DSP могут и в воздухе висеть (их подключенность не будет влиять на потребление самих BRAM/DSP). Но думаю, что трогать DSP и BRAM Вам не потребуется, т.к. полученной прожорливость на CLB FF при должной частоте, вполне хватит, что ПЛИС стала необратимо повреждённой

Вопрос какой-то у Вас неконкретный, не указаны: ни тип ПЛИС (FPGA/CPLD), ни производитель, ни семейство ПЛИС. Однако же попробую умеренно конкретно ответить. Для FPGA Xilinx 7-го семейства Artix-7/Kintex-7/Virtex-7 в I/O Block'ах используются 2 вида входных буферов: униполярные и дифференциальные. Униполярные буферы питаются от VCC (для HP от 1.2В до 1.8В, для HR от 1.2В до 3.3В), дифференциальные - от VCCAUX (только 1.8В). Соответственно, на диф. вход крайне вредно подавать что-либо надолго превышающее VCCAUX. Стандарты, использующие Vref (например SSTL) используют дифференциальные входные буферы.

1. Пакеты широковещательные - значить запротоколировать их на любой машине в сети, например при помощи Wireshark, настроив его именно на вредоносные пакеты. 2. Показывать, log начальству: вот пакеты - вот проблемы / нет пакетов - нет проблем. 3. При необходимости показать в живую: вот валятся вредоносные пакеты -> вот проблемы,.. прервать поток вредоносных пакетов - и нет проблем. Log составить в любом случае - он как протокол вредительства и саботажа, поможет указать руководству, сколько рабочего времени и усилий (т.е. денег) было испоганено вредителем... тогда, глядишь, уже не фирма ему будет должна, а он ей (при увольнении).

Пока мне больше подходят NU 15, но есть и другие варианты - главное моё требование способность собрать дирректории, MFT и прочие служебные записи покучнее - чтобы всё это легче входило в кеш HDD/ОС. Отмечу однако, что NU 15 под разными ОС ведёт себя заметно по разному, и далеко не всегда дает адекватный результат (например, под Win7 по какой-то причине не определяется редко используемое файло, которое было бы неплохо свалить в конец раздела, а вот под XP такой проблемы нет...) Можно и с O&O повозиться - порой тоже даёт не плохой результат, но почему-то часто стремится размазать директории по всему диску (поближе к файлам в них описанных), возможно, в новых версиях это исправили, или сделали возможным перенастроить. Но повторюсь, дефрагментация - вторична, первично - состояние служебной информации (в т.ч. MFT). P.S. Если кто порекомендует навороченный дефрагментатор, с функционалом, приближающимся к NU SpeedDisk 2002 (прекрасно работавший в Win98/Me с FAT'ами), то буду благодарен. P.P.S. Для сжатия MFT пользую Paragon Partition Manager 12, за более чем 3 летний срок эксплуатации проблем не было ни разу.

Это результаты моих "частных", но "системных" наблюдении, проводимых непрерывно на протяжении более 15 лет, на десятках разных машин, с заметно разными CAD'ами, от Windows 2000 до Windows 7. Большой статистики (3 года и более на более чем 30 машинах) для Win 8.1 и 10 у меня пока нет, но т.к. NTFS в плане MFT / утилит по обслуживанию MFT не улучшался, то надежд на заметное улучшение ситуации - нет, правда есть небольшие улучшения за счёт большего объёма памяти выделяемой под дисковый кэш. Естественно есть ещё и наблюдения по разным FAT’ам, накопленные за более чем 20 лет, но, подозреваю, что они мало кому интересны. Наверняка, кто-нибудь тоже проводил подобные наблюдения/исследования - но я пока не натыкался на их результаты. Особо интересующиеся проблемами NTFS(MFT) могут ознакомиться с историей появления exFAT - может она наведёт на какие-то мысли... В принципе exFAT значительно проще (быстрее) NTFS, но это достоинство в значительной степени убивается драйверами Win-XP/7 (про Win 8.1 и 10 опять-таки умолчу, из-за временного отсутствия достаточной статистики). Если есть желание, то можно развить и обсудить эту тему. Но только сразу обращаю внимание: вопрос стоит не столько в плоскости дефрагментации (ныне сведённой к маразму), сколько в плоскости обслуживания и оптимизации служебных записей, при помощи которых, осуществляется навигация и доступ к файлам: т.е. директории, MFT и прочие атрибуты. Проблема в том, что MFT надо сжимать строго, после удаления большого количества файлов - т.е. сразу после удаления старой среды разработки, иначе практически заметной пользы уже не будет. Таки соглашусь, SSD очень хорошо скрадывает проблемы NTFS. Соответственно, при использовании SSD можно и не колдовать над дисками. А без backup'ов стрёмно как на SSD, так и на HDD,.. но на SSD всё же по стремнее будет: были уже с ними проблемы. Вопрос колдовать или не париться в большей степени стоит в денежной плоскости: цена денег в Москве и за 150-200км (не говоря уж про 1000км) от Москвы - существенно разная, поэтому работодатели существенно по разному смотрят на затраты на технику. И если могучие CPU/DDR достаточно легко обосновываются, то с остальными комплектующими бывают и накладки. Есть такая проблема, замечал, что на ряде материнских плат (в т.ч. дорогих ASUS), при установке 4 модулей памяти, BIOS сам (тихонечко) приподымал питания памяти на 0.05В, а VTT, соответственно, на 0025В. И если его принудительно сводить к «норме» (т.е. значениям прописанным в SPD) начинались глюки.

Для малых ПЛИС это верно, но если кто-либо планирует двигаться в сторону UltraScale или UltraScale+, 16 ГБ может вдруг стать недостаточно - проверено. Однако, если не надо работать с монстровидными ПЛИС, то лучше использовать 16 ГБ хорошей памяти, т.к. её гораздо проще найти, чем 32 ГБ. Да SSD штука быстрая... но не всегда надёжная. Если вопрос стоит в скорости работы Windows с NTFS разделами, то можно немного поколдовать на новой машине и проблем будет значительно меньше. Основной проблемой NTFS является MFT, хранящая служебную информацию о файлах. Чтобы Windows нормально работал, необходимо, чтобы MFT системного раздела был минимальный, следовательно, необходимо чтобы на этом разделе было как можно меньше файлов и директорий. Поэтому ставить монстровидные среды на системный раздал HDD (и SDD тоже) крайне черевато для нормальной работы Windows. Посему рекомендую для гадких программ завести отдельный(е) раздел(ы) диска(ов). Для HDD не забыть проводить дефрагментацию этих отдельных разделов хорошими дефрагментаторами. Также крайне полезно периодически проводить сжатие MFT, в особенности после удаления файлов.

Как было отмечено ранее, основное влияние (не менее 80%) оказывает частота процессора. Для Intel процессоров в большей степени необходимо учитывать нормальную максимальную частоту, нежели Turbo boost, т.к. по ряду причин CPU не может долго находиться в Turbo boost режиме. На сегодняшний день, как отметил _4afc_, лучшим вариантом будет i7-6700K с 4 ГГц номинальной частоты и TDP 91W, в Turbo boost режиме получим 4.2 ГГц и более TDP 100W. Необходимо будет озаботиться и очень хорошей системой охлаждения такой системы, т.к. охлаждать надо будет не только CPU, но и расположенные вокруг него компоненты, в особенности систему питания и модули памяти. От адекватной работы системы охлаждения будет зависеть продолжительность работы системы на большой частоте, в противном случае система будет впадать в локальные кратковременные параличи. В нормальных материнских платах (которые смогут питать i7-6700K) запрос на «паралич» может посылать не только перегревшийся процессор, но и другие компоненты системы, например система питания. Подробные характеристики i7-6700K см. тут Касательно памяти и Intel CPU: Сейчас 128 Гб ОЗУ можно вкрячить только к Xeon или Core Extream (тот же Xeon) процессорам. Последние desktop Skylake потянут только 64 Гб. Чтобы система не перегревалась и не деградировала необходимо брать ОЗУ только с номинальным напряжением питания (для DDR4 это 1.2В), в тоже время брать тормозную память тоже не хорошо. Официально i7-6700K поддерживает из DDR4 только 1866/2133. Xeon и Core Extream можно брать только если есть необходимость одновременной компиляции нескольких проектов на одной машине, в противном случае никакого выигрыша не будет. Также желательно разгрузить контроллер памяти, встроенный в процессор, от "левых" задач; например не использовать встроенную в Core i-3/5/7 видеокарту. Возможно, при компиляции ISE'ом одного проекта будет некоторый прирост, если отключить Hyper Threading.

Угу, ещё бы к этой Vivado 2016.2 новое лекарство бы прилагалось, вообще бы цены не было ! А то старое лекарство что-то подвыдохлось...

Угу, только в моём случае машинка будет стоять на рабочем месте,.. а если она будет меня сильно напрягать шумом, то производительность моего труда заметно снизится. В т.ч. увеличится коэффициент ошибок, на отлов и исправление которых потребуется время. Поэтому для охлаждения CPU я не могу поставить ревущую корову. P.S. в настоящее время я пользуюсь Zalman CNPS8900 Quiet - работают тихо и легко охлаждают Ivy Bridge i5-3570K даже при полной нагрузке. Ничего лучше по тишине/охлаждению (с подобной конструкцией) я пока не нашёл и в новую систему тоже планирую поставить этого зверя. Для желающих поставить такой же себе обязан предупредить - радиатор алюминиевый и покрыт чем-то вроде меди, но через какой-то промежуточный слой (никеля что ли ?), поэтому может отслаиваться и проникать в матерински плату в виде проводящей фольги ! Я уже потерял 2 таких радиатора отработавших по 1.5-2 года (гарантия производителя - 1 год), еще два (отработав по 2 года) держаться молодцом. Если кто может посоветовать тихую чашеобразную PWM систему охлаждения CPU, которая будет лучше по охлаждению/шум чем Zalman CNPS8900 Quiet, буду благодарен. P.P.S. Чтобы не возникало странных вопросов, сразу уточню, что сейчас у меня на рабочем месте Core2Dou E8600 c 4Гб DDR2 800, который и необходимо обновить.

Вчера наткнулся на IXBT: Процессоры Intel Core i7-4820K и Core i7-4960X Extreme Edition и что-то закрались у меня сомнения по поводу целисообразности Socket-R (2011): 1. В данной статье показано, что по их методике тестирования в однопоточных приложения Intel Core i7-4820K (Ivy Bridge-E) аналогичен Core i7-3770K (Ivy Bridge QC, 1155). А i7-3770K (Ivy Bridge QC, 1155), в свою очередь, заметно уступает Core i7-4770K (Haswell QC, 1150). 2. Удалось найти, что разрабатываемый Haswell-E будет иметь другой Socket (2011-3), и не будет совместим с Ivy Bridge-E. В следствии вышеизложенного, на настоящий момент мне кажется целесообразным взять что-то из Haswell'ов: есть подозрение, что лобовая производительность обновлённых ядер будет полезнее, чем большая пропускная способность памяти. Вопрос только в том - что (тыц) ? С одной стороны в *K процессорах можно приподнять множители, с другой стороны они не поддерживают некоторые "технологии". Может у кого-нибудь есть соображение: насколько эти технологии будут востребованы и полезны ? Далее выбор стоит между Core i5 и i7: 1. ISE/Vivado распараллеливается слабо, и от дополнительных 4 HT-ядер выигрыш мною почему-то просматривается слабо (может чего-то не замечаю ???). 2. Есть подозрение, что i5, имея меньшее число транзисторов внутри, будет дольше работать в режиме turbo boost, чем i7 - т.е. «разгон» будет длиться дольше и приносить больше пользы. С другой стороны, в нормальных BIOS можно отключить HT ядра в i7 и получить очень близкое тепловыделение + немного cache. У кого какие мысли, соображение и советы имеются ? P.S. Crystal Well из рассмотрения пока выпали... т.к. они, заразы, поставляются только в BGA корпусах... - и в мамки их пока не воткнуть.

Если ISE/Vivado что-то подобное и умеют, то это хорошо скрыто. Но я о другом говорил: если пользоваться встроенной «видюхой» в Crystal Well или Haswell, то она будет занимать часть пропускной способности системной памяти. А в Crystal Well еще и часть ёмкости встроенной 128MB ОЗУшки уйдёт на обслуживание этой «видюхи». Вот чтобы больше ресурсов досталось ISE я не собираюсь использовать встроенную в CPU «видюху». Э-э-э... Что-то я не соображу: Ivy Bridge E i7-4820K вроде же имеет Socket FCLGA2011, а у Вас указан 1150. Опечатка ?

Мучаюсь аналогичным вопросом: какой PC взять, чтобы ISE бодрее компилировал ? Основные кристаллы: "маленькие" Virtex-6/7/U, аналогичные Kintex-7/U. В моих проектах эти кристаллы полупустые - так случилось, что пока я не отлажу свою часть, погружать в эти кристаллы другие фрагменты - бессмысленно. Запускать параллельно с разными Cost Table тоже необходимости нет, правда, иногда (в 5-7%), бывает необходимо откомпилировать параллельно несколько проектов. Покопавшись на сайте Intel я выделил следующие CPU: Intel ARK: Brutal CPU Compare Теперь возникают вопросы: 1. PC на каком CPU (Crystal Well, Haswell, Ivy Bridge E) будет давать меньшее время компиляции одиночного проекта ? 2. в чём будет разница при использовании Socket 2011 (4xDDR3 1866) и Socket 1150 (4xDDR3 1600) ? 3. будет ли существенно отличаться работа CPU на Socket 2011 от CPU Socket 1150 в смысле шума системы охлаждения ? - машина всё-таки на рабочем месте будет стоять... При любом CPU планируется использование видеокарты. У кого какие есть мысли, соображения и советы на эту тему ?

Для расширения кругозора: ОАО «Морион» СПб - вдруг да пригодиться.

Тут всё зависит от нюансов, но если Вам нужен только bitstream, то Вы и должны платить "только" за bitstream - ну Вы же не покупаете ворох прав на использование патентов при покупке компьютеров (как бытовых, так и встраиваемых в Ваши изделия). Другое дело, что при создании Вами приобретаемого bitstream'а создателям может понадобиться какое-либо стороннее платное ядро, тогда цена этого ядра будет полностью (или частично) погружена в цену Вами приобретаемого bitsrteam'а.

Ну тогда начнём с аллегории: да тут даже и не скажешь, что неправильного в забивании гантелей (ну или гирей) гвоздей... вроде даже быстро и добротно забиваются, но что-то не то. Вы выбрали Spartan3e, т.е. FPGA. В этом классе ПЛИС практически нет логических элементов (за исключением фрагментов логики быстрого переноса), зато в наличии имеется широкий спектр статических элементов памяти и мультиплексоров + к этому всему некоторые специализированные аппаратные блоки (выполняющие только узкий спектр действий, но с малыми задержками, например встроенный умножитель). Т.е. вся ваша схема в ПЛИС реализуется на статическом ОЗУ 3-х степеней интеграции (плотности): 1. DFF - 1 бит ОЗУ, 2. LUT4 - 16 бит ОЗУ, 3. Block RAM - 18 Кбит ОЗУ. Использовать 2/4 LUT для реализации одного триггера, мне представляется нецелесообразным. Обычно содержимое LUT задаётся при конфигурировании ПЛИС, но в FPGA Xilinx для LUT в SliceM (а их около 1/4 от общего количества Slice'ов) есть возможность изменять оное содержимое, переведя LUT в режим Distributed RAM или Shift Register. Ну вот, иcходя из этих соображений и проектируйте Ваши схемы и устройства. Если очень сильно хочется бодаться именно с асинхронной схемой с обратными связями, то используйте временное моделирование, т.е. моделируйте с учётом задержек в связях и элементах.

Если я не ошибаюсь, то проблема в том, что ISE 12.4 вышел в 2010Q4, и, похоже, что Synplify F-2011.09 в то время еще не существовал.

Да чего ж тут сложного-то ? Вы всего лишь утверждаете, что с pipelining’ом схема сможет работать на большей частоте. Ну, сможет - и что ? (Этот факт, как раз, никто и не оспаривал) Но у pipelining есть свои недостатки, поэтому он не везде применим. Первичный-то вопрос стоял не в целесообразности применения pipelining'а, а «как сделать так, чтобы было побыстрее, да еще и без pipelining». И, кстати, схемы без pipelining'а, как правило, обладают меньшей латентностью (в нс), чем работающие на большей частоте pipeline схемы. Посему, в каждом конкретном случае приходится выбирать, что критичнее: латентность или частота - универсального ответа - нет.

К сожалению, Вы ошибаетесь: не совсем то сравниваете: 1. TITO (An – Dn inputs to A – D Q outputs) - это задержка от изменения входов LUT до появления устойчивых данных на выходе Slice (актуально для первого LUT'а Вашей схемы). А второй LUT вашей схемы, если я ничего не путаю, описывается TILO (An – Dn LUT address to A = 0.07ns) + TDICK (A – D input to CLK on A – D Flip Flops = 0.36ns), итого 43ns. 2. TRQ (Delay from SR input to AQ – DQ flip-flops) - это задержка реакции триггера на асинхронный Reset (задержка от прихода SR до изменения Q триггера). А Вам нужно TSRCK (SR input to CLK on A – D Flip Flops = 0.44ns) - время предустановки для SR входа. Т.е. получается, что разницы практически нет... Если я нигде не ошибся. Также необходимо учитывать, что использование LUT -> MUXF7 (или MUXF8) -> D вход триггера может дать более интересный результат. Для каждого семейства ПЛИС необходимо проверять всё это в Timing Analyzer'е, ибо не всё можно рассчитать по данным из Data Sheet, да и он ошибается значительно реже, чем сам разработчик.

Да, можно подавать данные с выхода LUT на синхронный вход SR триггеров. Но только на синхронный SR, если не хотите поиметь кучу проблем с асинхронщиной. Более того, при синтезе сложных логических функций синтезаторы периодически сами синтезируют схемы в которых используются D, CE и SR, на которые подаются сигналы с выходов LUT'ов. Да, скажется, но практически незаметно. Но зато может позволить реализовать очень вычурную логическую функцию с Logic Level = 1. Единственным существенным (для Xilinx V-5/S-6 и более новых) является наличие уникального набора CE, SR, CLK, что с большой долей вероятности приводит к невозможности использования остальных триггеров в Slice. Но, иногда, даже такие жертвы - оправданы.