dxp

ИМХО always@(GCLK) по уровню :) (сколько себя помню всегда так было), а если по фронту то always@(posedge GCLK) это не ВХДЛ, always@(GCLK) - это по любому событию. По факту это соответствует комбинационной логике. В Верилог-2001 задавать список для комбинационных схем не требуется, можно просто писать always @(*) или always @*. Компилятор дальше сам разберется, что к чему исходя из контекста описания тела блока.

Там есть и в LQFP. До 500 МГц.

Точно так же - кипаутом нарисовать. Если надо только в одном слое, то разместить на полигоне объект с установленным крыжиком Keepout. В последних версиях появилось для этого специальное средство: Place->Polygon Pour Cutout, тут можно сразу вырезать кусок произвольной формы.

На Agilent нет таких нареканий, как на Instek, а проигрывает он только в объеме памяти :) Тут каждый решает сам, но я бы выбрал Agilent, естественно :). При данной альтернативе я бы тоже выбрал Аджилент, т.к. 1 ГГц на выборках мне важнее. К счастью, именно такая альтернатива передо мной не стояла и есть еще Лекрой, который про соотношению цена/возможности весьма впереди остальных. Мелочевку за 1 килобакс он не делает, а вот начиная от 5 тонн зеленых там уже есть дивайсы и они очень приличные.

MicroCap, PSpice, Spectre, прочие SPICE-симуляторы. Первый на мой взгляд удобнее всего. Я бы посоветовал PSpice, который входит в состав Orcad. Решатель там нормальный. Рисовалка замечательная. Да и до конца дело можно довести (печатка). MicroCap уступает в функциональности и удобстве, по-моему. Спайс (который в составе Оркада), к сожалению, не развивается. Сам пользуюсь им. Микрокап, слыхал, считает быстрее. Иногда это важно.

Не вполне адекватная замена. У Инстека памяти 125к, а у Аджилента этого всего 4к. А это очень важный момент. С другой стороны у Аджилента выборка 1 ГГц, а у Инстека, насколько помню, всего 100 МГц, что по нашим временам уже не вполне серьезно. Если только с аудио возиться.

Сорри, уже поправил. :) Цифры были приведены как пример. А сделать хотелось бы делитель одной частоты на другую. Как-то странно Вы поправили - мегагерцы в герцы перевели. :) Все равно делим частоту на частоту и получаем частоту. :) Наверное имелось в виду, что делим частоту в N раз и получаем поделенную частоту. Сделать это достаточно просто - используйте счетчик. С другой стороны, если надо иметь синхронные клоки, то этот вариант не пойдет. Для получения синхронных клоков надо использовать специальные аппаратные средства типа PLL. В этом случае коэффициенты умножения/деления, фазовые сдвиги и прочее задаются не HDL описанием, а с помощью параметров модуля, соответствующего аппаратному PLL.

В Стандарте на С, afair, знаковость char отдана на откуп реализации. В Стандарте С++ типы char, unsigned char и signed char - это три разных типа. Да, целые типы - знаковые.

А релизные ноты не читали?

Их как грязи. Тут надо под свои требования выбирать. Посмотреть можно тут. Использовали серию BLM21R. (0805)

Current-Feedback Amplifier (CFA) - это по сути не ОУ, а просто один из видов усилителя. Его поведение весьма отличается от традиционных ОУ. CFA характеризуется так называемым transimpedance - величиной, характеризующей его усилительные и частотные свойства. По сути, это нагрузка транзистора первого каскада. CFA лучше чем классические ОУ подходят для работы в качестве широкополосного усилителя напряжения. Они при прочих равных более дешевы, имеют бОльшее значение произведения усиления на полосу. Кроме того у них в отличие от ОУ усиление не зависит от полосы, т.е. можно отдельно рулить усилением в полосе и отдельно шириной полосы. Сопротивление неинвертирующего входа у CFA большое (база или затвор транзистора), а сопроитвление инвертирующего входа - маленькое (эмиттер или исток транзистора). Короче, это совсем другая песня, нежели ОУ, обращаться с ними, как с обычными ОУ нельзя. Что почитать?.. Даже не знаю. Я знакомился в свое время по материалам фирмы Burr-Brown у них был неких Application Handbook (кажется за 1994 год), там была пара неплохих статей, где все было разжевано. Попробуйте поискать на сайте у ТИ, оно должно быть и в электронном виде.

Не нужно его постоянно проверять. Постоянно-то не надо, а вот время от времени - очень даже полезно :) Оптимизатор довольно корявый у ИАРа. И от версии к версии разные глюки. Глюки есть у всех. У ИАРа отличный компилятор и замечательный оптимизатор - лучший в своем классе. Всегда работаю с максимальным уровнем оптимизации, проблемы бывали, но не фатальные и не связанные именно с максимальным уровнем оптимизации. Как раз на максимальном уровне глюков меньше, чем на средних. Работаю с ИАРом с 1998 года, ни разу не пожалел.

Вот и я так тоже подумал, что сам бы я в эту сумму уложился - тогда не понятно почему никто не производит? Как всегда в России действует принцип: "Если прибыль меньше 100% - то и начинать дело не стоит" Потому, что в 1000 руб. укладывается стоимость комплектующих. И то, смотря что. Один корпус приличный, думается, будет стОит весьма значительно. А кроме нее есть еще работа, накладные расходы, налоги, затраты на сертификацию и т.д. И все это при мелкой серийности, т.к. дивайс однозначно не массовый. Т.ч. 3 т.р. - это еще очень дешево, если прибор приличный. У меня стоит Mastech HY3005D-3, его брали где-то порядка 10 т.р. Но он этого стОит! :)

Не нужно его постоянно проверят. Нужно немножко подучить язык. У Вас цикл ничего не делает и компилятор его выкидывает, т.к. с его точки зрения (с точки зрения языка) с циклом или без - результат работы программы один и тот же. Но без цикла она работает быстрее и ее размер меньше. Поэтому компилятор и выкидывает этот цикл. Напишите в цикле код, который делает полезную работу и компилятор ничего выкидывать не будет. Если хочется подавить подобные оптимизации, то можно использовать прямое указание компилятору не оптимизировать, объявив одну из переменных как volatile. Тогда компилятор не будет иметь права делать какие-либо предположения о поведении этой переменной и вынужден будет честно сгенерировать код для нее, даже если этот код ничего с точки зрения компилятора не делает. Формирование задержки этим способом имеет то неудобство, что сложно предсказать, во сколько тактов реально выльется цикл. Для задания точной задержки в пакете EWAVR имеется специальная intrinsic функцию __delay_cycles(). При ее вызове компилятор сам организует код, формирующий указанную задержку. Чтобы она работала, нужно подключить заголовок inavr.h, иначе компилятор не видит прототипа и ругается. Т.ч. почитайте, во-первых, доку по С, во-вторых, доку на компилятор - она очень внятная. Удачи.

Так у Вас тут асинхронщина в полный рост! :) Не, так нельзя делать в ПЛИС. Только синхронный дизайн. хоть не ко мне вопрос, но перекликается. При использовании программируемой логики с таким подходом Вы получите неконтолируемые задержки и длительности. Они будут "плавать" в зависисмости от конкретного значения напряжения питания, текущей температуры, партии микросхем. ПЛИС специально спроектированы для синхронного дизайна. Там для этого есть специальные ресурсы - в частности, отдельные слои для распространения тактовых сигналов.

Для готового лабораторного (т.е. с регулировками, защитами) БП 1000 руб., имхо, не реально.

И какой длительности должен быть скачок? :) Синплифай прав. Насчет Леонардо не скажу, а Квартус может и синтезитует, но вряд ли нормально. На предупреждения посмотрите? Не может быть, чтоб он это молча проглатывал. В Вашем случае, похоже, требуется формирование импульса длительностью один период тактовой частоты. Тогда код должен выглядеть где-то так: module ( input c, input en output reg q ); always @(posedge c) begin if (q) q <= 0; else if (en) q <= 1; end endmodule

Если уж перешли на make, то почему бы не взять нормальный? Зачем мучиться с каким-то частным решением? Возьмите GNU make и все. Там тоже не все идеально, но это массо используемый инструмент. И там уж точно таких трудностей не будет - что напишите, то оно и будет делать. И документации по нему полно (в т.ч. и на русском, если это для Вас важно :) ).

Тут не смеятся, тут плакать хочется. А как же читать схемы? Зачем же плакать? :) Тут надо не путать две вещи. Одна - это документация по ГОСТ, другая - для себя (для настройщиков, ремонтников и т.д.). Документация по ГОСТ должна быть выполнена в соответствии с определенными требованиями - в частности, номиналы, типы и прочая информация про ЭРИ на принципиальной схеме (Э3) не выводится, только позиционные обозначения элементов. А вся необходимая информация об элементах - в перечне элементов. Зачем так сделано? Мне объясняли, что эта документация не для разработчиков схем, а для разработки последующей документации - ПП, перечня покупных изделий и т.д., т.е. для рутинной конструкторской работы. И лазить по схеме, выискивая номиналы и типы элементов, их названия и прочую инфу (которая порой и на схему-то с трудом может поместиться), конструктору неудобно и он тут ошибок наделает. Для него гораздо удобнее перечень элементов, где вся информация для него есть в сжатом, формализованном виде. А для себя, для настройщиков выпускается другая документация. Например, для настройщиков выпускается "Инструкция по настройке и проверке", где кратко описана схема, ее работа, обозначены нюансы и приведены рисунки. В т.ч. и хоть вся схема целиком в виде рисунков. И уж на этих рисунках пишите на схемах все, что хочется - на то он и рисунок. Лично я так и делаю - когда надо отдать схему в оформление, выключаю номиналы, названия микрух - словом, все, кроме позиционных. А когда надо для себя схему тиснуть, чтобы с ней работать, то включаю все это. Благо схемный редактор позволяет все это делать легко и непринужденно. Что касается обозначения мощности, то по ГОСТу на схеме это писать не положено - это должно быть отражено в перечне элементов. Но если кому-то это важно при работе (чтобы оно всегда было перед глазами и не забывать об этом) и он хочет на своем рабочем экземпляре этот момент отобразить, то сделать это можно в произвольной форме - имхо, просто рядом с номиналом подписать текстом, что, дескать, к примеру, 100 Ом, 0.75 Вт. Вот и все трудности. :)

Где взять? Или как самому сделать? Подскажите пожалуйста... А что тут трудного? Вариантов масса, в книжках описаны. Навскидку - ОУ по схеме трансимпедансного усилителя (преобразователь "ток-напряжение"), на вход ему опору с прецизионного источника (какой-нито ADR42x или от Maxim, там даже и получше есть), в обратную связь нагрузку - там будет протекать нужный ток. Резистор входной для ОУ тоже лучше прецизионный ставить - у таких ТКС лучше. Возможно, вышеописанный вариант Вам не подойдет, т.к. нагрузка там включается в ОС ОУ. Тогда можно даже и проще поступить - схема классическая: опора, с нее на неинвертирующий вход ОУ с выхода ОУ на затвор полевика. В исток полевику резистор, с резистора - на инвертирующий вход ОУ. Опора, ОУ и резистор, ессно, прецизионные. Все нестабильности и неточности полевика будут компенсироваться за счет ООС. Со стока полевика получите ток. Полевик - mosfet, конечно.

Если загрузка синхронная, то сигнал загрузки пойдет через LUT данной ячейки. При этом оно отъест часть логики. Т.е. если, к примеру, на вход данной ячейки уже приходят 3 сигнала, что вместе с синхронной загрузкой, которая тоже тащит два сигнала, то все это не сможет быть реализовано в одном LUT'е, придется каскадировать, что есть потеря ресурса и быстродействия. И из-за чего? Из-за начальной загрузки, которая на рантайме вообще в статике находится, не шевелится. Поэтому эту загрузку я всегда выношу в асинхронный вариант. Естественно, там все проще, либо 0, либо 1, т.е. одновременно используется либо PRN, либо CLRN триггера. Примерно так же. Кстати, в обоих случаях Синплифай выдает предупреждение: Register q with async load is being synthesized in compatability mode. A Synthesis/Simulation mismatch is possible.

Почему бы не взять прецизионный источник опорного напряжения и прецизионный операционник и на них не собрать источник тока?

И какие там ENOB, SFDR, SNR, SNDR?

Я не сторонник асинхронного дизайна в ПЛИС, и делать асинхронную загрузку в процессе работы никому бы не рекомендовал. Но при начальной инициализации этот подход, имхо, вполне оправдан - сам так всегда делаю. Правда, там у меня значения загрузки обычно определены - 0 либо 1. Главная причина, побуждающая использовать асинхронную установку - разгрузить рабочую логику. Что касается обсуждаемого описания, то все прекрасно синтезируется. Например, на альтеровском Циклоне. См картинку. Блокирующее присваивание при описании синхронной логики - bad style. Не надо так делать.

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